DVA-C02 Deployment 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 the pipeline to automatically deploy every commit to production.

  Why it's wrong here

  Without a manual approval action, every code push to the configured source repository immediately progresses to the Deploy stage, so unreviewed or unvalidated changes can be released to production. CodePipeline only pauses stage transitions if you explicitly add an Approval action; otherwise, execution flows automatically. This approach eliminates the human review gate and increases the risk of introducing breaking changes without oversight.

• ✗

  Deploy all feature branches directly to production.

  Why it's wrong here

  Feature branches are often in-progress and not merged with the latest mainline, so deploying them directly to production exposes users to incomplete or conflicting code. In CodePipeline, you can target a branch as the source, but that bypasses the merge and integration process that normally precedes a production release. Production should receive only vetted changes from the mainline after passing CI/CD and release approval.

• ✓

  Add a manual approval step before the deploy stage.

  Why this is correct

  In CodePipeline, a manual approval step is an action that pauses the pipeline execution at a specified stage and sends an SNS notification to designated reviewers. The reviewer must sign in, review the deployment details, and choose Approve or Reject before the Deploy stage can run, providing a human control point for production changes. This is the recommended way to satisfy a 'gates' requirement without removing automation.

• ✓

  Use separate pipelines for different environments (e.g., dev, staging, prod).

  Why this is correct

  Creating separate pipelines for dev, staging, and prod allows each environment to use its own IAM role, artifact bucket, and deployment configuration, so you can target a rolling deploy in dev but a blue/green deploy in prod. It also means that approval gates and test stages can be inserted only where needed, and a failure in an earlier environment does not affect the production pipeline. Artifacts can be promoted between pipelines by versioning them in an S3 bucket and configuring the next pipeline to fetch the approved artifact.

• ✓

  Implement integration tests in the build stage to catch errors early.

  Why this is correct

  Running integration tests as part of the Build stage (or a dedicated Test stage) in CodePipeline prevents defective code from reaching the deploy steps. CodeBuild can execute your test suite and mark the build as failed if any test fails, causing the pipeline execution to halt and not produce a deployable artifact. This catches service-level compatibility and data-layer issues early, reducing the likelihood of production incidents.

Go deeper

Related to this question