DOP-C02 Practice Question 46: Warm Pool Slow Boot Scale Out
AWS Certified DevOps Engineer – Professional (DOP-C02) · Test 5 · question 6 of 10
An Auto Scaling group runs a JVM application whose instances take about 12 minutes from launch to being able to serve traffic, because each one writes a large reference dataset to its local disk and then warms its caches. Traffic spikes are driven by unscheduled marketing pushes, so they follow no repeating daily or weekly pattern. Target tracking does scale out, but the new capacity arrives far too late and latency suffers, so the team currently runs a large permanent over-provision to compensate. They want to cut both the scale-out latency and that standing cost, and the application cannot be containerized this quarter.
What should the team do?
Show answer and explanation
Answer:
A warm pool is built for this case: it "gives you the ability to decrease latency for your applications that have exceptionally long boot times, for example, because instances need to write massive amounts of data to disk," and "with warm pools, you no longer have to over-provision your Auto Scaling groups to manage latency", both halves of the requirement. The pool holds pre-initialized instances that the group draws on during a scale-out (a *warm start*), so the 12-minute initialization has already happened. Keeping them Stopped is "an effective way to minimize costs": you pay for the EBS volumes rather than the instances. The lifecycle hook is not optional here: Auto Scaling "stops or hibernates instances as they enter the warm pool, and does not wait for user data to finish running", so without a hook the instances would be stopped mid-initialization and put into service unready.
Option A changes when instances are requested, not how long they take to become useful. Whatever the policy, each new instance still needs 12 minutes, so the capacity still arrives late, just in bigger, more expensive batches.
Option B depends on a pattern that does not exist. Predictive scaling forecasts from historical load, so it works for recurring daily or weekly cycles; unscheduled marketing pushes give it nothing to forecast.
Option C attacks only one of the two causes and requires application work. A shared file system changes the I/O profile and adds a new dependency, and it does nothing about the cache warm-up that makes up the rest of the 12 minutes.
Reference: Decrease latency for applications with long boot times using warm pools