SAP-C02 Practice Question 18: Slow Boot Auto Scaling Remediation
AWS Certified Solutions Architect – Professional (SAP-C02) · Test 2 · question 8 of 10
An insurance quoting application runs on Amazon EC2 instances in an Auto Scaling group behind an Application Load Balancer. Each new instance needs about 12 minutes before it can serve traffic, because it loads a large rating model from Amazon S3 onto local EBS storage and warms a cache. Traffic follows a strong weekday cycle: a steep ramp between 08:00 and 09:30 local time and a quiet night. Brokers also cause occasional unplanned surges during the day when a campaign launches. The group uses a target tracking policy on CPU utilization.
Every morning, and during each unplanned surge, latency breaches the SLA for 10 to 15 minutes while new instances boot. The ramp time drifts with daylight saving changes and seasonal patterns, and the team doesn't want to maintain schedules. Finance has rejected keeping peak capacity running around the clock. Which change fixes both latency problems at the lowest cost?
Show answer and explanation
Answer:
There are two latency problems with different causes, and option B pairs one tool with each.
The morning ramp is cyclical and predictable. Predictive scaling analyses up to 14 days of history, forecasts capacity for the next 48 hours, and adjusts itself as the pattern drifts, so no schedule needs maintaining. AWS names applications that take a long time to initialize as a key use case. The pre-launch setting (SchedulingBufferTime) launches instances ahead of the forecast hour, so the 12-minute boot finishes before the ramp arrives. Predictive scaling does not scale in by itself. Keeping target tracking alongside it handles scale-in and anything above the forecast, and the group uses whichever policy asks for more capacity.
The unplanned surges can't be forecast, so the fix is to make reactive scale-out fast. A warm pool holds instances that have already run the slow initialization and then stopped. When target tracking scales out, instances come from the warm pool and only need to start, not rebuild. In the Stopped state you pay only for EBS volumes and attached Elastic IPs, not for instance hours, which satisfies Finance.
Option A still needs a schedule, which the team refuses to maintain, and it drifts with seasons and daylight saving. A fixed 30 percent target runs extra capacity all day, and unplanned surges still hit the 12-minute boot.
Option C is exactly the always-on peak capacity Finance rejected. A Savings Plan discounts the rate but still pays for idle instances every night and weekend.
Option D detects load a little sooner, but instances still need 12 minutes after launch, which is the actual bottleneck. Faster alarms can't make cold instances ready faster.
References: Predictive scaling for Amazon EC2 Auto Scaling; Decrease latency for applications with long boot times using warm pools