Overview
Domain 3 covers the path from a code change to a running, healthy application. Application Delivery includes continuous integration and continuous delivery pipelines, GitOps with a Git repository as the source of truth and pull-based reconcilers such as Argo CD and Flux, packaging and templating with Helm charts and Kustomize overlays, and release strategies such as rolling updates, blue-green and canary releases, plus rollback. Debugging covers how to investigate an application once it is deployed: kubectl logs including previous container logs, kubectl describe and events, kubectl exec, port-forward, and ephemeral debug containers added with kubectl debug.
The November 2025 revision raised this domain from 8% to 16% and added Debugging as a named topic. Questions stay conceptual: which tool or practice fits a delivery goal, and which command or signal best explains an application problem.
How it's tested
Delivery questions describe a team's goal, such as auditable deployments, gradual exposure of a new version or reusable packaging, and ask which practice or CNCF tool fits. Debugging questions describe what a developer sees and ask which command reveals the cause. Expect definitions to be tested through short scenarios.
-
Match the release strategy
A risk or rollout goal is described and you choose rolling update, blue-green or canary, or recognise how rollback works.
-
GitOps principles
You identify what makes a workflow GitOps: declarative desired state in Git, versioned history, pull-based agents and continuous reconciliation.
-
Choose the debug command
A symptom is given and you pick logs, logs --previous, describe, exec, port-forward or kubectl debug as the best next step.
A team wants every production change to be reviewed, versioned and automatically applied, with drift corrected if someone edits the cluster by hand. A CI pipeline running kubectl apply is tempting, but it pushes once and does not notice later drift. A GitOps controller such as Argo CD or Flux pulls desired state from Git and continuously reconciles the cluster, which meets all three needs.
Topics 2
Official topics from the CNCF / The Linux Foundation outline, in outline order.
3.1 Application DeliveryCI/CD, GitOps, packaging and release strategies.
- What it means
- Application delivery is the practice of moving code changes reliably into running environments. In cloud native systems it combines CI pipelines that build and test images, CD that deploys them, declarative configuration stored in Git, and tooling that packages Kubernetes manifests for reuse.
- What to understand
- CI builds, tests and publishes an image; CD deploys it. GitOps, as described by the OpenGitOps principles, keeps desired state declarative and versioned in Git and uses agents that pull and continuously reconcile. Argo CD and Flux are CNCF graduated GitOps tools. Helm packages manifests as charts with templated values and tracks releases; Kustomize patches plain YAML with overlays and is built into kubectl. Rolling updates replace Pods gradually; blue-green switches traffic between two full environments; canary sends a small share of traffic to the new version first.
- How it shows up
- Expect to match a delivery goal to a practice or tool, or to identify GitOps characteristics.
- Common confusion
- Calling any pipeline that runs kubectl apply from CI a GitOps workflow.
3.2 DebuggingInvestigating application behaviour in a running cluster.
- What it means
- Debugging means finding out why an application behaves incorrectly after deployment, using the information Kubernetes exposes about containers and the tools it provides to inspect them.
- What to understand
- kubectl logs shows container output, and --previous shows the last terminated instance, which is essential for crash loops. kubectl describe and kubectl get events show scheduling, image and probe problems. kubectl exec runs a command in a running container, while kubectl debug adds an ephemeral container for images that lack a shell. kubectl port-forward reaches a Pod or Service locally without exposing it. Checking Service endpoints confirms whether traffic can reach ready Pods.
- How it shows up
- A symptom is described and you choose the command that reveals the cause fastest.
- Common confusion
- Using kubectl exec on a distroless image with no shell, where kubectl debug is needed.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Continuous integration
Automatically building and testing every code change.
- Remember
- CI produces a versioned, tested container image.
- Tested as
- Distinguishing CI from CD is a basic delivery question.
- Trap
- Treating CI as the step that deploys to production.
-
Continuous delivery and deployment
Delivery keeps every build releasable; deployment releases it automatically.
- Remember
- Continuous deployment removes the manual approval step.
- Tested as
- Questions test the difference in automation.
- Trap
- Using the two terms interchangeably.
-
GitOps
Operating systems by storing declarative desired state in Git and reconciling it automatically.
- Remember
- OpenGitOps principles: declarative, versioned and immutable, pulled automatically, continuously reconciled.
- Tested as
- A recurring KCNA concept with clear definitions.
- Trap
- Ignoring the pull-based and continuous reconciliation parts.
-
Argo CD and Flux
CNCF graduated GitOps controllers that sync clusters from Git.
- Remember
- Both run in the cluster and detect drift.
- Tested as
- Recognising them as GitOps tools is commonly asked.
- Trap
- Grouping them with CI tools such as Jenkins.
-
Helm
The Kubernetes package manager that installs charts as named releases.
- Remember
- Charts use templates and values files; helm rollback returns to a previous release.
- Tested as
- Packaging and versioned install questions point here.
- Trap
- Confusing Helm with a container registry.
-
Kustomize
Template-free customisation of YAML using bases, overlays and patches.
- Remember
- It is built into kubectl with apply -k.
- Tested as
- Questions contrast it with Helm templating.
- Trap
- Thinking Kustomize uses a templating language.
-
Rolling update
The default Deployment strategy that replaces Pods a few at a time.
- Remember
- maxSurge and maxUnavailable control the pace.
- Tested as
- Default behaviour questions point here.
- Trap
- Assuming it routes a fixed percentage of users to the new version.
-
Blue-green deployment
Running two full environments and switching traffic all at once.
- Remember
- Rollback is an instant switch back.
- Tested as
- Zero-downtime cut-over scenarios point here.
- Trap
- Confusing it with canary's gradual traffic shift.
-
Canary release
Sending a small share of traffic to a new version before full rollout.
- Remember
- Often automated by tools such as Argo Rollouts or Flagger with metrics checks.
- Tested as
- Risk-limiting rollout questions point here.
- Trap
- Thinking canary needs twice the capacity like blue-green.
-
kubectl rollout undo
Reverts a Deployment to a previous ReplicaSet revision.
- Remember
- Revision history is kept via revisionHistoryLimit.
- Tested as
- Rollback questions for plain Deployments use this.
- Trap
- Expecting it to roll back ConfigMap changes.
-
kubectl logs --previous
Shows logs from the last terminated container instance.
- Remember
- Vital for CrashLoopBackOff, where the current container may have no output yet.
- Tested as
- Crash debugging questions often hinge on it.
- Trap
- Reading only current logs and finding them empty.
-
Ephemeral debug containers
Temporary containers added to a running Pod with kubectl debug.
- Remember
- Useful for minimal or distroless images without a shell.
- Tested as
- Questions on debugging locked-down images lead here.
- Trap
- Trying kubectl exec into an image with no shell.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Rolling update vs. blue-green vs. canary
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Rolling update | Gradually replaces old Pods with new ones | Built into Deployments; old and new run together briefly | Expecting user-percentage control |
| Blue-green | Two full environments with a traffic switch | Instant cut-over and rollback, double capacity | Thinking traffic shifts gradually |
| Canary | Small traffic share to the new version first | Limits impact while metrics are checked | Assuming plain Deployments do this without extra tooling or traffic control |
Helm vs. Kustomize
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Helm | Package manager using templated charts | Tracks releases with install, upgrade and rollback | Expecting it to be built into kubectl |
| Kustomize | Overlays and patches on plain YAML | No templating; built into kubectl apply -k | Expecting release history and rollback |
Push-based CD vs. GitOps pull
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Push-based CD | A pipeline applies manifests to the cluster | Pipeline needs cluster credentials; runs once per change | Assuming it corrects later manual drift |
| GitOps pull | An in-cluster agent pulls desired state from Git | Continuous reconciliation; credentials stay in the cluster | Calling a CI job that runs kubectl apply GitOps |
logs vs. describe vs. exec vs. debug
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| kubectl logs | Container stdout and stderr | Application-level errors | Using it for image pull failures where the container never started |
| kubectl describe | Object details and recent events | Scheduling, image and probe failures | Skipping it and guessing |
| kubectl exec | Command inside a running container | Needs a shell or binary in the image | Using it on a crashed container |
| kubectl debug | Adds an ephemeral debug container | Works with minimal images | Forgetting it exists |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Push pipeline as GitOps
- What candidates pick
- A Jenkins or GitHub Actions job running kubectl apply as the GitOps answer.
- Why it looks right
- The manifests live in Git, which sounds like GitOps.
- Why it's wrong
- GitOps requires an agent that pulls desired state and continuously reconciles; a push job does not correct drift.
Clue to watch for Words such as 'drift', 'reconcile' or 'source of truth'.
-
Canary vs. blue-green
- What candidates pick
- Blue-green when the goal is exposing 5% of users first.
- Why it looks right
- Both reduce release risk.
- Why it's wrong
- Blue-green switches all traffic at once; only canary shifts a small share gradually.
Clue to watch for A percentage of traffic or users in the question.
-
Helm as a registry
- What candidates pick
- Helm as the place container images are stored.
- Why it looks right
- Helm charts are stored in repositories.
- Why it's wrong
- Helm packages Kubernetes manifests; images live in an OCI registry.
Clue to watch for Options mixing chart repositories and image registries.
-
Rollback by redeploying
- What candidates pick
- Editing the manifest back by hand as the only rollback path.
- Why it looks right
- It is how the change was made.
- Why it's wrong
- Deployments keep revision history, so kubectl rollout undo or helm rollback reverts quickly; in GitOps you revert the commit.
Clue to watch for A request for the fastest way to return to the previous version.
-
Empty logs mean no error
- What candidates pick
- Concluding the app is fine because kubectl logs shows nothing.
- Why it looks right
- No error output is visible.
- Why it's wrong
- In a crash loop the new container may not have logged yet; --previous shows why the last one exited.
Clue to watch for Status CrashLoopBackOff with a rising restart count.
-
exec on distroless
- What candidates pick
- kubectl exec with a shell into a minimal image.
- Why it looks right
- exec is the familiar way in.
- Why it's wrong
- Distroless images have no shell, so exec fails; kubectl debug adds an ephemeral container with tools.
Clue to watch for Mention of a distroless or scratch-based image.
Answer framework
Pick delivery and debugging answers by matching the stated goal or symptom to one specific mechanism.
- Identify whether the question is about building, deploying, packaging or releasing, and separate CI tools from CD and GitOps tools.
- If the scenario mentions drift, auditability or Git as the source of truth, favour a pull-based GitOps controller over a push pipeline.
- For packaging, choose Helm when templated, versioned releases are needed and Kustomize when patching plain YAML per environment is enough.
- For releases, use the traffic clue: gradual replacement means rolling update, an all-at-once switch means blue-green, and a small percentage means canary.
- For debugging, start with describe and events, use logs or logs --previous for application errors, and use exec or kubectl debug to inspect inside a container.
Practice question
Want more like this? The KCNA practice test has questions for every domain.
Checklist
0 of 11
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
This domain rewards clear definitions, so begin by writing one-sentence explanations of CI, continuous delivery, continuous deployment and GitOps, then check them against the OpenGitOps principles. Learn the four principles word for word, because questions often test one of them indirectly.
Next, get hands-on with a small app. Install it with a Helm chart, change a value, upgrade, and roll back. Then express the same app with a Kustomize base and two overlays and apply each with kubectl apply -k. Seeing both tools side by side makes the comparison questions easy.
Install Argo CD or Flux on a local cluster, point it at a Git repository, and edit a Deployment by hand to watch the controller undo your change. That single exercise explains drift correction better than any diagram.
For debugging, deploy an app that crashes on start, a distroless image and a Pod with a bad image tag, and practise choosing logs, logs --previous, describe, exec or debug for each. Because this domain doubled to 16% in 2025, give it real time rather than a final skim.
FAQ
How much is Cloud Native Application Delivery worth on the KCNA?
Cloud Native Application Delivery is 16% of the KCNA, about 10 of 60 questions. Its weight doubled from 8% in the November 2025 revision, which also added Debugging.
Do I need to know how to write a CI pipeline?
No. Know what CI and CD each do, where image builds and tests happen, and how GitOps differs from push-based deployment.
Which GitOps tools should I know?
Argo CD and Flux, both CNCF graduated projects. Know that they run in the cluster, pull from Git and reconcile drift.
Is Helm on the KCNA?
Yes, at a conceptual level: charts, values, releases, upgrade and rollback, and how Helm compares with Kustomize.
Which debugging commands matter most?
kubectl logs (including --previous), describe, get events, exec, port-forward and debug. Know which symptom each one helps with.
Does the KCNA cover progressive delivery tools?
Know the canary and blue-green concepts. Recognising tools such as Argo Rollouts or Flagger helps, but their configuration is beyond the associate level.
Other DevOps & Containers certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 3 knowledge
Practise matching delivery goals to GitOps, Helm, Kustomize and release strategies, and choosing the right debugging command.