SAA-C03 Design Resilient Architectures Practice Question
A web application runs on an Auto Scaling group (ASG) behind an Application Load Balancer (ALB). The ASG uses the ALB target group health checks to decide when instances are healthy (for example, by using the ELB/target-group health check integration). During a deployment, the ASG performs instance replacement. Shortly after the deployment starts and while new instances are still bootstrapping, CloudWatch shows the ALB target group briefly has zero healthy targets, and users intermittently receive 502 responses. Which ASG deployment configuration best reduces the chance that there will be a period with zero healthy ALB targets, while still keeping failover behavior resilient?
⚠ Common exam trap
Many exam-takers think reducing the health check grace period or disabling health checks will speed up recovery, but in reality, these actions either cause premature removal of healthy instances or allow traffic to unhealthy instances, both of which increase the likelihood of 502 errors and reduce resilience.
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 an ASG rolling update approach that launches replacement instances first, ensures the new instances pass the ALB target group health checks, and only then terminates the old instances (for example, by configuring sufficient minimum healthy capacity and waiting on ALB health).
It describes a rolling update strategy that launches new instances first, waits for them to pass ALB target group health checks, and only then terminates old instances. This ensures that at all times during the deployment, there is a sufficient number of healthy instances to serve traffic, preventing the ALB target group from ever having zero healthy targets. The ASG's minimum healthy capacity setting and the wait for ALB health check integration guarantee that failover remains resilient because the old instances continue to handle requests until the new ones are fully ready.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Set the target group HealthCheckGracePeriod to a very short value so the ALB quickly declares instances healthy or unhealthy.
Why it's wrong here
A short grace period makes the target group start health evaluation before the application is ready. Instances that are still bootstrapping can be marked unhealthy, increasing the likelihood that all targets become unhealthy during rollout.
- ✓
Use an ASG rolling update approach that launches replacement instances first, ensures the new instances pass the ALB target group health checks, and only then terminates the old instances (for example, by configuring sufficient minimum healthy capacity and waiting on ALB health).
Why this is correct
This sequencing avoids a “no healthy targets” window. By keeping capacity stable (or maintaining a minimum healthy percentage) and waiting for the new instances to be marked healthy by the ALB, traffic is only sent to healthy targets during replacement.
- ✗
Disable ALB target group health checks and route traffic to any registered targets so replacements do not depend on health check status.
Why it's wrong here
Disabling ALB target group health checks does not make replacements faster; it removes the only mechanism the ALB has to distinguish an instance that is ready to serve traffic from one that is still bootstrapping or already failing. Without health checks, the ALB will forward requests to any registered target, including a newly launched instance that has not finished initializing or an old instance that is in the process of being terminated, producing connection errors and 502 responses from the application's perspective. Furthermore, the ASG cannot confirm that a new instance has passed the ELB health check, so it may complete the launch lifecycle while the instance is still unusable, and there is no graceful deregistration trigger for instances that become unhealthy. In short, disabling health checks eliminates the safety net that both the ALB and the ASG rely on to maintain a continuous pool of healthy targets during rolling updates.
- ✗
Reduce the ASG desired capacity by one instance during deployments so the replacement happens faster.
Why it's wrong here
Reducing desired capacity lowers the number of healthy instances that must be replaced, but it does not prevent the ALB from draining connections from terminated instances before new ones pass health checks; the ASG still terminates old instances immediately, so the gap between the last old instance deregistering and the first new instance becoming healthy can still leave zero healthy targets. This option is tempting because reducing capacity is a common technique to accelerate deployments in non-critical environments where brief downtime is acceptable, and it would be correct if the goal were solely to minimise replacement time rather than to maintain a continuous pool of healthy targets.
Go deeper
Related to this question
About these practice questions
This SAA-C03 question is part of Courseiva's 935-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam 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 SAA-C03 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 SAA-C03 exam.