Exercise 1: The Security-Model Difference Between Push CI/CD and Pull GitOps — Possible Solution
====================================================================

TRADITIONAL PUSH-BASED CI/CD: per the chapter, "an external pipeline
runs kubectl apply/helm upgrade against the cluster." This means the
CI/CD SYSTEM ITSELF -- typically running outside the cluster, often on
a third-party CI provider's own infrastructure -- has to hold real,
working credentials with sufficient permissions to actually create,
update, and delete resources in the cluster. Those deployment
credentials live EXTERNALLY, on infrastructure the cluster's own
administrators don't fully control, and if that external CI system is
ever compromised, an attacker who gains access to it directly inherits
genuine deployment access to the cluster.

PULL-BASED GITOPS: per the chapter, "a controller inside the cluster
pulls changes from git itself." The GitOps controller runs INSIDE the
cluster it manages, and it's the one initiating contact with git (to
check for changes) -- git itself, and any external CI system that
might build artifacts or run tests, never needs to hold any cluster
deployment credentials at all. Per the chapter, "nowhere external --
the cluster reaches out, nothing reaches in."

The key difference: WHO holds the credentials, and WHERE they live.
Push-based CI/CD requires trusting an EXTERNAL system with real
cluster deployment access. Pull-based GitOps keeps that access
entirely INTERNAL to the cluster's own controller -- no external
system, including the CI pipeline itself, is ever a viable attack path
into the cluster's deployment permissions, because none of them ever
possess those permissions in the first place.

WHY THIS WORKS AS AN ANSWER
------------------------------
This directly contrasts WHERE deployment credentials physically live
in each model (external CI system vs. an internal, cluster-resident
controller) and explains the concrete security consequence of that
difference (a compromised external system inheriting real access vs.
having nothing to inherit at all) -- exactly the distinction the
chapter's own comparison table and accompanying explanation draws.