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.

• ✗

  Use a larger build environment for the Test stage.

  Why it's wrong here

  Enlarging the CodeBuild compute environment (e.g., from General1.small to Large) only increases per-execution CPU and memory; if the Test stage contains a single build action running a monolithic test suite, the tests still execute serially inside that one job. Wall-clock time is bounded by the sum of all test durations, not by throughput, so the gain comes only from faster individual tests—often marginal. This does not introduce any parallelism, so the stage duration remains largely unchanged.

• ✓

  Configure parallel build actions in the Test stage to run tests concurrently.

  Why this is correct

  CodePipeline naturally executes independent actions within a stage in parallel unless you set explicit runOrder values or action dependencies. By configuring multiple build actions, each running a partitioned portion of the test suite (by module, service, or shard), the total test work is spread across concurrent CodeBuild projects. The stage completes when all parallel actions finish, so overall duration approaches the slowest shard's critical path rather than the sum of all tests, directly reducing feedback time.

• ✗

  Remove the Test stage and rely on post-deployment testing.

  Why it's wrong here

  Removing the Test stage and relying on post-deployment testing eliminates the safety gate before artifacts are promoted to production; any regression would only be detected after the code is already live and serving traffic. You would then need smoke tests, health checks, or rollback procedures in production, all slower and riskier than fail-fast pipeline validation. This does not shorten the pipeline—it merely postpones quality verification, increasing the blast radius of defects and the cost of remediation.

• ✗

  Move the Test stage to after deployment.

  Why it's wrong here

  Moving the Test stage to after deployment reverses the pipeline's intended order: the build artifact is deployed to a production or production-like environment before tests execute, so you are validating in the same environment that serves end users. The stage still consumes the same duration, but the feedback loop is longer because deployment happens first, and any test failure may already have exposed users to faulty behavior. It also contradicts CodePipeline's recommended practice of verifying an artifact before promotion to later stages.

Go deeper

Related to this question