SAA-C03 Practice Question 14: ASG ELB Health Checks
AWS Certified Solutions Architect – Associate (SAA-C03) · Test 2 · question 4 of 10
An Auto Scaling group runs six EC2 instances behind an Application Load Balancer. Occasionally the application process on an instance deadlocks. The operating system keeps running, but the application stops answering HTTP requests.
The ALB target group correctly marks these instances unhealthy and stops sending them traffic. However, the Auto Scaling group never replaces them, so the fleet slowly loses capacity until someone terminates the stuck instances by hand. What should the architect change?
Show answer and explanation
Answer:
By default, Amazon EC2 Auto Scaling decides health only from EC2 status checks, which test whether the instance and its underlying host are reachable and running. A deadlocked application on a running OS passes those checks, so Auto Scaling believes the instance is fine even though the load balancer does not. When you turn on Elastic Load Balancing health checks for the group, Auto Scaling also uses the target group's verdict. It marks an instance unhealthy when the load balancer reports it unhealthy, then terminates and replaces it, which is exactly the self-healing that is missing here.
Option A makes things worse. The grace period only delays when Auto Scaling starts health-checking a newly launched instance. It has nothing to do with instances that fail long after launch, and a longer period just delays any detection.
Option C changes how the ALB spreads requests across Availability Zones. The ALB already routes around the unhealthy targets. The problem is that nothing replaces them.
Option D adds instances based on load, not health. The stuck instances would still count toward the group's capacity and would never be terminated. Since a deadlocked process often uses little CPU, the policy might even scale in and remove healthy instances.
Reference: Attach an Elastic Load Balancing load balancer to your Auto Scaling group