CodeDeploy Rolling Update Configuration — OneAtATime Deployment

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Perform an in-place update by updating the launch template and manually replacing instances one by one.

  Why it's wrong here

  Manually terminating one instance at a time after updating the launch template lacks automation and safeguards. The Auto Scaling group will replace terminated instances with the new template, but this process relies on the operator to wait for health checks and sufficient capacity before terminating the next instance. If prompted carelessly, the in-service count can drop below the desired level, causing availability risks. AWS Instance Refresh is the intended automated mechanism for this scenario, offering health check grace periods and minimum healthy percentage controls.

• ✗

  Use a rolling update with a batch size of 100% of the instances.

  Why it's wrong here

  Setting the Instance Refresh batch size to 100% causes Amazon EC2 Auto Scaling to terminate all old instances in a single batch before launching replacements. This temporarily reduces the group to zero in-service instances, so the application becomes unavailable and the load balancer will report failed health checks. Even though the refresh completes quickly, the downtime violates the zero-downtime requirement. A smaller batch size, such as 25%, keeps at least some instances serving traffic during the update.

• ✓

  Use a rolling update with a batch size of 1 instance and enable the health check grace period.

  Why this is correct

  A rolling update with a batch size of one uses AWS Instance Refresh to replace one instance at a time while keeping the remaining instances online. The health check grace period delays the start of health checks for newly launched instances, preventing them from being terminated before the application has fully initialized. This approach maintains the group's desired capacity and availability throughout the deployment, satisfying the zero-downtime requirement. It is the AWS-recommended way to update an Auto Scaling group with a new launch template without manual intervention or traffic loss.

• ✗

  Create a new Auto Scaling group with the new launch template and gradually shift traffic using a load balancer target group.

  Why it's wrong here

  Creating a new Auto Scaling group with a separate target group does not inherently shift traffic from the existing group; it requires manual intervention to update the load balancer listener rules or DNS, which risks downtime during the transition. This method is tempting because it is used for blue/green deployments where the old group is fully replaced after validation, but the question demands a zero-downtime shift without manual cutover steps.

Go deeper

Related to this question