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.

• ✗

  Configure a single pipeline that always builds all microservices.

  Why it's wrong here

  A single pipeline that always builds all microservices treats every commit as if it affected every service, regardless of which directories actually changed. In a monorepo, most commits touch only one microservice, so this design wastes CodeBuild minutes, increases cost, and slows feedback by running unchanged builds and potentially triggering unnecessary deployments. It also creates version churn for services that were not modified, making release history noisy and harder to audit.

• ✗

  Create separate CodeCommit repositories for each microservice.

  Why it's wrong here

  Splitting the monorepo into per-microservice CodeCommit repositories directly contradicts the company's stated desire to keep a monorepo. That separation would lose atomic cross-service commits, make refactoring across services painful, and force every team to manage multiple repositories and synchronized versioning. While this would make path filtering trivial, it sacrifices the monorepo's advantages and is not what the company asked for in this scenario.

• ✓

  Use an AWS Lambda function triggered by CloudWatch Events for CodeCommit to start the specific pipeline for the changed microservice.

  Why this is correct

  This is the correct approach because CodeCommit emits CloudWatch Events (EventBridge) on branch pushes, and a Lambda function can use the CodeCommit API to inspect the files changed in that push. The Lambda then maps a changed path prefix (e.g., 'services/order-service/') to the corresponding CodePipeline pipeline and calls StartPipelineExecution with the exact commit ID and branch. This provides path-based, per-service CI/CD while preserving the monorepo, and it only builds the microservice that actually changed, avoiding wasted compute and keeping feedback fast.

• ✗

  Use a single pipeline with multiple build actions that each check if their microservice changed.

  Why it's wrong here

  Even if each build action in a single pipeline checks whether its microservice changed, all build actions in a stage are still executed by CodePipeline—there are no native conditional actions that can be skipped based on changed files. Each action launches a CodeBuild environment, runs a shell or buildspec script to evaluate the diff, and then exits early if unchanged, so you still pay for the container startup and script execution for every service. In larger monorepos, the pipeline duration remains bounded by the number of services, not the size of the change, and resource waste is only reduced, not eliminated.

Go deeper

Related to this question