DOP-C02 SDLC Automation Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Build the image with the 'latest' tag first, then run the security scan. If it fails, delete the 'latest' tag.

  Why it's wrong here

  This approach prematurely tags a potentially vulnerable image as 'latest' before any security validation has completed. Once that tag is pushed to Amazon ECR, any downstream consumer (ECS, EKS, or other services) that pulls 'latest' will receive the vulnerable image, and even if the tag is later deleted, the underlying image digest may already have been pulled and deployed. Deleting a tag in ECR does not automatically delete the underlying image, leaving a stale artifact; this creates an unnecessary exposure window and does not prevent accidental use before cleanup.

• ✓

  In the post_build phase, run the security scan, and if it passes, tag the image with 'latest' and push.

  Why this is correct

  This is the correct approach because it guarantees the 'latest' tag is only ever applied to an image that has successfully passed the defined security gate. In the post_build phase of CodeBuild, you can run a local container scanner (e.g., Trivy, Snyk, or Anchore) and only when the exit code indicates a pass do you execute `docker tag` to relabel the built image as `latest` followed by `docker push`. This ensures the 'latest' tag remains immutable and clean, with no vulnerable image ever being exposed under that tag during the build or scan window.

• ✗

  Use ECR lifecycle policies to remove images that do not pass the security scan.

  Why it's wrong here

  Amazon ECR lifecycle policies are rules that operate solely on image age and tag count (e.g., expire untagged images older than X days or keep only N images), and they cannot evaluate scan findings such as CVSS severity scores. Lifecycle actions are executed automatically by ECR without awareness of the results from basic or enhanced scanning, so they cannot selectively remove images that failed a security scan. To act on scan results you must build an event-driven workflow (e.g., Amazon EventBridge and a Lambda function) that calls the ECR API to delete or quarantine failing image digests.

• ✗

  Tag the image with 'latest' only after the build phase, regardless of scan results.

  Why it's wrong here

  Tagging the image with 'latest' immediately after the build phase, without any reference to the security scan outcome, completely bypasses the requirement that only passing images receive the 'latest' tag. In CodeBuild, the build phase completes before the post_build phase, so this action promotes the image before a scan is even initiated, and there is no conditional logic to stop it. This leaves a vulnerable window like the first option but without any fallback cleanup mechanism, making it strictly non-compliant and a dangerous practice.

Go deeper

Related to this question