DOP-C02 SDLC Automation Practice Question
Your company uses AWS CodePipeline to automate the deployment of a critical web application. The pipeline consists of a source stage (CodeCommit), a build stage (CodeBuild), and a deploy stage (CodeDeploy) that deploys to an Auto Scaling group of EC2 instances running Amazon Linux 2. The deployment strategy is 'AllAtOnce'. Recently, the team noticed that during deployments, the application becomes completely unavailable for a few minutes until the new instances are registered with the load balancer. The business requires zero downtime during deployments. You need to modify the deployment process to achieve zero downtime while minimizing cost and complexity. The Auto Scaling group currently has a minimum of 2 instances and a maximum of 4 instances. The application is stateless and sessions are stored in ElastiCache. Which solution should you implement?
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
✓
Use CodeDeploy's blue/green deployment with an Application Load Balancer. Create a new Auto Scaling group for the green environment, deploy to it, and then shift traffic.
CodeDeploy's 'Blue/Green' deployment creates new instances, shifts traffic, and allows rollback, achieving zero downtime. Option A is incorrect because 'HalfAtATime' still causes temporary capacity reduction. Option B is incorrect because increasing minimum size does not change deployment strategy. Option D is incorrect because creating a new ASG and using DNS can work but is more complex and costly than CodeDeploy's built-in blue/green.
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 second Auto Scaling group, deploy to it, and then update Route 53 to point to the new group.
Why it's wrong here
This approach is incorrect because updating Route 53 to point to a new Auto Scaling group introduces a DNS propagation delay, during which traffic might still be directed to the old, unavailable instances, failing the zero-downtime requirement. It is tempting because this blue/green deployment pattern is effective for achieving zero downtime by maintaining two distinct environments and switching traffic only when the new environment is fully ready.
- ✗
Change the deployment configuration to 'HalfAtATime' to update half the instances at a time.
Why it's wrong here
Selecting the 'HalfAtATime' deployment configuration (e.g., in CodeDeploy or an ASG rolling update) still uses an in-place update mechanism. It only halves the number of instances updated simultaneously, but each instance must still be deregistered from the load balancer, have its software replaced, and then pass health checks before being restored. During that transition, the instances being updated are unavailable, and if the load balancer's connection draining is short, active sessions on those instances are forcibly terminated, causing downtime. This is fundamentally a rolling-with-batch approach, not a blue/green switch, and therefore does not meet the zero-downtime requirement.
- ✓
Use CodeDeploy's blue/green deployment with an Application Load Balancer. Create a new Auto Scaling group for the green environment, deploy to it, and then shift traffic.
Why this is correct
CodeDeploy's blue/green deployment with an Application Load Balancer is the correct solution because it provisions a completely new Auto Scaling group (the green environment) running the new revision and registers it with a new or existing target group. The ALB only shifts traffic to the green target group after all instances pass health checks, while the blue instances continue serving requests during the entire setup and validation. After a configurable wait time, the original blue ASG is terminated, ensuring no point where users have no service. This architecture provides true zero downtime because the old fleet remains fully operational until the new fleet is verified.
- ✗
Increase the Auto Scaling group's minimum size to 4 so there are always extra instances.
Why it's wrong here
Increasing the Auto Scaling group's minimum size to 4 only changes the number of instances present; it does not alter the deployment method itself, which remains an in-place update. During the deployment, all instances in the ASG—including the new, extra ones—are subject to the same update cycle, so each will be taken offline, updated, and then brought back, often one at a time or all at once depending on the policy. Having more instances does not create a separate, isolated version of the application; it merely spreads the risk across a larger fleet while still allowing the old version to be fully replaced before the new version is stable. The 'extra' instances are not a blue environment, so traffic still hits instances during the update window, making it impossible to achieve truly zero downtime.
Go deeper
Related to this question
About these practice questions
Courseiva writes every DOP-C02 question from scratch — 251 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 by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This DOP-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 DOP-C02 exam.