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.

• ✗

  The CloudWatch alarm that triggered the rollback also stopped the old task set.

  Why it's wrong here

  CloudWatch alarms are monitoring-only; they can trigger CodeDeploy to roll back, but they do not directly stop ECS tasks or task sets. The alarm simply sends an SNS notification or event that CodeDeploy interprets as a failure signal. Stopping a task set is a deployment-lifecycle action performed by CodeDeploy or Amazon ECS, not by CloudWatch itself. Therefore, the alarm stopping the old task set is not the cause of the broken old version.

• ✗

  CodeDeploy did not drain connections from the Application Load Balancer before terminating the old task set.

  Why it's wrong here

  During a CodeDeploy blue/green deployment on ECS, the ALB's connection draining (deregistration delay) is automatically configured on the target group, so connections from the ALB to the old task set are drained before target deregistration. The rollback failure was not due to missing connection draining; rather, the old tasks were re-registered and unhealthy because the application couldn't start. Connection draining only impacts in-flight requests, not the runtime health of old application code after a database schema change. Thus, this is not the root cause.

• ✗

  The ECS service auto-scaling policy reduced the desired count of the old task set during the deployment.

  Why it's wrong here

  ECS Service Auto Scaling adjusts the service's desired count at the service level, but during a blue/green deployment, CodeDeploy owns the task sets and the traffic shift. Auto-scaling policies do not directly modify the desired count of a specific task set created for a deployment, and they are typically suspended or overridden by the deployment process. Reducing the old task set count would not cause the old application to crash or become unhealthy; it would only change capacity. Hence, auto-scaling is an unlikely contributor here.

• ✓

  The new application version changed the database schema, which broke the old version after rollback.

  Why this is correct

  When the new version applied a forward-only database schema migration, the schema changed irreversibly for the running environment. CodeDeploy rolled back the ECS task set to the old code, but that old code cannot understand the new schema, causing errors, failed health checks, and a broken application. This is the recognized cause: database changes are not automatically rolled back, so they break the previous version. The fix is to implement reverse migrations or use an expansion-contraction pattern.

Go deeper

Related to this question