Exercise 2: Why GitOps Deployment Is a Meaningfully Different Security Posture — Possible Solution
====================================================================

Running `helm upgrade` manually from a laptop requires that laptop --
and whoever is sitting at it -- to hold real, standing cluster-admin
(or close to it) credentials capable of creating, updating, and
deleting resources across the cluster. Per k8s2-9's own comparison,
this is exactly the push-based model: the deploying system (here, a
person's laptop instead of a CI pipeline) holds working credentials
externally, outside the cluster's own control. If that laptop is lost,
stolen, or compromised, whoever has it inherits genuine deployment
access -- and because it's a person's own machine rather than a
tracked pipeline, there's often no audit trail at all of what was
actually deployed, when, or why.

Deploying this same production-ready application via GitOps (Chapter
9's pull-based model) removes that exposure entirely. The cluster's own
in-cluster controller holds the only credentials capable of applying
changes; no laptop, external CI system, or individual person ever
needs standing deployment access. Every change is instead a git commit
-- reviewed via a pull request, attributed to a specific author,
timestamped, and reversible by simply reverting the commit. The
laptop's credentials, even if compromised, would grant at most access
to propose a change via a PR (assuming git write access), not the
ability to apply anything directly to the cluster.

The meaningful difference isn't just "GitOps is more convenient" -- it's
that the manual `helm upgrade` model requires trusting a person's own
machine with real infrastructure access, while GitOps confines that
access entirely to a single, auditable, in-cluster controller, exactly
as Chapter 9's own push-vs-pull security comparison described.

WHY THIS WORKS AS AN ANSWER
------------------------------
This identifies manual `helm upgrade` as a specific instance of the
push model Chapter 9 already contrasted with GitOps's pull model, and
explains the concrete consequence (standing credentials on a
compromisable personal machine, no audit trail) rather than treating
"GitOps is better" as a given without justifying why.