Introduction
Most KCNA study plans pour energy into Kubernetes Fundamentals (about 46% of the exam) and Container Orchestration (about 22%), which is sensible — that is where most of the points live. But the smallest domain on the Kubernetes and Cloud Native Associate (KCNA) exam is also the one candidates most often wing: Cloud Native Application Delivery, worth roughly 8% of the exam. Those are easy, low-effort points if you understand a handful of ideas, and easy points to lose if you have never thought about how an application actually gets from a Git repository onto a running cluster.
This domain is not about writing YAML by hand under time pressure. KCNA is a conceptual, multiple-choice exam (see the KCNA Exam Format breakdown). What it tests here is whether you understand the delivery pipeline of a cloud native application: how applications are defined declaratively, how they are packaged and configured with tools like Helm and Kustomize, how CI/CD automates the path to production, and what GitOps adds on top of all of it.
This guide walks the Cloud Native Application Delivery domain the way the KCNA blueprint frames it. If you want the full lay of the land first, start with the KCNA Exam Guide 2026 and the KCNA Study Guide, then come back here to go deep on delivery.
What the Cloud Native Application Delivery Domain Covers
The KCNA blueprint groups this domain into three connected ideas. Keep the whole map in view before diving in:
| Sub-topic | What the exam expects you to know |
|---|---|
| Application Definition & Configuration | Declarative manifests, ConfigMaps/Secrets, templating and packaging (Helm, Kustomize) |
| CI/CD Fundamentals | What continuous integration and continuous delivery/deployment mean, and the pipeline stages |
| GitOps | Git as the single source of truth, declarative reconciliation, pull vs push, Argo CD and Flux |
You are not expected to build a pipeline or author a Helm chart from scratch. The questions test whether you understand what each concept does and how the pieces connect. Keep that altitude in mind as we go.
Application Definition: Declarative Is the Whole Point
Everything in cloud native application delivery starts from one idea you have already met elsewhere in KCNA: declarative, desired-state configuration. You describe what you want — three replicas of an image, exposed on a Service, with a config file mounted — and Kubernetes controllers continuously reconcile reality toward that description. You do not script the steps.
An application definition in Kubernetes is a set of manifests — usually YAML — that describe objects such as Deployment, Service, ConfigMap, and Secret. A minimal example:
apiVersion: apps/v1
kind: Deployment
metadata:
name: web
spec:
replicas: 3
selector:
matchLabels: { app: web }
template:
metadata:
labels: { app: web }
spec:
containers:
- name: web
image: registry.example.com/web:1.4.2
envFrom:
- configMapRef: { name: web-config }Two supporting objects show up constantly in this domain:
- ConfigMap — non-sensitive configuration (env vars, config files) kept out of the container image so the same image runs in dev, staging, and prod with different settings.
- Secret — the same idea for sensitive values (tokens, passwords). On the KCNA, remember the nuance: by default Kubernetes Secrets are only base64-encoded, not encrypted, unless encryption at rest is enabled on the cluster.
The exam-worthy takeaway: decoupling configuration from the image is a core cloud native practice. It is what lets one immutable artifact move through environments unchanged.
Packaging and Templating: Helm and Kustomize
Raw manifests work, but real applications have many objects that repeat across environments. Two tools dominate the packaging conversation, and KCNA expects recognition-level familiarity with both.
Helm is the de facto package manager for Kubernetes — think “apt/yum for clusters.” It bundles manifests into a chart, parameterizes them with a values.yaml file, and installs a versioned release onto the cluster. You can upgrade, roll back, and uninstall a release as a unit.
helm repo add bitnami https://charts.bitnami.com/bitnami
helm install my-site bitnami/nginx --set replicaCount=3
helm upgrade my-site bitnami/nginx --set image.tag=1.4.2
helm rollback my-site 1Kustomize takes a different approach: instead of templating, it uses overlays to patch a common base set of manifests per environment. It is built into kubectl (kubectl apply -k), so no extra tool is required.
| Tool | Model | Best exam cue |
|---|---|---|
| Helm | Templating + package manager | Versioned releases, values.yaml, install/upgrade/rollback, chart repositories |
| Kustomize | Overlay/patch (template-free) | base + overlays, built into kubectl -k, no separate templating language |
For a deeper, hands-on treatment aimed at the CKA level, our Helm & Kustomize for the CKA Exam guide goes much further — but for KCNA, knowing what each tool is for and the Helm chart/release/values vocabulary is enough.
You may also see Operators and Custom Resource Definitions (CRDs) mentioned. At KCNA level, just recognize the pattern: a CRD extends the Kubernetes API with a new object type, and an Operator is a controller that manages that object — encoding operational knowledge (backups, upgrades, failover) as software. It is the same declarative, controller-driven model applied to complex applications.
CI/CD Fundamentals
CI/CD is the automation that carries code from a commit to a running workload. The two halves are often blurred, so pin down the distinction the exam likes:
- Continuous Integration (CI) — developers merge code frequently; each change triggers an automated build and test. The output is usually a tested container image pushed to a registry.
- Continuous Delivery (CD) — every change that passes CI is automatically prepared for release, but a human approves the final push to production.
- Continuous Deployment (CD) — the same pipeline, but the release to production is fully automated with no manual gate.
A typical cloud native pipeline looks like this:
| Stage | What happens | Typical output |
|---|---|---|
| Source | Developer commits to Git | New commit / pull request |
| Build | Compile, build the container image | Immutable image tagged by version/SHA |
| Test | Unit, integration, security scans | Pass/fail signal |
| Package | Push image to a registry; bump manifests/chart | Image in registry, updated deployment definition |
| Release/Deploy | Apply the new definition to the cluster | Running workload |
The cloud native emphasis is on immutable artifacts (build once, promote the same image through environments) and automation (no hand-editing production). KCNA will not ask you to configure a specific CI tool — it wants you to recognize what CI vs CD/CD means and why automating delivery reduces risk and toil.
GitOps: Git as the Single Source of Truth
GitOps is the concept this domain most loves to test, because it ties the whole exam together. GitOps applies the declarative, desired-state model to delivery itself: the entire desired state of the cluster lives in a Git repository, and an in-cluster agent continuously reconciles the live cluster to match Git.
The four widely cited GitOps principles are worth memorizing:
- Declarative — the whole system is described declaratively.
- Versioned and immutable — desired state is stored in Git, giving you history, review, and rollback (just
git revert). - Pulled automatically — software agents pull the approved state from Git.
- Continuously reconciled — agents constantly detect drift and correct it back to the declared state.
The key mechanism is pull-based deployment. Instead of a CI server pushing changes into the cluster with cluster credentials (push model), a GitOps agent inside the cluster pulls changes from Git (pull model). This is more secure — cluster credentials never leave the cluster — and it means any manual drift gets automatically reverted.
Two CNCF projects own this space, and KCNA expects you to recognize both:
| Tool | Note for the exam |
|---|---|
| Argo CD | Declarative GitOps CD tool with a UI showing sync status and drift; app-of-apps pattern |
| Flux | GitOps toolkit of controllers that reconcile Git → cluster; integrates Helm and Kustomize |
If a question describes “a controller in the cluster that watches a Git repo and automatically makes the cluster match it,” the answer is GitOps — and the tools are Argo CD or Flux.
CI/CD vs GitOps: Clearing Up the Confusion
Candidates frequently conflate these. Hold this distinction:
| Concept | Direction | Source of truth | Typical tools |
|---|---|---|---|
| Traditional CI/CD | Push — pipeline pushes to the cluster | The pipeline / imperative scripts | Generic CI servers, deploy scripts |
| GitOps | Pull — agent pulls from Git | A Git repository | Argo CD, Flux |
GitOps does not replace CI — you still build and test images in CI. GitOps replaces the deployment half: instead of the pipeline running kubectl apply, CI updates a manifest/chart version in Git, and the GitOps agent notices and reconciles. Remembering that GitOps is about the CD/deploy stage, driven by Git as the source of truth, answers most questions in this area.
How This Domain Fits the Cloud Native Model
Step back and the domain forms a clean pipeline that reuses ideas from the rest of KCNA:
- You define the application declaratively as manifests (Kubernetes Fundamentals).
- You package and configure it with Helm or Kustomize, decoupling config from the image.
- CI builds and tests an immutable image and pushes it to a registry.
- A change to the desired state is committed to Git.
- A GitOps agent (Argo CD/Flux) pulls that state and continuously reconciles the cluster.
- Controllers do the actual work of making desired state real (Container Orchestration).
Notice the recurring KCNA theme: declarative desired state plus continuous reconciliation. Application delivery is just that same pattern extended from individual objects to the entire delivery process. If you internalize that, the domain becomes almost intuitive.
Study Strategy for This Domain
Because this is the smallest domain, spend your time efficiently — a little targeted review yields all the available points:
- Nail the CI vs CD vs CD distinction (integration, delivery, deployment) — it is a favorite.
- Know Helm vocabulary — chart, release,
values.yaml, repository — and that Kustomize uses overlays and is built intokubectl. - Memorize the GitOps principles and the pull vs push distinction.
- Recognize Argo CD and Flux as the GitOps tools, both CNCF projects.
- Connect it to declarative desired state — the thread running through the whole exam.
Reading explains the concepts, but the KCNA rewards fast pattern recognition — 60 questions in 90 minutes. The most reliable way to find your weak spots is to answer realistic, exam-style questions and read the explanations. Our free KCNA practice questions are a good warm-up, and when you’re ready for full-length, timed conditions across every domain, the KCNA Certification Ready Mock Exam Bundle gives you structured mock exams with detailed explanations so you walk in knowing exactly where you stand.
Pair this with the broader Kubernetes Certification Path Guide 2026 if you plan to continue toward CKA or CKAD — where these delivery concepts become hands-on. The CKAD Deployments & Rolling Updates guide is a natural next step once you want to do rather than recognize.
Conclusion
Cloud Native Application Delivery may be the smallest KCNA domain, but it is the one that shows you the full journey of a cloud native application — from a declarative definition, through packaging with Helm or Kustomize, through CI that builds immutable images, to GitOps agents that continuously reconcile the cluster against Git. Every idea here is the same declarative, desired-state pattern you have seen throughout the exam, applied to the act of delivery itself.
Get the CI-vs-CD distinction, the Helm and Kustomize vocabulary, and the GitOps pull model straight, and roughly 8% of the exam becomes points you can answer in seconds. Combine this conceptual map with timed practice, and delivery questions become the fastest ones on your paper — freeing time for the heavier Fundamentals and Orchestration domains.
FAQ
How much of the KCNA exam is Cloud Native Application Delivery?
It is the smallest domain at roughly 8% of the exam. With 60 questions total, expect around 5 questions from this area — easy points if you know the concepts, easy losses if you skip them.
What is the difference between continuous delivery and continuous deployment?
Both automate the pipeline after CI. Continuous delivery prepares every passing change for release but keeps a manual approval before production. Continuous deployment removes that gate — every change that passes automated tests is automatically released to production.
Do I need to write Helm charts or YAML for the KCNA?
No. KCNA is a conceptual, multiple-choice exam. You need to recognize what Helm and Kustomize do — charts, releases, values, overlays — not author them. Hands-on manifest and Helm work shows up later on CKA and CKAD.
What exactly is GitOps?
GitOps is an operational model where the entire desired state of your system lives in Git, and an in-cluster agent continuously pulls that state and reconciles the live cluster to match it. Its four principles are: declarative, versioned/immutable, pulled automatically, and continuously reconciled.
What is the difference between Argo CD and Flux?
Both are CNCF GitOps tools that reconcile a cluster to a Git repository. Argo CD is an application-centric CD tool with a rich UI that visualizes sync status and drift. Flux is a toolkit of composable controllers and integrates tightly with Helm and Kustomize. For KCNA, recognizing both as GitOps tools is enough.
Is GitOps the same as CI/CD?
No. CI/CD is the broader automation of build, test, and deploy. GitOps specifically reimplements the deploy (CD) half using a pull-based agent and Git as the single source of truth, replacing a pipeline that pushes changes into the cluster. You still use CI to build and test images before Git is updated.