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.
Worked example from the KCNA bank
lock_openFree sampleCloud Native Application Deliverymedium
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.