Domain 3 · Cloud native application delivery

16% of the exam. How code becomes a running workload through CI/CD and GitOps, how it's packaged with Helm or Kustomize, how releases roll out safely, and how you debug what's running.

Domain 3 questions start after the container image exists. They ask how a change travels from a Git commit to a running Pod, who or what applies it, how you limit the damage of a bad release, and which kubectl command shows you what's wrong once it's live. Expect definition questions ("what is GitOps?") and "which project does this?" questions in roughly equal measure.

Competency	What it's really asking	Pages
3.1 Application delivery	CI vs continuous delivery vs continuous deployment, the four GitOps principles, push vs pull, Argo CD and Flux, Helm vs Kustomize, rolling, blue/green and canary releases, progressive delivery	GitOps and CI/CD, Packaging and rollouts
3.2 Debugging	Getting inside or next to a running Pod (`exec`, `port-forward`, `debug`, ephemeral containers), reading events, and telling why a rollout stalled	Debugging

What connects Domain 3 to the rest of the exam:

Everything here relies on declarative objects and reconciliation loops, covered in Architecture and API and kubectl.
Deployments, ReplicaSets and their rollout behaviour are introduced in Core objects.
Debugging a running app picks up where Troubleshooting (Pod phases, describe, logs) leaves off.
Canary traffic splitting often uses a service mesh, and rollout analysis reads metrics from observability tools such as Prometheus.
Argo, Flux and Helm maturity levels come back in CNCF ecosystem.

GitOps is not just 'YAML in Git'

Storing manifests in a repository and running kubectl apply from a pipeline is infrastructure as code with a push pipeline. It becomes GitOps only when an agent pulls the desired state and keeps reconciling it, reverting drift. If an option lacks the continuous, pull-based loop, it isn't the GitOps answer.