Exercise 3: A Partial Values File on helm upgrade — What Happens to Replica Count — Possible Solution
====================================================================

What might happen:

Per the chapter's own warn-box, "running helm upgrade with only a new,
small values file... without including previously-set custom values
like a production replica count -- can reset those OTHER values back
to the chart's defaults, unless --reuse-values is used or the full,
correct values file(s) are passed every time."

In this specific scenario: the team's production release presumably
had a CUSTOM replica count set at some earlier point (likely higher
than the chart's own default, appropriate for real production load).
Their new values file only specifies the updated image tag -- it says
NOTHING about replicaCount at all. If Helm isn't told to preserve the
release's existing values (via `--reuse-values`, or by including the
full, complete values file with the custom replica count still
present), it has no way to know the production-specific replica count
should be kept -- it falls back to whatever the CHART'S OWN DEFAULT
`replicaCount` value is (per this chapter's own `values.yaml` example,
that default might be something like 3), silently overwriting whatever
higher, production-appropriate value was previously set.

How this could cause a real incident:

If the production replica count was, say, 10 (sized to handle real
production traffic), and the upgrade silently resets it down to the
chart's default of 3, the application would suddenly be running with
FAR LESS CAPACITY than production traffic actually requires --
potentially causing real, user-facing degradation (overloaded pods,
increased latency, dropped requests) immediately after what the team
believed was a routine, low-risk change (just updating an image tag).
This is especially dangerous because the actual INTENT of the upgrade
(deploy a new image version) had nothing to do with replica count at
all -- the team likely wouldn't even think to check that value after
the upgrade, since their change was ostensibly unrelated to scaling.

How to prevent it:

Per the chapter, always either use `--reuse-values` (explicitly telling
Helm to keep the release's existing values except for what's newly
specified) or ensure the FULL, correct values file -- including the
custom replica count -- is passed on every single upgrade, rather than
assuming a small, partial values file will "just add to" what's
already there.

WHY THIS WORKS AS AN ANSWER
------------------------------
This applies the chapter's own warn-box mechanism directly to the
specific scenario, explains WHY the reset happens (Helm falls back to
chart defaults for anything not explicitly specified or preserved),
and traces the concrete, realistic incident (unexpected capacity loss
right after an unrelated-seeming change) that this specific gotcha
produces in practice.