Exercise 3: Why Committing a Raw Secret YAML to Git Is Risky — Possible Solution
====================================================================

Why this is risky:

Per the chapter, a Kubernetes Secret's value is only BASE64-ENCODED,
not encrypted -- and base64 is "a simple, publicly known, reversible
transformation" (per Exercise 1's own reasoning) requiring no key or
password to reverse. Committing a raw Secret YAML file to a git
repository means committing what is EFFECTIVELY PLAINTEXT sensitive
data (a password, API key, or token, trivially decodable by anyone who
sees the file) directly into source control.

This is exactly the risk `pipelines1-5` describes for any committed
credential: "a committed credential is compromised forever" -- once
committed, the sensitive value exists in the repository's HISTORY
permanently, even if the file is later deleted or the value is
changed, because every prior commit still contains the original,
decodable value. Anyone with access to the repository's history --
including, in many real-world incidents, an unintended public audience
if a private repository is ever accidentally made public, or a
compromised developer account -- gains trivial access to the real
secret value, with no encryption standing between them and it.

What category of tool solves this for GitOps workflows:

Per the chapter, tools like SEALED SECRETS or EXTERNAL SECRETS
OPERATOR exist specifically to solve this problem. These tools allow
genuinely ENCRYPTED secret material (not just base64-encoded) to be
safely committed to git -- the encrypted form is only decryptable by
the specific cluster's own controller (which holds the real decryption
key), meaning even if the encrypted file in git were exposed, it would
be useless to anyone without access to that specific cluster's key
material. This lets teams keep the benefits of a GitOps workflow
(everything, including secret configuration, tracked and reviewed in
git) without ever committing a plaintext-equivalent secret value
directly.

WHY THIS WORKS AS AN ANSWER
------------------------------
This connects the chapter's own base64-isn't-encryption point directly
to `pipelines1-5`'s "compromised forever" principle, explaining
specifically WHY a base64 Secret committed to git is functionally
equivalent to committing a plaintext credential -- and then names the
exact category of tool the chapter itself points to as the solution,
rather than a generic "use a secrets manager" answer disconnected from
the chapter's specific GitOps framing.