Increase the Auto Scaling health check grace period for slow-starting instances
A company hosts an application that uses several Amazon EC2 instances in an Auto Scaling group behind an Application Load Balancer (ALB). During the initial startup of the EC2 instances, the EC2 instances run user data scripts to download critical content for the application from an Amazon S3 bucket. The EC2 instances are launching correctly. However, after a period of time, the EC2 instances are terminated with the following error message: “An instance was taken out of service in response to an ELB system health check failure.” EC2 instances continue to launch and be terminated because of Auto Scaling events in an endless loop. The only recent change to the deployment is that the company added a large amount of critical content to the S3 bucket. The company does not want to alter the user data scripts in production. What should a solutions architect do so that the production environment can deploy successfully?
Community Votes
100% of anonymous learners picked answer D. Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
The health check grace period tells the Auto Scaling group to wait a set number of seconds after an instance comes into service before the load balancer health checks can mark it unhealthy, which covers the boot window without touching the scripts.
Instances behind an Application Load Balancer are terminated in a loop because the load balancer health check fails before the user data script finishes downloading a large amount of critical content from S3. The user data scripts must not be changed in production.
Increasing the health check timeout or changing the health check path. The load balancer timeout cannot be set below the interval the group uses to evaluate health, and changing the path alters what is being probed rather than granting the instance more startup time, so the loop persists.
Community Discussion (6 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
The Auto Scaling health check grace period is the documented control for exactly this situation. Until the grace period elapses, the Auto Scaling group does not act on load balancer health check results, so instances that need longer than the default window to download content from S3 and become healthy are not terminated. The instances launch successfully, the application becomes healthy, and then the load balancer starts including them, all without modifying the user data scripts the company asked not to touch.Why the Other Options Are Wrong
A: A larger instance does not shorten the time needed to download a large amount of content over the network, so the health check still fails during startup. B: The health check timeout controls how long the load balancer waits for a response, not how long the Auto Scaling group tolerates a booting instance, and it cannot be set below the health check interval. C: Changing the health check path changes what the load balancer probes, and if the probe already succeeded the problem would not occur, so this does not address the startup timing.Community Comment Notes
The community voted 90 to 1 for D. Commenters linked the Auto Scaling documentation for the health check grace period and explained that it gives instances time to finish user data scripts before health check results are acted upon, which is precisely the reported symptom after the S3 bucket grew.Official Reference
Related Analysis
Practice All SAP-C02 Questions
Access 85 questions with complete answers and detailed explanations.
View Full SAP-C02 Practice Test →