Increase the Auto Scaling health check grace period for slow-starting instances

SAP-C02 By islever Editorial Last updated

Design a strategy to meet reliability requirements. Determine a strategy to improve reliability.

Short answer

D Increase the health check grace period on the Auto Scaling group so instances can finish downloading content before health checks apply.

Question

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?
  1. Increase the size of the EC2 instances.
  2. Increase the health check timeout for the ALB.
  3. Change the health check path for the ALB.
  4. Increase the health check grace period for the Auto Scaling group. Correct Answer

Key Takeaways

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.

Common mistake: 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.

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

https://docs.aws.amazon.com/autoscaling/ec2/userguide/health-check-grace-period.html

This link opens the official vendor documentation in a new tab.

Community Votes

D
100%

100% of anonymous learners picked answer D. Votes are pick records left by other test-takers — they are not the verified answer.

Discussion 6 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 6

  1. ebbff63 👍 9 Answered D
    D. Increase the health check grace period
  2. AhmedSalem 👍 7 Answered D
    Answer D. Extending the grace period allows the instances more time to complete their startup tasks, including downloading the additional content from S3, before health checks start. This solution does not require altering the user data scripts in production, which aligns with the company’s requirements.
  3. liuliangzhou 👍 2 Answered B
    I prefer B over D: The problem is that EC2 instances need to download content from S3 during the startup process, which may take some time. If ALB's health check is performed during this period and the EC2 instance is unable to respond to the health check request due to incomplete downloads, ALB may consider the instance unhealthy and remove it from the service. This may trigger the auto scaling group to start new instances, creating an endless loop.
  4. AzureDP900 👍 1
    D is right. Since the EC2 instances are being terminated due to an ELB system health check failure, it's likely that the health checks are timing out while the user data scripts are still running and downloading content from S3. This causes the ALB to think the instance is unhealthy, leading to termination. By increasing the health check grace period for the Auto Scaling group, you give the instances more time to complete their startup process, including the execution of the user data scripts, before considering them healthy or unhealthy. This should prevent the endless loop of launching and terminating EC2 instances due to health check failures.
  5. JoeTromundo 👍 1 Answered D
    Correct answer: D - The grace period in Auto Scaling allows new instances time to finish initialization (like downloading data or running user scripts) before health checks start. By increasing this grace period, you provide more time for the EC2 instances to complete the startup process and avoid premature termination. Incorrect answer: B - This only extends the time the ALB waits for a response on a health check, but if the EC2 instance isn't ready to serve requests due to its long initialization time, it will still fail the health check.
Show 1 more comment
  1. nimbus_00 👍 1 Answered D
    https://docs.aws.amazon.com/autoscaling/ec2/userguide/health-check-grace-period.html#:~:text=In%20the%20console%2C%20by%20default,the%20health%20check%20grace%20period.

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

Modernize centralized firewall appliances with a Gateway Load Balancer and Auto Scaling

S-grade

Use Lambda over a CloudWatch Logs stream to count unique users per client

S-grade

Serve global game assets with Route 53 latency records and health checks

S-grade

Reach a cross-account S3 data lake through a gateway endpoint and an access point bucket policy

S-grade

Practice All SAP-C02 Questions

Access 85 questions with complete answers and detailed explanations.

View Full SAP-C02 Practice Test →

← Back to SAP-C02 Study Guide