DOP-C02 - SDLC Automation (22% of the exam) - 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.

Exam traps in SDLC Automation

Answers that look right on this material and are not. Each one is a distractor from a different question in the DOP-C02 bank for this domain.

Enable a CodeBuild local cache with the source cache mode so each build reuses the checked-out source tree and avoids re-resolving the project dependencies on the managed build compute.
Why it is wrong: A source local cache only speeds up source checkout and is tied to a reused host, so it does not persist resolved dependencies across the separate, freshly provisioned builds the scenario describes.
Generate a permanent CodeArtifact access token once, store it as a plaintext environment variable in the build project configuration, and reuse it for every build so package managers always have credentials available.
Why it is wrong: A permanent token stored in plaintext is exactly the long-lived embedded credential the security team prohibits, and a leak would stay valid indefinitely instead of expiring quickly as required.
Host a self-managed Nexus or Artifactory server on Amazon EC2 behind an internal load balancer, configure it as the proxy for public registries, and have every pipeline authenticate to it with static service credentials stored in the build environment.
Why it is wrong: A self-hosted repository server can proxy public registries, but it adds servers, patching and capacity management to operate, and static credentials in the build environment break the least-overhead and IAM-integration goals.

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