Exercise 3: How Auto-Scaling Can Mask a Real Problem — Possible Solution ==================================================================== In your own words, how the masking happens: Auto-scaling is designed to react to symptoms, not diagnose causes -- it watches a metric like CPU utilization or request load, and when that metric crosses a threshold, it simply adds more instances to share the load. If the REASON the metric is climbing is a genuine bug -- a memory leak, an inefficient database query, unoptimized code -- the auto-scaler has no way to know that, and no way to fix it. It just keeps doing its one job: adding capacity to compensate for whatever load it sees, regardless of whether that load is legitimate growth or a symptom of something broken. The result, per the chapter, is that cost quietly climbs in the background (more instances running than a healthy version of this workload would actually need) while the underlying bug goes completely unaddressed -- until the auto-scaling group hits its configured MAXIMUM instance count. At that point, scaling can no longer compensate, and the original symptom (slow responses, timeouts, failures) reappears -- except now at a larger scale, likely under more load and more urgency than if the root cause had been investigated back when the first extra instances were added. What a support engineer should investigate before accepting "the auto-scaler handled it": 1. Whether the instance count has been trending steadily upward over time for a WORKLOAD that hasn't genuinely grown -- a sign the system is quietly compensating for something rather than serving more real traffic. 2. Whether resource usage per-instance (CPU, memory, especially memory trending upward without ever going back down) looks like a leak or inefficiency rather than proportional, legitimate demand. 3. Whether the cost trend (Chapter 9) is increasing faster than any actual increase in real user traffic or business activity would explain. 4. Whether the group is getting close to its configured maximum instance count -- a warning sign that the current trajectory is heading toward the exact "scaling can no longer compensate" failure this chapter describes. WHY THIS WORKS AS AN ANSWER ------------------------------ This restates the chapter's own causal chain (symptom masked -> cost climbs quietly -> hits the max -> symptom reappears worse) in the student's own words, and then converts that causal chain directly into a concrete investigation checklist -- each item corresponds to one stage of the chapter's own described failure mode, giving a support engineer something actionable to check rather than simply trusting that scaling activity by itself means the system is healthy.