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.

• ✓

  Create a single pipeline with a parallel action for unit tests, then a serial stage for integration tests

  Why this is correct

  This design uses CodePipeline stages to gate flow: a stage with parallel unit-test actions runs the per-microservice unit suites concurrently, cutting total test wall-clock time, and the stage only completes when every action succeeds. The subsequent integration-test stage is serial relative to unit tests, so integration testing starts only after all unit suites are green, preserving deterministic dependency ordering while still exploiting parallelism where safe.

• ✗

  Create a single pipeline with a serial stage for unit tests, then integration tests

  Why it's wrong here

  A single pipeline with a serial stage for unit tests forces the unit suites to execute one after another instead of concurrently, so total pipeline duration becomes the sum of all unit-test runtimes rather than the slowest runtime. While this is functionally correct and simpler to visualize, it needlessly increases feedback time for a microservice system without any benefit in reliability.

• ✗

  Create one pipeline per microservice, each triggering integration tests via SNS

  Why it's wrong here

  Running one pipeline per microservice and having each publish an SNS notification for integration testing decentralizes orchestration. The integration-test job may be triggered before all services' unit tests pass, or multiple SNS messages may launch duplicate concurrent integration runs, causing race conditions and unpredictable results; there's also no built-in mechanism to aggregate success/failure across pipelines. Integration tests across services need a single coordinated pipeline that knows the status of all components before proceeding.

• ✗

  Use AWS CodeBuild batch builds with a fan-out/fan-in pattern

  Why it's wrong here

  CodeBuild batch builds are designed to run multiple builds of a project (e.g., different build configurations or versions) using a single buildspec, not to coordinate sequential or parallel pipeline stages. A fan-out/fan-in pattern with batch builds cannot express stage-level gates like 'run integration only after all unit tests succeed' with proper failure handling; also, batch builds are a build action, not a pipeline orchestrator, so external orchestration is still required. The natural fit for stage coordination is CodePipeline stages and actions, which provide explicit transition and gate semantics.

Go deeper

Related to this question