KCNA study guide

KCNA is a breadth exam. It does not ask you to fix a cluster — it asks whether you know what a cluster is made of, which object solves which problem, and where in the CNCF landscape a given tool sits. Ninety minutes, online proctored, multiple choice.

This guide is organised by the official domain weights, heaviest first. That ordering matters more than it looks: 44% of the exam sits in one domain, and 72% sits in two. Study time should follow the weighting, not your curiosity.

Kubernetes Fundamentals — 44%

Nearly half the exam. Official sub-topics: core concepts, administration, scheduling, containerization.

The control plane, component by component

Be able to say what each process does and what breaks when it stops:

• kube-apiserver — the only component that talks to etcd, and the front door for everything else. All state changes go through it. Stop it and the cluster keeps running but becomes unmanageable.
• etcd — the consistent key-value store holding all cluster state. Not a component you interact with directly; the thing you back up.
• kube-scheduler — decides which node an unscheduled Pod binds to. Stop it and existing workloads are fine, new Pods sit Pending.
• kube-controller-manager — runs the reconciliation loops (node, replication, endpoints, service accounts). The engine behind “desired state”.
• cloud-controller-manager — the cloud-provider-specific loops, split out so the core is provider-agnostic.

On every node: kubelet (the agent that actually starts containers and reports status), kube-proxy (maintains the network rules behind Services), and a container runtime (containerd or CRI-O, spoken to over the CRI).

The declarative model

This is the concept the exam keeps circling. You write desired state; controllers reconcile towards it continuously. Nothing is a one-shot command. Know the difference between:

• imperative — kubectl run, kubectl create — you tell the cluster what to do
• declarative — kubectl apply -f — you tell the cluster what you want to exist

Every object has apiVersion, kind, metadata, spec (desired), and — once the cluster touches it — status (observed). The controller’s whole job is closing the gap between the two.

Workload objects

Know which one to reach for:

The distinction the exam actually probes is Deployment vs StatefulSet: identity and storage. A Deployment’s Pods are interchangeable and get random names; a StatefulSet’s are web-0, web-1, created and deleted in order, each keeping its own PersistentVolumeClaim.

Scheduling

The scheduler runs filtering (which nodes can take this Pod) then scoring (which is best), then binds. The mechanisms that influence it:

• resource requests — the number the scheduler actually uses to place a Pod. Limits are enforced at runtime by the kubelet and the runtime, not at scheduling time. Exceeding a memory limit gets the container OOM-killed; exceeding a CPU limit gets it throttled. This request-vs-limit distinction is worth being precise about.
• nodeSelector — the crude version: simple label matching.
• affinity / anti-affinity — the expressive version. Node affinity constrains against node labels; Pod affinity/anti-affinity constrains against other Pods’ labels, which is how you spread replicas across zones. requiredDuringScheduling... is hard, preferredDuringScheduling... is soft.
• taints and tolerations — the inverse mechanism. A taint on a node repels Pods; a toleration on a Pod lets it land anyway. Effects: NoSchedule, PreferNoSchedule, NoExecute (which also evicts already-running Pods).

Also know QoS classes, because they decide eviction order under pressure: Guaranteed (requests == limits for every container), Burstable (requests set, lower than limits), BestEffort (nothing set — first to be evicted).

Containerization

Containers are Linux primitives, not virtual machines: namespaces for isolation (pid, net, mnt, uts, ipc, user) and cgroups for resource limits. Images are layered and immutable; a container is a writable layer over a read-only stack.

Know the interfaces, because they explain why the ecosystem looks the way it does:

• OCI — image and runtime specifications
• CRI — Container Runtime Interface, how the kubelet talks to containerd/CRI-O
• CNI — Container Network Interface, how networking is plugged in
• CSI — Container Storage Interface, how storage is plugged in

Kubernetes removed built-in Docker support in v1.24 via dockershim removal. Docker-built images still run fine — they’re OCI images. That distinction between the image format and the runtime shim is a classic exam trap.

Container Orchestration — 28%

Official sub-topics: networking, security, troubleshooting, storage.

Networking

The Kubernetes network model, stated as rules:

1. Every Pod gets its own IP.
2. Pods can reach every other Pod without NAT.
3. Agents on a node can reach all Pods on that node.

Containers inside a Pod share a network namespace — they reach each other on localhost and must not collide on ports.

Service types, in order of exposure:

A Service selects Pods by label and tracks the healthy ones in Endpoints (or EndpointSlices). Understand that a Service is not a process — it is rules that kube-proxy programs into iptables/IPVS.

Above Services, Ingress does HTTP/HTTPS routing (host and path rules, TLS termination) and requires an ingress controller to be installed — the resource alone does nothing. The Gateway API is its more expressive successor, with role-oriented resources (GatewayClass, Gateway, HTTPRoute). Know that Gateway API exists and why it was created.

DNS: CoreDNS gives every Service a name of the form <service>.<namespace>.svc.cluster.local. Same-namespace lookups can use just <service>.

NetworkPolicy is the Pod-level firewall — but it is enforced by the CNI plugin. If your CNI doesn’t implement it, the policy is silently inert. Default is allow-all; once a Pod is selected by any policy, it becomes default-deny for that direction.

Storage

• Volume — tied to the Pod lifetime. emptyDir dies with the Pod, configMap and secret project data in, hostPath mounts from the node (and is a security smell).
• PersistentVolume (PV) — a piece of storage in the cluster, provisioned by an admin or dynamically.
• PersistentVolumeClaim (PVC) — a request for storage by a user. The indirection is the point: workloads ask for capacity and access mode without knowing the backend.
• StorageClass — enables dynamic provisioning and carries the reclaimPolicy (Delete vs Retain) and provisioner.

Access modes: ReadWriteOnce (one node), ReadOnlyMany, ReadWriteMany, ReadWriteOncePod. Note that RWO is per node, not per Pod — a distinction the exam likes.

CSI is why none of this is baked into the core anymore: storage drivers ship out-of-tree.

Security

At associate level this is concepts, not YAML:

• Authentication — Kubernetes has no user objects. Identity comes from certificates, bearer tokens, or an external provider. ServiceAccounts are the in-cluster identity for workloads.
• Authorization — RBAC is the one to know cold: Role and RoleBinding are namespaced, ClusterRole and ClusterRoleBinding are cluster-wide. A RoleBinding can bind a ClusterRole into a single namespace, which is the common idiom.
• Admission control — runs after authn/authz. Mutating admission changes the object; validating admission accepts or rejects it. This is where policy engines hook in.
• Pod Security Standards — privileged, baseline, restricted, applied through Pod Security Admission at the namespace level. These replaced PodSecurityPolicy, which was removed in v1.25.
• Secrets are base64-encoded, not encrypted, unless you enable encryption at rest.

Troubleshooting

Know the flow and what each command tells you: kubectl get for state, kubectl describe for events and the reason something is stuck, kubectl logs (with --previous for a crashed container), kubectl exec to get inside.

Recognise the common Pod states by cause:

• Pending — unschedulable. Insufficient resources, an unsatisfied taint, or an unbound PVC.
• ImagePullBackOff / ErrImagePull — wrong name, wrong tag, or missing registry credentials.
• CrashLoopBackOff — the container starts and exits repeatedly. The app is failing, not Kubernetes.
• OOMKilled — exceeded its memory limit.

Cloud Native Application Delivery — 16%

Official sub-topics: application delivery, debugging.

GitOps is the headline concept: Git as the single source of truth for declarative infrastructure, with a controller in the cluster continuously reconciling actual state against the repository. Pull-based, not push-based — the cluster fetches its desired state rather than CI pushing into it. Argo CD and Flux are the two CNCF projects to be able to name.

Deployment strategies, and what each trades:

• Rolling update — the Kubernetes default. maxSurge and maxUnavailable control the pace; both versions serve traffic during the roll.
• Recreate — all down, then all up. Downtime, but no version overlap.
• Blue/green — two full environments, cut traffic over at once. Fast rollback, double the resources.
• Canary — a slice of traffic to the new version first, widen if the metrics hold.

Packaging and templating: Helm (charts, values, releases) and Kustomize (overlays and patches, no templating language, built into kubectl). Know the philosophical difference — Helm templates, Kustomize patches.

CI/CD in this context: the pipeline builds and pushes an image, then either applies manifests or updates the Git repo that a GitOps controller watches. Argo and Tekton are the CNCF projects in this space.

Cloud Native Architecture — 12%

Official sub-topics: observability, cloud native ecosystem and principles, cloud native community and collaboration.

Principles

Autoscaling, serverless, community and governance, roles and personas, open standards. The ideas worth being able to articulate:

• Immutable infrastructure — you replace instances rather than mutate them.
• Declarative APIs and reconciliation — the loop, again.
• Loose coupling — microservices, and the operational cost that comes with them.
• Elasticity — scale with demand, in both directions.

Autoscaling has three distinct axes, and mixing them up is a common error:

Observability

The pillars — metrics, logs, traces — and the projects that own them: Prometheus for metrics (pull-based, time-series, PromQL), Fluentd/Fluent Bit for log collection, Jaeger for distributed tracing, OpenTelemetry as the vendor-neutral instrumentation standard that increasingly spans all three. Grafana visualises.

Know liveness vs readiness vs startup probes, because this is asked in some form nearly everywhere:

• liveness — is it alive? Failure restarts the container.
• readiness — should it get traffic? Failure removes it from Service endpoints; no restart.
• startup — is it still booting? Suppresses the other two until it passes.

Also cost management — a topic that surprises people by being in scope. Rightsizing requests, the consequences of overprovisioning, and the FinOps idea that cost is an engineering signal.

The ecosystem

CNCF is part of the Linux Foundation. Projects move through sandbox → incubating → graduated; be able to place the big ones. Graduated includes Kubernetes, Prometheus, Envoy, containerd, etcd, Helm, Argo, Cilium. The CNCF Landscape is the map, and the exam expects you to know roughly which box a project sits in.

Service mesh belongs here: sidecar or node proxy handling mTLS, retries, traffic splitting, and telemetry without the application knowing. Istio and Linkerd are the names.

Serverless / Knative — scale-to-zero, event-driven, the CNCF serverless story.

Logistics — verified facts only

From the official Linux Foundation certification page:

• Online, proctored, multiple choice
• 90 minutes
• No prerequisites; positioned as beginner-level
• Certification is valid for 2 years
• 12-month eligibility window to schedule and sit
• One retake included
• $250 exam-only at list price

The number of questions and the passing score are not published on that page. Anyone quoting you a specific figure with confidence is repeating hearsay — check the Candidate Handbook rather than a blog post, and treat the requirement as “know the material” rather than “clear a number”.

A study sequence

1. Read the official curriculum PDF first, not last. It is the actual contract, and it is published in the CNCF curriculum repository on GitHub. Every domain heading in this guide comes from it.
2. Take LFS250 (Kubernetes and Cloud Native Essentials) — the free-to-audit companion course, and the one bundled with the exam. It is mapped to the curriculum.
3. Run a cluster. kind or minikube on a laptop is enough. The exam is multiple choice, but the questions are much easier when you have watched a rolling update happen and broken a Pod on purpose.
4. Read kubernetes.io/docs/concepts end to end. It is better written than most paid material and it is the source the exam is drawn from.
5. Walk the CNCF Landscape and, for each graduated project, be able to say in one sentence what problem it solves.

What not to over-invest in

• Memorising YAML fields. This is not a hands-on exam. Knowing that a Deployment has a strategy matters; knowing the indentation of rollingUpdate.maxSurge does not.
• Deep kubectl flag trivia. Save it — it pays off in CKA and CKAD, where it is the whole game.
• Any single vendor’s distribution. The exam is upstream Kubernetes.
• Chasing the newest release notes. Know the structural changes that already landed — dockershim removal, PodSecurityPolicy’s replacement by Pod Security Admission — not this month’s alpha features.

Part of the Kubestronaut run. Next: the KCSA study guide, which assumes everything above and asks how each piece of it fails.