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.

• ✗

  Add a manual approval step after the test stage.

  Why it's wrong here

  A manual approval action placed after the test stage cannot retry a failed test. When the CodeBuild action fails, CodePipeline marks that stage as Failed and immediately stops the pipeline, so the approval action is never reached. If the approval were placed before the test stage, it would pause the pipeline for human review but would still require a user to manually re-run the build from the console or CLI, and CodePipeline has no built-in 'approve-to-retry' behavior. This introduces costly human latency and fails to provide the automatic retry that the organization requested, so it does not solve the flaky-test problem.

• ✗

  Use Amazon CloudWatch Events to listen for test failures and trigger a new pipeline execution.

  Why it's wrong here

  Listening for test failures via CloudWatch Events and triggering a new pipeline execution restarts the entire pipeline from the beginning, not just the failed test stage, which wastes time and resources and does not isolate the retry to the flaky integration tests. This approach is tempting because CloudWatch Events can react to state changes in CodePipeline, and in scenarios where a full pipeline rerun is acceptable—such as recovering from an infrastructure failure in a build stage—it would be a valid solution.

• ✓

  Configure the CodeBuild project to automatically retry the build on failure.

  Why this is correct

  CodeBuild projects support an automatic retry configuration that re-runs a failed build when the build action is executed by CodePipeline. By setting a retry limit (up to 10 attempts) and an optional execution timeout, the CodeBuild service itself retries the exact same build spec, allowing flaky integration tests to succeed on a subsequent attempt without any pipeline-level changes. The build action in CodePipeline reports a single success/failure status based on the final attempt, so a successful retry lets the stage pass without re-running earlier source or build stages. This is the only option that provides an automatic, stage-local retry mechanism for the build, directly addressing the flaky tests.

• ✗

  Create a second pipeline that triggers only on test failures.

  Why it's wrong here

  Creating a separate pipeline that triggers on test failures is not a true retry mechanism: CodePipeline provides no native event source for a failed stage in another pipeline, so you would need to build a custom EventBridge rule and handle permissions. Even then, the second pipeline would execute its own stages from the beginning, reprovisioning infrastructure and re-running earlier steps rather than retrying the isolated integration-test action. This adds duplicate resources, maintenance overhead, and potential concurrency conflicts with the original pipeline, making it an unnecessarily complex and ineffective solution.

Go deeper

Related to this question