Exercise 2: How Sealed Secrets Resolves the Git-Everything vs. No-Raw-Secrets Tension — Possible Solution
====================================================================

The tension, stated precisely:

GitOps' own core principle, per this chapter, is that git holds the
COMPLETE desired state of the cluster as the single source of truth --
implying, on its face, that EVERYTHING (including Secrets) should live
in git for the GitOps controller to actually apply it. But per
`k8s1-7`'s own warning, "committing raw Secret YAML to git is
genuinely risky" -- since a Secret's value is only base64-encoded
(trivially reversible), committing one to git is functionally
equivalent to committing a plaintext credential permanently into
version history. These two principles appear to directly conflict:
GitOps wants everything in git, but Secrets specifically shouldn't be
there in a readable form.

How Sealed Secrets resolves this:

Per the chapter, "Sealed Secrets encrypts a Secret's value CLIENT-SIDE,
before it's ever committed to git, producing a SealedSecret object
that's genuinely safe to commit." The key mechanism: the encryption
happens BEFORE the object ever reaches git, using a key pair where only
the CLUSTER'S OWN CONTROLLER holds the private key needed to decrypt
it. This means:

1. The object committed to git (the SealedSecret) IS genuinely
   encrypted, not just base64-encoded -- unlike a raw Secret, decoding
   it requires the private key, which never leaves the cluster and was
   never committed to git at all.

2. GitOps' own principle is satisfied -- the SealedSecret object DOES
   live in git, tracked and reviewable exactly like every other
   resource, so the "everything in git" requirement is genuinely met.

3. `k8s1-7`'s warning is also satisfied -- what's actually SITTING in
   git is not a readable, trivially-decodable value at all; it's
   something only the cluster's own controller can ever turn back into
   the real Secret.

The GitOps controller, once it pulls the SealedSecret from git, submits
it to the cluster's Sealed Secrets controller, which decrypts it using
the private key and creates the real (still only base64-encoded, but
now access-controlled via RBAC per `k8s2-4`) Secret object inside the
cluster itself -- never exposing the decrypted value in git at any
point.

WHY THIS WORKS AS AN ANSWER
------------------------------
This states the apparent conflict explicitly (GitOps wants everything
in git; Secrets shouldn't be readable in git) and then traces exactly
HOW client-side encryption before commit satisfies BOTH requirements
simultaneously -- the object exists in git (satisfying GitOps) while
never containing anything decodable outside the cluster (satisfying
Chapter 1-7's warning), rather than treating the two principles as
requiring a trade-off.