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 test stage in the pipeline with a CodeBuild action that runs code quality and unit tests.

  Why this is correct

  Adding a dedicated test stage in CodePipeline with a CodeBuild action is the canonical pattern for automated validation: after the source is retrieved and built, the pipeline invokes a CodeBuild project whose buildspec runs code quality checks and unit tests. Because the stage fails the pipeline if any test exits non-zero, this creates an explicit quality gate that must pass before the build artifact proceeds to deployment, and CodePipeline's stage boundaries give you clear visibility into test results and execution history.

• ✗

  Add a manual approval step before the deploy stage.

  Why it's wrong here

  A manual approval step is a human-in-the-loop governance control: it pauses the pipeline until a designated approver reviews the change and clicks Approve, but it never executes test code or validates application behavior. Without a CodeBuild or other test action, the approval step cannot detect failed assertions, coverage regressions, or linting errors, so it does not satisfy the requirement to run code quality and unit tests during CI/CD.

• ✓

  Modify the buildspec file of the build stage to include test commands and fail on test failures.

  Why this is correct

  Modifying the buildspec file in the existing build stage to include test commands with fail-fast behavior (e.g., `set -e` combined with test runners) makes the build action itself the testing gate, so if unit tests fail, the CodeBuild build fails and the pipeline stops before artifact generation. This is a correct approach because it runs tests on the same compute environment as the build, but unlike a separate test stage, it couples test execution with compilation and may not produce a distinct test phase in pipeline visualizations.

• ✗

  Configure the source stage to use an S3 bucket and add a test action.

  Why it's wrong here

  Configuring the source stage to use an S3 bucket only changes where the pipeline retrieves source artifacts; S3 is object storage and has no compute or runtime to execute test commands. Adding a test action after a source stage still requires an action provider like CodeBuild (or a partner test action) to actually run code, and merely swapping the source repository type to S3 does not introduce any test capability or quality gate into the pipeline.

• ✗

  Use AWS CloudFormation to create a test environment and run tests.

  Why it's wrong here

  AWS CloudFormation is an infrastructure-as-code service that provisions and manages resources such as EC2 instances, Lambda functions, and VPCs by creating or updating stacks, but it does not execute application code or run test suites. While you can use CloudFormation to provision a test environment, the actual code quality and unit test commands must be run by a compute service—typically CodeBuild or another test runner—so a CloudFormation template alone cannot satisfy the testing requirement.

Go deeper

Related to this question