How to pass Kubernetes and Cloud Native Associate (KCNA)
16 min read4 domains coveredFree practice, no sign-up
The Kubernetes and Cloud Native Associate (KCNA) is the entry point to the CNCF certification ladder and the foundation beneath the CKA, CKAD, and CKS. It is a multiple-choice exam, not a hands-on lab, so it tests whether you understand how Kubernetes and the wider cloud native ecosystem work rather than whether you can drive kubectl under time pressure. Most questions describe a small cluster situation and ask which object, Service type, probe, or pattern fits it.
It suits developers, operators, and technical people moving into the cloud native world: anyone who needs a credible grounding before the hands-on Kubernetes exams, or who works around Kubernetes without administering it daily. If you can already explain what a Deployment reconciles and why a readiness probe is not a liveness probe, much of the exam will feel familiar. If those ideas are new, the gap is closable in a few focused weeks because the blueprint is broad rather than deep.
The exam rewards understanding the mechanism. Many options name a real Kubernetes object that almost fits the scenario, so the skill being tested is matching the object to the requirement, not recalling a definition. Practise on scenario questions that explain every option, so you learn why a NodePort is the wrong layer for host-based HTTP routing and why a StatefulSet, not a Deployment, is what a database with stable identity needs.
KCNA rewards matching the right Kubernetes object or pattern to a stated requirement, not memorising definitions or kubectl flags.
Difficulty
Foundational
Best for
Developers, operators, and technical staff new to Kubernetes and the cloud native ecosystem who want a recognised foundation before the hands-on CKA, CKAD, and CKS exams.
Prerequisites
None. Comfort with containers and basic command-line concepts helps but is not assumed.
Not published by CNCF
Questions
90 min
Time allowed
75%
Pass mark
$250
Exam cost (USD)
305
Practice questions
How this exam thinks
Three habits separate a pass from a fail on the KCNA, and none of them is about memorising more YAML.
First, the exam asks which object or setting fits the situation, not which one is generally good. The questions are short scenarios, and several options name real Kubernetes objects that could plausibly appear in a cluster. Only one satisfies the requirement as written. The real test is matching a capability to a need: a workload that needs stable network identity and ordered rollout points to a StatefulSet, not a Deployment; an internal-only service points to ClusterIP, not LoadBalancer. Read the requirement in the last line first, then judge each option against that requirement, not against general usefulness.
Second, the exam keeps returning to a handful of precise distinctions that candidates routinely blur. Liveness, readiness, and startup probes each do a different job: liveness restarts a container, readiness removes a Pod from Service endpoints without restarting it, and startup gates the other two while a slow app boots. Requests govern scheduling and limits govern runtime capping, and together they set the Guaranteed, Burstable, or BestEffort QoS class that decides eviction order. CRI, CNI, and CSI are runtime, network, and storage interfaces respectively and are constantly swapped in distractors. Make these automatic rather than reasoning them out each time.
Third, the exam expects you to respect the declarative, reconciling model. You describe desired state in a spec and a controller drives actual state toward it; status is written by the system, not by you. Options that describe imperatively poking a live object when the scenario calls for changing the declared spec are usually the distractor. The same instinct covers ownership: kube-proxy is not an Ingress controller, a PersistentVolumeClaim is not a PersistentVolume, and a ConfigMap is not a Secret. When two options look right, pick the one that respects which component owns which part of the system.
What each domain tests and how to study it
The KCNA blueprint is split across 4 domains. Weights are the official share of the exam; see the official exam guide for the authoritative breakdown.
What you must be able to do. Name the core Kubernetes objects and control-plane components, match a workload requirement to the controller that satisfies it, and explain the declarative reconciliation loop that drives actual state toward desired state.
In one sentenceThe vocabulary the rest of the exam is written in: Pods and the controllers that manage them, the control-plane and node components, the declarative API, and the Pod and rollout lifecycle.
Recall check: answer these from memory first
Give a one-line rule for choosing between a Deployment, a StatefulSet, a DaemonSet, and a Job by the workload property each fits.
Name the control-plane components and the node components, and say what each is responsible for.
Explain what spec and status each hold, and who writes status.
Describe how a rolling update proceeds and what maxSurge and maxUnavailable control.
What it tests. The core objects and how they relate: Pods, ReplicaSets, Deployments, StatefulSets, DaemonSets, Jobs and CronJobs, and which workload property selects each. It covers the control-plane and node components (kube-apiserver, etcd, scheduler, controller-manager, kubelet, kube-proxy), the declarative API with its apiVersion, kind, spec and status shape, how the scheduler places Pods, and the Pod lifecycle including rolling updates and rollback.
How to study it. Get the objects exact first, because every later domain assumes them. Be able to say in one line why a StatefulSet differs from a Deployment, when a DaemonSet is the right controller, and what a Job is for. Then learn the cluster as a reconciliation loop, not a set of commands: a controller continuously compares desired spec against actual status and acts on the difference. Drill scenario questions until you can pick the controller from the workload property rather than from familiarity.
Easy to confuse
Deployment versus StatefulSet versus DaemonSet. A Deployment runs interchangeable, stateless replicas; a StatefulSet gives each replica a stable identity, ordered rollout, and its own persistent storage; a DaemonSet runs one Pod per node. Pick by the workload property in the scenario (stable identity, per-node coverage, or interchangeable replicas), not by which object you see most often.
spec versus status. The spec is the desired state you declare; the status is the observed state a controller writes. The exam plants a distractor that has the user setting status or a controller reading only the spec, when the reconciliation loop compares the two.
Declarative apply versus imperative commands. Declarative apply submits the desired spec and lets a controller reconcile it, so the change is repeatable and version-controllable; an imperative command mutates a live object directly. When the scenario values repeatability or GitOps, the declarative option is the one the exam wants.
Worked example from the KCNA bank
lock_openFree sampleKubernetes Fundamentalseasy
A cluster administrator needs a log-collection agent to run on every node, including any new node that later joins the cluster, with exactly one copy of the agent per node. Which Kubernetes workload object is purpose-built to guarantee one Pod on each node automatically?
AA Deployment, because it keeps a fixed number of identical Pod replicas running across the cluster
BA StatefulSet, because it gives each Pod a stable network identity tied to a specific node
CA Job, because it runs one Pod per node until each completes its task
DA DaemonSet, because it schedules one copy of the Pod onto every eligible node and onto new nodes as they joincheck_circle Correct
A DaemonSet runs exactly one copy of a Pod on every eligible node, including nodes that join later. The DaemonSet controller watches the set of nodes and reconciles one matching Pod per eligible node, adding Pods when nodes join and removing them when nodes leave, which is why it fits cluster-wide agents like log or metrics collectors.
Why A is wrong: A Deployment maintains a chosen replica count and lets the scheduler place those Pods anywhere, so it is tempting for any 'run this everywhere' need, but it cannot guarantee one Pod per node and will not react to new nodes joining.
Why B is wrong: A StatefulSet provides ordered, stably named Pods for stateful apps, which sounds node-related, but its replica count is fixed and its Pods are not placed one-per-node, so it does not track node membership.
Why C is wrong: A Job runs Pods to completion for batch work, which can feel like a per-node task, but it targets a completion count rather than node coverage and does not maintain a long-running agent on every node.
Why D is correct: A DaemonSet ensures each eligible node runs exactly one copy of the Pod, and it automatically adds a Pod to any node that later joins, which is precisely the node-agent pattern described.
What you must be able to do. Choose the right Service type and networking object for a stated exposure need, secure access to the cluster and its workloads, provide persistent storage, and diagnose common workload failures from their symptoms.
In one sentenceHow Kubernetes runs and connects workloads: the Service and networking model, cluster and container security, persistent storage, autoscaling and QoS, and troubleshooting the states a broken workload reports.
Recall check: answer these from memory first
Give a one-line rule for choosing between ClusterIP, NodePort, LoadBalancer, and Ingress from an exposure requirement.
Map ImagePullBackOff, CrashLoopBackOff, Pending, and OOMKilled each to its most likely cause and next diagnostic step.
Explain how requests and limits set the Guaranteed, Burstable, and BestEffort QoS classes and what that means for eviction.
Distinguish a PersistentVolume, a PersistentVolumeClaim, and a StorageClass in one line each.
What it tests. The networking model and Service types (ClusterIP, NodePort, LoadBalancer, ExternalName, and Ingress for layer-7 routing), the security controls that gate the API and the workloads (authentication, authorisation, admission, RBAC, ServiceAccounts, NetworkPolicy, security context), storage through PersistentVolumes, PersistentVolumeClaims and StorageClasses, scaling and Quality of Service classes, container isolation primitives, and reading the cause of a failure from its symptom.
How to study it. This is the second largest domain and the richest in near-miss distractors, so spend real time here. Make Service-type selection automatic: internal-only is ClusterIP, node-port exposure is NodePort, a cloud external address is LoadBalancer, host-based HTTP routing is Ingress. Learn the failure states as a lookup from symptom to cause: ImagePullBackOff is a registry or image-name problem, CrashLoopBackOff is the container exiting after start, Pending is unschedulable, OOMKilled is a breached memory limit. Tie requests and limits to the resulting QoS class and eviction order.
Easy to confuse
NodePort versus Ingress. A NodePort exposes a service on a port of every node at layer 4; an Ingress provides layer-7 host and path based HTTP routing through an Ingress controller. When the requirement is name or path based HTTP routing, the answer is Ingress, and a NodePort distractor is the trap.
Liveness versus readiness versus startup probe. A failing liveness probe restarts the container; a failing readiness probe removes the Pod from Service endpoints without restarting it; a startup probe gates the other two while a slow application boots. Match the probe to whether the symptom needs a restart or just removal from traffic.
Requests versus limits. A request is what the scheduler reserves and places the Pod against; a limit is the ceiling the runtime enforces, and breaching a memory limit gets the container OOMKilled. The exam treats them as one knob in a distractor; they govern scheduling and runtime capping respectively.
PersistentVolume versus PersistentVolumeClaim. A PersistentVolume is the actual storage resource in the cluster; a PersistentVolumeClaim is a workload's request to bind one, optionally satisfied dynamically by a StorageClass. The exam swaps the two, or has a Pod mount a PersistentVolume directly instead of through a claim.
kube-proxy versus an Ingress controller. kube-proxy programs the node so Service virtual IPs route to backing Pods at layer 4; an Ingress controller is a separate component that terminates and routes HTTP at layer 7. Treating kube-proxy as what fulfils an Ingress is a common trap.
Worked example from the KCNA bank
lock_openFree sampleContainer Orchestrationmedium
A team runs a Redis cache Pod that only other Pods inside the same cluster need to reach. They want a stable virtual IP and DNS name for the cache, but the cache must never be reachable from outside the cluster. Which Service type meets this requirement with the least exposure?
AA ClusterIP Service, which allocates an internal virtual IP and cluster DNS name reachable only from within the cluster.check_circle Correct
BA NodePort Service, which reserves a port on every node so internal Pods can connect through any node address reliably.
CA LoadBalancer Service, which provisions an external cloud load balancer to front the cache with a stable public address.
DAn ExternalName Service, which maps the cache name to an external DNS record through a returned CNAME entry.
Select ClusterIP when a workload only needs a stable internal address reachable from within the cluster. ClusterIP is the default Service type and allocates a virtual IP from the service CIDR plus a cluster DNS name that kube-proxy routes only to backing Pods, so traffic never leaves the cluster boundary.
Why A is correct: ClusterIP provides a stable internal virtual IP and DNS record while remaining unreachable from outside the cluster, which exactly matches an internal-only cache.
Why B is wrong: NodePort is tempting because it also gives a stable target, but it opens a port on every node's external IP, exposing the cache beyond the cluster, which the requirement forbids.
Why C is wrong: LoadBalancer looks safe because it also yields a stable address, but it provisions an externally reachable cloud load balancer, violating the internal-only constraint.
Why D is wrong: ExternalName seems relevant because it involves DNS, but it aliases to an external hostname rather than fronting an in-cluster Pod, so it does not expose the local cache at all.
What you must be able to do. Explain GitOps and continuous delivery for containerised workloads, choose a deployment strategy for a stated risk requirement, and package and configure an application across environments.
In one sentenceHow cloud native applications ship: GitOps and pull-based delivery, CI/CD pipelines, deployment strategies chosen by blast radius, and packaging with Helm and Kustomize.
Recall check: answer these from memory first
Explain how GitOps differs from a push-based pipeline and name the reconciling agents that implement it.
Match recreate, rolling update, blue-green, and canary each to the downtime and rollback profile it gives.
Distinguish how Helm and Kustomize each customise configuration across environments.
What it tests. GitOps with Git as the single source of truth and continuous reconciliation by Argo CD or Flux, continuous integration and delivery for containers with projects such as Tekton and Argo Workflows, deployment strategies (recreate, rolling, blue-green, canary, and progressive delivery) chosen by downtime and rollback needs, packaging and configuration with Helm charts and Kustomize overlays, and inspecting a running application through logs, exec, port-forward, and ephemeral debug containers.
How to study it. Learn GitOps as a decision, not a tool list: when the scenario values auditability, rollback, and a declarative source of truth, the answer is the pull-based reconciling model, not a push from a pipeline. Match each deployment strategy to its risk profile so you can reason about downtime, rollback speed, and blast radius rather than reciting definitions. Keep Helm and Kustomize distinct: templating with values versus overlaying patches on a base.
Easy to confuse
GitOps pull model versus a push-based pipeline. In GitOps an in-cluster agent continuously reconciles the cluster against a Git repository, so Git is the source of truth and drift is corrected automatically; a push pipeline applies changes from outside and does not reconcile. The exam signals GitOps with auditability, rollback, and declarative-source requirements.
Blue-green versus canary deployment. Blue-green switches all traffic between two full environments at once for instant rollback; canary shifts a small percentage of traffic to the new version and grows it while watching metrics. Choose by whether the requirement is instant cutover or gradual, measured exposure.
Helm versus Kustomize. Helm packages an application as a templated chart parameterised by values; Kustomize layers patches over a plain base with no templating. When the scenario wants environment overlays without a templating engine, Kustomize is the answer the exam points at.
A platform team wants to adopt GitOps for cluster configuration. Which statement best captures the defining principle that distinguishes GitOps from other delivery approaches?
AA Git repository holds the declared desired state, and an in-cluster agent continuously reconciles the running state to match what is committed.check_circle Correct
BA CI server holds the authoritative configuration and issues kubectl apply commands to the cluster whenever a build succeeds.
CDevelopers connect to the cluster with kubectl and make live changes directly, then export the result back into a Git repository as a backup.
DContainer images are signed and stored in a registry, and the cluster pulls the newest image tag on a fixed schedule regardless of any repository.
Understand that GitOps means a Git-declared desired state continuously reconciled into the cluster by an agent. GitOps rests on two pillars: a declarative desired state versioned in Git, and a reconciliation loop running in or against the cluster that continuously drives actual state to match the committed state, making Git the single source of truth.
Why A is correct: This is correct because GitOps uses a versioned declarative source of truth in Git and a reconciliation agent that continuously converges actual cluster state towards the committed desired state.
Why B is wrong: This is tempting because CI pipelines do deploy to clusters, but it describes a push model where an external system imperatively applies changes rather than a Git repository being the declarative source of truth that the cluster reconciles against.
Why C is wrong: This inverts the flow and is tempting because it involves Git, but here Git is a passive backup rather than the authoritative source, so live manual edits are the real source of truth, which GitOps forbids.
Why D is wrong: This is tempting because it uses the word pull, but it describes image polling, not reconciliation of declared manifests from Git, and it ignores the declarative desired-state repository entirely.
What you must be able to do. Describe the principles of cloud native architecture, explain observability and its signals, reason about serverless and service-mesh patterns, and place well-known CNCF projects at the correct maturity level.
In one sentenceThe wider ecosystem and its ideas: cloud native principles, observability with metrics, logs and traces, serverless and service-mesh patterns, and CNCF project maturity and governance.
Recall check: answer these from memory first
Name the three primary observability signals and say what each answers about a system.
Distinguish Prometheus, OpenTelemetry, and a tracing backend by the role each plays.
State the three CNCF maturity levels in order and place two well-known projects on the ladder.
Explain what a service mesh provides and one reason it might not be worth its operational cost.
What it tests. The defining principles (immutable infrastructure, declarative configuration, loose coupling, resilience, microservices), observability built on metrics, logs and traces with Prometheus and OpenTelemetry, serverless and event-driven patterns with Knative and KEDA, what a service mesh provides and its cost, and the CNCF landscape with Sandbox, Incubating and Graduated maturity levels and community governance. On the current outline, observability is examined inside this domain rather than as a domain of its own.
How to study it. Learn the three observability signals and which project owns which role: Prometheus scrapes metrics with a pull model, OpenTelemetry is the vendor-neutral instrumentation standard, and traces follow a request across services. Keep the difference between monitoring and observability clear. For the ecosystem, learn the maturity ladder and be able to place well-known projects on it, because a project at the wrong maturity level is a hard correctness trap. Treat a service mesh as a cost-benefit decision, not a default.
Easy to confuse
Metrics versus logs versus traces. Metrics are aggregated numeric time series good for alerting on trends; logs are discrete timestamped events good for detail; traces follow one request across services to locate latency. The exam asks which signal answers the question being posed, not which is best in general.
Monitoring versus observability. Monitoring watches known signals against thresholds you defined in advance; observability is the property that lets you ask new questions about unforeseen behaviour from the data emitted. The exam pairs the requirement (known dashboards versus debugging the unknown) with the term.
Sandbox versus Incubating versus Graduated. Sandbox is early and experimental, Incubating has real adoption and is maturing, and Graduated has proven production maturity and broad adoption. Placing a Graduated project such as Prometheus or Kubernetes in the Sandbox tier, or the reverse, is a hard correctness failure the exam plants deliberately.
Knative versus KEDA. Knative provides serverless request-driven workloads with scale-to-zero on a cluster; KEDA drives event-driven autoscaling from external event sources such as a queue. Match by whether the trigger is inbound requests or an external event backlog.
Worked example from the KCNA bank
lock_openFree sampleCloud Native Architectureeasy
A platform team follows the principle of immutable infrastructure for their cloud native workloads. When they need to change the configuration of a running service, which approach is consistent with this principle?
AOpen a shell into each running container and edit the configuration files directly so no redeploy is needed
BAttach a configuration volume and hot-patch the binary on each host while the service keeps serving
CBuild a new container image with the change and roll out fresh replacement instances, discarding the old onescheck_circle Correct
DRun a configuration management agent that periodically reconciles and rewrites files on the live servers
Immutable infrastructure replaces instances with new artifacts rather than modifying running ones in place. The defining behaviour of immutable infrastructure is that no change is applied to a live instance; instead a new versioned artifact is built and deployed as a replacement, which eliminates configuration drift and makes rollbacks predictable.
Why A is wrong: Editing files inside a live container is tempting because it seems faster, but it mutates the running instance in place, which is the mutable pattern immutable infrastructure exists to avoid.
Why B is wrong: Hot-patching a running binary sounds efficient and zero-downtime, but it modifies existing instances rather than replacing them, so it violates immutability and causes environment drift.
Why C is correct: Immutable infrastructure means a running instance is never modified in place; a change produces a new image or artifact that replaces the existing instances entirely, which is exactly what this describes.
Why D is wrong: An agent that continuously mutates live servers is a classic mutable-infrastructure workflow; it changes instances in place instead of replacing them, so it is the opposite of the immutable approach.
A study plan that works
Map the blueprint and set a date
Day 1
Read the official CNCF and Linux Foundation curriculum and the four domains with their weights. Book a provisional exam date now: a fixed date turns open-ended study into a plan and is the single biggest predictor of actually sitting the exam.
Lock the fundamentals (Kubernetes Fundamentals)
Weeks 1-2
This is the largest domain and the base for the rest, so give it the most time. Get the objects and controllers exact, learn the control-plane and node components, and internalise the declarative reconciliation loop. Use the recall prompts in this guide: cover the summary, answer from memory, then reveal.
Go deep on orchestration (Container Orchestration)
Weeks 2-3
The second largest domain and the richest in near-miss distractors. Drill Service-type selection, the probe distinctions, requests-versus-limits and QoS, storage objects, and the symptom-to-cause map for failing workloads. Use scenario questions, not flashcards alone.
Cover delivery and architecture (Application Delivery, Architecture)
Week 3
Work through GitOps, CI/CD, deployment strategies, and packaging, then the cloud native principles, observability signals, serverless, service mesh, and CNCF maturity levels. These are lower weight and largely conceptual, so a focused pass plus practice is enough. Note that observability sits inside the architecture domain.
Practise on scenarios with every answer explained
Week 4
Move to full practice sets and read the explanation for every question, including the ones you got right. The exam tests matching an object to a requirement among plausible options, so understanding why each near-miss is wrong is where the marks are.
Find and close your weak domains
Week 4
Use your per-domain accuracy to drill the domains dragging you down rather than re-reading what you already know. Repeat until every domain clears the pass line with margin.
Sit a timed mock and review it
Week 5
Take at least one full timed mock to rehearse pacing and flag-and-return. Treat the score as a per-domain readiness signal, then review every missed question before booking or sitting.
Know when you're ready
Readiness for the KCNA is a score on questions you have not seen before, not a feeling that the material is familiar. Those are different things, and the gap between them is where people fail. Re-reading notes builds fluency, and fluency feels like knowledge, so confidence rises while real recall does not. The fix is to test yourself: if you can answer fresh scenario questions and explain why the wrong objects are wrong, you know it; if you can only nod along to an explanation, you do not yet.
Be especially wary of early confidence on a foundational exam. The material is broad rather than deep, so a first pass feels like mastery, but the questions reward picking the right object among plausible near-misses, which only practice exposes. Trust your measured per-domain accuracy over your gut, and set the bar at clearing every domain comfortably on unseen questions across more than one session, not scraping the pass mark once.
This guide gives you the map. The practice bank is where you find out whether you can navigate it, with an explanation of why the right answer is right and every wrong one is wrong on every question. Readiness scoring tells you when you are there. Not before.
Ready to put this into practice?
Free KCNA questions, every answer explained. No sign-up.
Read the last line of the question first. It tells you the requirement being tested, so you can read the scenario looking for the object that satisfies it rather than memorising detail.
Choose the object that fits the requirement, not merely a real one. Several options name genuine Kubernetes objects; the exam wants the best fit for the stated need.
When the scenario needs stable identity or ordered storage, think StatefulSet, not Deployment. The workload property, not familiarity, selects the controller.
Separate the probes: liveness restarts, readiness removes from endpoints, startup gates the others. Match the probe to whether the symptom needs a restart or just removal from traffic.
Keep CRI, CNI, and CSI straight as runtime, network, and storage. Distractors swap them deliberately.
Flag and move on. Do not lose time on one hard item when easier marks are waiting; the timer rewards covering every question first.
Verify a CNCF project's maturity level rather than guessing. A Graduated project placed in Sandbox, or the reverse, is a planted trap.
Frequently asked questions
Is KCNA hard?
It is a foundational, multiple-choice exam with no hands-on labs, so it is broad rather than deep. The difficulty is in choosing the object or setting that fits the scenario among plausible near-misses, which is why scenario practice that explains every option matters more than memorising definitions.
How long should I study for KCNA?
Most candidates with some container or cloud background are ready in three to five weeks of focused study. Less background means more time on Kubernetes Fundamentals and Container Orchestration, which is where the weight sits.
Do I need hands-on Kubernetes experience to pass?
No. The exam is conceptual and multiple choice. Understanding how the objects and components work is enough; you are not asked to operate a live cluster. Some hands-on practice still helps the concepts stick.
What is the pass mark for KCNA?
The published pass mark is in the facts panel above. Aim to clear every domain comfortably on unseen questions rather than scraping the target once, because a broad exam can hide a weak domain behind a strong one.
Which domains should I focus on?
Kubernetes Fundamentals and Container Orchestration together make up most of the exam, so they deserve the most time. Cloud Native Application Delivery and Cloud Native Architecture are smaller and largely conceptual, and observability is examined inside the architecture domain.
Is observability its own domain on the KCNA?
Not on the current outline. An earlier version of the exam had a standalone observability domain, but it has been folded into Cloud Native Architecture. Study observability, but expect those questions under the architecture domain rather than a separate one.
Does KCNA lead to the CKA, CKAD, or CKS?
Yes. KCNA is the associate-level foundation beneath the hands-on Kubernetes exams. It is a sensible first step that builds the conceptual grounding those performance-based exams assume.
How many practice questions should I do before booking?
Enough that every domain clears the pass line with margin on questions you have not seen before, and that a full timed mock feels comfortable on pacing. Quality of review matters more than raw volume: read the explanation on every question.
Examworthy is not affiliated with or endorsed by Cloud Native Computing Foundation. This guide is original study material based on the public exam blueprint. We never reproduce live exam items. KCNA and related marks belong to their respective owners.
