Challenge 3: Diagnose a Production Incident — Possible Solution
====================================================================

WHAT WENT WRONG: production was configured to always pull myapp:latest
— but latest is just a MUTABLE pointer to whatever was most recently
pushed under that tag, from ANY branch, by ANY build. When the
unrelated branch's build pushed its own image also tagged latest, it
silently overwrote what that tag pointed to — there was no requirement
that the new latest come from a tested, intended release branch at
all. The next time production pulled myapp:latest (whether
automatically or on a routine restart/redeploy), it received this new,
broken image instead of whatever had been running previously — with no
deploy event, no approval step, and no record that anything had
changed from production's own perspective.

HOW THIS CHAPTER'S TAGGING STRATEGY WOULD HAVE PREVENTED IT: if
production were instead configured to pull an IMMUTABLE tag — a
specific commit SHA (myapp:a1b2c3d) or a semantic version
(myapp:v1.2.3) — the unrelated branch's build could push whatever it
wanted to its own SHA tag or to latest without ever affecting what
production actually runs. Production's tag would remain pointing at
exactly the commit it was deliberately deployed with, unaffected by
any build happening elsewhere, until someone deliberately changed
production's configuration to reference a NEW specific tag as part of
an actual, intentional deployment.

The core lesson: this incident is a direct real-world instance of this
chapter's central gotcha — latest was never a safe thing for
production to depend on, precisely because "most recently pushed" and
"the version we intend to run in production" are two completely
different, unrelated concepts.