Exercise 1: What Helm Templating Solves That Raw YAML Can't — Possible Solution
====================================================================

The specific problem: per the chapter, "raw YAML has no built-in
templating -- that means separate, near-duplicate files per
environment, or external tooling." Applying this to the dev/staging/
prod scenario:

WITHOUT Helm (Course 1's raw YAML approach): deploying the same
application with different replica counts, resource limits, and image
tags per environment means maintaining THREE (or more) nearly
identical, manually-duplicated copies of every YAML manifest -- one
set for dev, one for staging, one for prod -- each differing only in a
handful of specific values. Every time a structural change is needed
(a new probe, an added environment variable, a changed label), that
change has to be made CONSISTENTLY across all three duplicated copies
by hand, which is genuinely error-prone -- it's easy to update dev and
staging but forget prod, or to introduce an inconsistency between
copies that were supposed to stay identical apart from a few
deliberately-different values.

WITH Helm's templating: per the chapter's own example, the actual
STRUCTURE of the manifest is written ONCE, as a template
(`templates/deployment.yaml`), with placeholders like
`{{ .Values.replicaCount }}` and `{{ .Values.image.tag }}` standing in
for the values that genuinely need to differ per environment. A
SEPARATE, much smaller values file per environment (e.g.
`values-prod.yaml` overriding just `replicaCount` and `tag`) supplies
only the handful of values that actually differ -- the underlying
structure is defined exactly once and reused identically across every
environment. A structural change only needs to be made in ONE place
(the template), and it automatically applies correctly to every
environment the next time each is deployed/upgraded.

WHY THIS WORKS AS AN ANSWER
------------------------------
This contrasts the two approaches specifically on the axis the chapter
raises -- duplicated full files (raw YAML) vs. one shared template
plus small per-environment value overrides (Helm) -- and explains the
concrete maintenance risk (structural changes needing to be
consistently applied across duplicates) that templating specifically
eliminates.