DVA-C02 Deployment Practice Question
A developer is using AWS CodePipeline to automate the deployment of a microservices application. The pipeline consists of a source stage (GitHub), a build stage (AWS CodeBuild), and a deploy stage (Amazon ECS). The developer wants to ensure that only approved changes are deployed to production. Which THREE actions should the developer take? (Choose THREE.)
⚠ Common exam trap
DVA-C02 often tests the misconception that automation alone ensures safety, so candidates select auto-deploy options instead of recognizing that approval gates and environment separation are required for controlled production releases.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Add a manual approval step before the deploy stage.
Option C is correct because inserting a manual approval action (an Approval action in CodePipeline, typically using Amazon SNS to notify approvers) between the build stage and the ECS deploy stage gates production deployment so that only changes a human explicitly approves proceed to production. Option D is correct because using separate pipelines for dev, staging, and prod isolates environments, so a change must pass through the earlier pipelines before a production pipeline is triggered, preventing unvetted commits from reaching production. Option E is correct because adding integration tests in the CodeBuild build stage (via buildspec.yml commands) validates the microservices against their dependencies and fails the pipeline on errors, so broken or unapproved-quality changes never reach the deploy stage. Option A is incorrect because automatically deploying every commit to production removes any approval gate and directly contradicts the requirement that only approved changes be deployed. Option B is incorrect because deploying all feature branches directly to production bypasses review, testing, and approval, which is exactly the risk the developer wants to eliminate.
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
About these practice questions
Courseiva writes every DVA-C02 question from scratch — 1,135 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Amazon Web Services exam blueprint
This DVA-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the DVA-C02 exam.