How Do You Ramp ALB Traffic Gradually During EC2 Cache Warm-Up?
An application runs on Amazon EC2 instances behind an Application Load Balancer (ALB). The application takes up to 2 minutes to populate a local cache after the application is started. The application reports as healthy in the target group health check a few seconds after starting. A CloudOps engineer observes that after some of the instances are rebooted, the instances receive an equal share of the traffic immediately after each instance reports as healthy. The application needs to receive a gradually increasing share of the traffic while the application cache is populated. Which solution will meet this requirement?
Community Insight
The exam tests whether you know slow start only applies when a target is newly registered or transitions to healthy — a plain reboot does not re-trigger it, so you must deregister and re-register to make the ramp happen.
ALB target group slow start mode exists precisely to ramp a newly registered target's traffic share linearly instead of handing it an equal share the moment health checks pass. This page confirms that setting slow_start.duration_seconds to 120 seconds, combined with deregister/register around the reboot, is the answer that satisfies the gradual cache warm-up requirement.
Choosing HealthCheckTimeoutSeconds, assuming a longer health check delay will hold traffic back; it only changes how long the ALB waits for a response before marking a target unhealthy and never ramps traffic at all.
Community Discussion (3 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
Application Load Balancer target groups support a slow start attribute, slow_start.duration_seconds, that gives a target a linearly increasing share of requests during the configured window instead of an equal share as soon as it reports healthy. Because the application reports healthy within seconds but needs up to two minutes to fill its local cache, a 120-second slow start window matches the warm-up period exactly. The critical nuance is that slow start is applied to targets that are newly registered (or that become healthy after being unhealthy); a simple reboot does not re-register the instance, so the engineer must deregister the instances before the reboot and register them again afterwards to put slow start into effect. Option A captures both halves of that requirement — the 120-second duration and the deregister/register cycle.Why the Other Options Are Wrong
Option B changes HealthCheckTimeoutSeconds, which only controls how long the load balancer waits for an HTTP response before declaring a health check failed; it cannot throttle or ramp request volume. As Derel1ct put it, that setting "doesn't change traffic ramping", and lengthening it just risks slower failure detection. Option C is unrelated on every axis: a CloudWatch alarm restarting unhealthy instances does nothing about warm-up, and switching loadbalancing.algorithm.type to weighted_random has no bearing on per-target ramp-up. Option D looks plausible because a lifecycle hook can hold an instance in a wait state, but lifecycle hooks are driven by Auto Scaling lifecycle transitions; attaching already-running instances does not gate ALB traffic, and the ALB still sends the target its full share once the target group considers it healthy.Community Comment Notes
Derel1ct walked through each distractor and concluded that slow start is the only mechanism that actually ramps traffic, noting that "Weighted_Random is an ALB algorithm that automatically sends more traffic to larger instance types, does nothing for ramping based on instance uptime". blasdelezo tied the requirement directly to the scenario text, observing that a 2-minute cache population means "the appllication is not yet ready to handle the full load". same24 argued for the lifecycle hook on the grounds that it keeps the instance out of the target group until readiness is signalled, but that mechanism depends on an Auto Scaling launch transition and does not apply to re-registering running instances, which is why the slow start answer prevails.Exam Strategy
When a question mentions an ALB, "gradually increasing share of traffic" and a warm-up period, slow start is almost always the intended service feature. Read the options for whether the warm-up is triggered by a re-registration; if the question scenario is a reboot, the correct answer must include deregister/register, not merely a health check timer change.Official Reference
Exam Strategy
Anchor on the phrase "gradually increasing share of traffic" — that is the AWS definition of ALB slow start mode, not of health check timing. Then check whether the option also re-registers the target, because slow start only engages on registration or a healthy transition.
Frequently Asked Questions
Why isn't slow start applied automatically when a rebooted EC2 instance passes health checks?
Slow start applies to targets that are newly registered or that transition to healthy after being unhealthy; a plain reboot leaves the registration unchanged, so you must deregister and register again.
Why is changing HealthCheckTimeoutSeconds to 120 seconds wrong here?
It only controls how long the ALB waits for a health check response before marking a target unhealthy, so it delays failure detection rather than throttling or ramping request volume.
Related Analysis
Practice All SOA-C03 Questions
Access 100 questions with complete answers and detailed explanations.
View Full SOA-C03 Practice Test →