Exercise 1: What HPA Solves Beyond Manual Scaling, and Why Requests Matter Even More — Possible Solution
====================================================================

What HPA solves that manual `kubectl scale` doesn't:

Per this chapter, manual scaling (Chapter 5) sets "a fixed,
manually-chosen number" that "doesn't respond to real-time changes in
demand automatically." A human has to notice load has changed and
manually run a new scale command every time. HPA solves this by
continuously watching real metrics (CPU/memory utilization, or custom
metrics) and automatically adjusting replica count on its own, in real
time, without anyone needing to notice a load change and intervene
manually -- exactly Chapter 2 (Course 1)'s reconciliation loop applied
to replica count, but driven by a live metric rather than a
human-chosen fixed number.

Why setting resource requests accurately matters MORE, not less, once
HPA is in use:

Per the chapter, "HPA's calculations are based on the percentage of
REQUESTED resources actually being used." This means HPA's entire
scaling decision is only as meaningful as the request value it's
measuring against. If a container's CPU request is set inaccurately --
say, far too low relative to what it actually needs -- then a
relatively small amount of ACTUAL CPU usage could register as a very
HIGH percentage of that (too-low) request, triggering HPA to scale up
aggressively even though the workload isn't genuinely under heavy real
load. Conversely, a request set far too HIGH would make genuinely
heavy usage look like a low percentage, causing HPA to under-scale
during real load spikes, risking degraded performance.

With MANUAL scaling, an inaccurate request value doesn't directly
drive any AUTOMATIC decision -- a human chooses the replica count
based on their own judgment, so a mis-set request is a wasted-cost
problem (Ch.10/`cloud1-9`) but not something actively steering scaling
decisions. With HPA, the request value becomes the direct INPUT to an
automated decision loop -- getting it wrong doesn't just waste
resources, it actively causes HPA to scale incorrectly, either too
aggressively or not aggressively enough.

WHY THIS WORKS AS AN ANSWER
------------------------------
This identifies the core capability HPA adds (continuous, metric-
driven adjustment vs. a static human-chosen number) and then explains,
mechanistically, why HPA's specific calculation method (percentage of
REQUESTED resources) makes request accuracy a direct input to an
automated decision -- a qualitatively different, more consequential
role than the one it played under purely manual scaling.