Centralize pre-scan and post-scan ECR repositories in the shared account and gate promotion with one EventBridge-triggered Lambda

DOP-C02 By islever Editorial Last updated

Apply automation for security controls and data protection. Design and build automated solutions for complex tasks and large-scale environments.

Short answer

AE Centralize pre-scan and post-scan repositories in the shared account and promote clean images with one EventBridge-triggered Lambda.

Question

A company is migrating its container-based workloads to an AWS Organizations multi-account environment. The environment consists of application workload accounts that the company uses to deploy and run the containerized workloads. The company has also provisioned a shared services account for shared workloads in the organization. The company must follow strict compliance regulations. All container images must receive security scanning before they are deployed to any environment. Images can be consumed by downstream deployment mechanisms after the images pass a scan with no critical vulnerabilities. Pre-scan and post-scan images must be isolated from one another so that a deployment can never use pre-scan images. A DevOps engineer needs to create a strategy to centralize this process. Which combination of steps will meet these requirements with the LEAST administrative overhead? (Choose two.)
  1. Create Amazon Elastic Container Registry (Amazon ECR) repositories in the shared services account: one repository for each pre-scan image and one repository for each post-scan image. Configure Amazon ECR image scanning to run on new image pushes to the pre-scan repositories. Use resource-based policies to grant the organization write access to the pre-scan repositories and read access to the post-scan repositories. Correct Answer
  2. Create pre-scan Amazon Elastic Container Registry (Amazon ECR) repositories in each account that publishes container images. Create repositories for post-scan images in the shared services account. Configure Amazon ECR image scanning to run on new image pushes to the pre-scan repositories. Use resource-based policies to grant the organization read access to the post-scan repositories.
  3. Configure image replication for each image from the image's pre-scan repository to the image's post-scan repository.
  4. Create a pipeline in AWS CodePipeline for each pre-scan repository. Create a source stage that runs when new images are pushed to the pre-scan repositories. Create a stage that uses AWS CodeBuild as the action provider. Write a buildspec.yaml definition that determines the image scanning status and pushes images without critical vulnerabilities to the post-scan repositories.
  5. Create an AWS Lambda function. Create an Amazon EventBridge rule that reacts to image scanning completed events and invokes the Lambda function. Write function code that determines the image scanning status and pushes images without critical vulnerabilities to the post-scan repositories. Correct Answer

Key Takeaways

The least-overhead design centralizes both repository sets in one account (A) rather than scattering pre-scan repositories across every publishing account, and uses a single event-driven Lambda (E) rather than a CodePipeline per repository. The physical separation between pre-scan and post-scan repositories is what guarantees a deployment can never pull an unscanned image, since the organization policy grants write only to pre-scan and read only from post-scan. Option D would require creating and maintaining a separate CodePipeline for every pre-scan repository.

To centralize container image scanning with the least administrative overhead, create the pre-scan and post-scan Amazon ECR repositories in the shared services account, enable ECR image scanning on push to the pre-scan repositories, and use resource-based policies granting the organization write access to pre-scan and read access to post-scan so no deployment can consume unscanned images. A single AWS Lambda function reacting to ECR image scan completed events inspects the scan status and promotes only images without critical vulnerabilities into the post-scan repositories.

Common mistake: Creating a separate AWS CodePipeline for each pre-scan repository (D) — this multiplies pipeline definitions, one per repository, which is precisely the administrative overhead the question asks to avoid; trungtd highlighted this when explaining why E is preferred over D. Creating pre-scan repositories in each publishing account (B) — this distributes the scanning surface across accounts instead of centralizing it, and the option's policy only grants read access to the shared post-scan repositories. Option C's replication approach conflicts with the requirement that images be scanned before they reach the post-scan repositories.

Expert Analysis

Why the Answer Is Correct

Creating both the pre-scan and post-scan ECR repositories in the shared services account (A) centralizes the process in one place rather than scattering scanning across every application account. Enabling image scanning on push to the pre-scan repositories means every image is evaluated as it arrives, and resource-based policies that grant the organization write access to pre-scan repositories and read access only to post-scan repositories structurally guarantee that a deployment cannot consume a pre-scan image. A single Lambda function (E) reacting to ECR image scan completed events reads the scan status and pushes only images with no critical vulnerabilities into the post-scan repositories, so one function serves every repository with no per-repository pipeline to build or maintain.

Why the Other Options Are Wrong

B creates pre-scan repositories in each account that publishes images, which distributes the scanning surface across accounts rather than centralizing it, and its resource-based policies grant only read access to the shared post-scan repositories without giving the publishing accounts the write access they would need. C configures replication from each pre-scan repository to its post-scan counterpart, which would copy images regardless of scan outcome and therefore does not gate deployment on a clean scan. D creates a separate CodePipeline for each pre-scan repository; while it does implement the scan-then-promote logic, it requires a pipeline definition per repository, which is the administrative overhead the question asks to minimize. A and E are the correct combination.

Community Comment Notes

Community was split, A,E (58) versus A,D (42). The A,E camp argued that creating the repositories in the shared services account and using one Lambda minimizes overhead, and that D means creating and managing many pipelines. The A,D camp pointeded out operational concerns, with aws_god noting Lambda is not intended for Docker workloads and auxwww linking a discussion on building and pushing Docker images from Lambda. Both answers share A; the deciding factor is that D scales linearly with the number of repositories while E scales with a single function.

Official Reference

These links open the official vendor documentation in a new tab.

Community Votes

AE
58%
AD
42%

58% of anonymous learners picked answer AE. Votes are pick records left by other test-takers — they are not the verified answer.

Discussion 9 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 9

  1. trungtd 👍 5
    LEAST administrative overhead: => Should create ECR repositories in the shared services account => A And should create only 1 Lambda function => E D wrong because it involves creating and managing multiple pipelines, which increases administrative overhead significantly
  2. jamesf 👍 4
    keywords: LEAST Administrative overhead Option A centralizes the repository management in the shared services account, simplifying access control and configuration management. Pre-scan and post-scan repositories are clearly separated, ensuring that only post-scan images are deployed. Option E uses event-driven automation to handle the scanning results and image promotion, reducing manual intervention and ensuring that only images that pass the security scan are moved to the post-scan repositories. This approach is efficient and minimizes administrative overhead compared to manually setting up pipelines or replication mechanisms.
  3. aws_god 👍 4
    Lambda is not meant to work with Docker
  4. xdkonorek2 👍 4
    E > D for LEAST administrative overhead
  5. auxwww 👍 3
    Why not E - To push images to the post-scan repo, you need a custom lambda container to run docker pull and push commands which is more complicated than Option D
Show 4 more comments
  1. limelight04 👍 3
    AD gives the least administrative overhead
  2. auxwww 👍 2
    Why E is not optimal - https://stackoverflow.com/questions/51158595/build-and-push-docker-image-to-aws-ecr-using-lambda
  3. tgv 👍 2
    ---> AE
  4. jojewi8143 👍 1
    AE because lambda

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

Optimizing Amazon Timestream Query Performance

S-grade

Deploy the CloudWatch agent as a StatefulSet with IRSA and CloudWatchAgentServerPolicy, and configure the OIDC provider

S-grade

Disable cross-zone load balancing on the target group and start an Application Recovery Controller zonal shift

S-grade

Stream all CloudWatch metrics to Firehose, transform with Lambda, and deliver to S3

S-grade

Practice All DOP-C02 Questions

Access 85 questions with complete answers and detailed explanations.

View Full DOP-C02 Practice Test →

← Back to DOP-C02 Study Guide