CodeDeploy Automatic Rollback — Configuration Steps

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 a CloudWatch alarm to stop the deployment if instances are unhealthy.

  Why it's wrong here

  A CloudWatch alarm can detect unhealthy instances and even trigger an Auto Scaling lifecycle hook or SNS notification, but by itself it has no mechanism to reroute traffic, replace the instance, or influence CodeDeploy's deployment lifecycle. Stopping the deployment would leave the fleet in a failed, half-updated state and would not remediate the underlying health check failure — it only escalates the problem. CodeDeploy already has built-in minimum healthy host checks; an external alarm adds monitoring but does not address why the application fails the ELB health check.

• ✗

  Modify the deployment configuration to deploy to only one instance at a time.

  Why it's wrong here

  Setting the deployment configuration to deploy to one instance at a time (e.g., CodeDeploy's OneAtATime) only changes the batch size and number of hosts that can be unhealthy during deployment. If the application itself fails the ELB health check—because of configuration errors, missing dependencies, or the new code crashing—each instance will still be marked unhealthy when the health check runs. A one-at-a-time strategy merely reduces blast radius; it does not correct the health check failure and will still fail once every updated instance is assessed.

• ✓

  Update the deployment group to use an Elastic Load Balancer and configure health checks.

  Why this is correct

  Registering the instances with an Elastic Load Balancer and configuring health checks in the CodeDeploy deployment group is the correct fix because CodeDeploy can then use the ELB's health check to validate that each instance is serving traffic correctly before allowing the deployment to continue. ELB health checks also enable automatic instance replacement by the Auto Scaling group when an instance becomes unhealthy, which prevents the deployment from being stuck with known-bad hosts. This integrates deployment validation with traffic shift and instance lifecycle management, directly addressing the health check failure at the application layer.

• ✗

  Increase the desired capacity of the Auto Scaling group to tolerate failures.

  Why it's wrong here

  Increasing the desired capacity of the Auto Scaling group adds more instances to absorb traffic, but it does nothing to prevent the newly deployed code from failing health checks on every instance. The deployment would still fail because CodeDeploy evaluates health per instance; extra capacity only means more unhealthy instances are running. It also increases cost and masks the real issue—the health check configuration or the application code—rather than validating that the updated application actually passes the health check before traffic is fully shifted.

Go deeper

Related to this question