DOP-C02 - SDLC Automation - Section 1.4

Build, version, store and share build artifacts using AWS CodeArtifact, Amazon ECR and Amazon S3 artifact stores, including dependency caching and image signing.

Store and version package dependencies in AWS CodeArtifact and container images in Amazon ECR, and apply image signing to enforce supply-chain integrity. Distinguish which artefact store suits a given workload - package registry versus object store versus container registry.

AWS CodeArtifactAmazon ECRArtifact versioningImage signing

Practice question for this objective

Free sampleSDLC Automationmedium

A regulated company publishes container images to Amazon ECR and deploys them to Amazon ECS. Security requires that only images cryptographically signed by the company's release pipeline can be deployed, that the signing keys are managed by AWS rather than stored on build hosts, and that verification at deploy time uses an open, portable signature format. Which approach MOST directly satisfies these requirements?

  • AEnable ECR image scanning with Amazon Inspector so each pushed image is assessed for vulnerabilities, and block deployment of any image that has unresolved critical findings in the scan report.
  • BTurn on ECR tag immutability and grant only the pipeline role permission to push, so that once a tag exists it cannot be overwritten and only the pipeline can place images under approved tags in the repository.
  • CUse AWS Signer with a signing profile to sign each image in the pipeline and store the Notation-format signature in ECR, then verify the signature with the trusted signing identity before the image is deployed to ECS. Correct
  • DHave the pipeline compute a SHA-256 digest of each image, store the digest in AWS Systems Manager Parameter Store, and have the deploy stage compare the running image digest against the stored value before launching tasks.
Use AWS Signer with ECR-stored Notation signatures and signature verification to enforce that only pipeline-signed container images are deployed. AWS Signer container image signing creates a signing profile whose keys AWS manages, signs the image in the pipeline, and stores a Notation-format signature in ECR next to the image; verifying that signature against the trusted signing identity before deployment cryptographically proves the image came from the approved pipeline.

Why A is wrong: Vulnerability scanning is valuable, but it proves nothing about who built or published an image, so it cannot enforce that only images signed by the release pipeline are allowed to deploy.

Why B is wrong: Tag immutability and tight push permissions stop tag reuse and limit who can push, but they produce no verifiable signature, so a deploy-time check cannot cryptographically confirm provenance.

Why C is correct: AWS Signer manages the signing keys and produces Notation-format OCI signatures stored alongside the image in ECR; the deploy step verifies against the trusted signing identity, enforcing pipeline-signed provenance with an open, portable format.

Why D is wrong: Comparing a stored digest detects substitution of a known image, but it is a hand-rolled scheme with no managed keys and no portable signature, missing the cryptographic signing and open-format requirements stated.

See more DOP-C02 practice questions, answers explained.

More in this domain

Back to all SDLC Automation objectives, or the DOP-C02 cert hub.

Examworthy is not affiliated with or endorsed by Amazon Web Services. Original, blueprint-aligned practice material only.