KCNA — the exam

The Kubernetes and Cloud Native Associate (KCNA) is the front door to this course's five-exam ladder and to the CNCF's whole certification catalogue — an entry-level, knowledge-based multiple-choice exam with no cluster, no terminal, and no prerequisite. It asks one question in four accents: do you understand what Kubernetes is, what it does for you, and what the ecosystem built up around it is for? Nothing on it rewards typing speed; everything rewards a correct mental model. This page is the KCNA hub for this course — who should sit it and who should skip it, the CNCF's official four-domain breakdown reproduced exactly as published, the substance behind each domain with worked examples, and where in this course to actually study it before you book a seat.

What KCNA actually is, and who it's for

☺ Like you're 10: It's an online quiz about how Kubernetes and the cloud native world fit together. There's no cluster to fix — only questions to answer correctly.

KCNA is the CNCF and Linux Foundation's entry-level, knowledge-based Kubernetes credential: online, remote-proctored, multiple-choice, with no live cluster and no kubectl to type. It certifies conceptual fluency — that you know what a Pod is, what the control plane does, why a container isn't a small virtual machine, what a Service solves, and what the wider CNCF landscape is a landscape of. It is deliberately broad and shallow: it sweeps from container images through scheduling, networking, storage and troubleshooting, then out into delivery pipelines and the governance of the open source community that maintains all of it.

Who should sit it

• People newer to Kubernetes — a structured, defensible map of the whole territory in a few focused weeks, without needing a cluster of your own yet.
• Developers who ship onto a platform someone else runs — enough of the object model and the control plane to stop copy-pasting YAML you don't understand.
• Adjacent roles and career switchers — managers, support engineers, consultants — who need to reason credibly about Kubernetes without operating it day to day.
• Anyone starting this course's ladder cold — see the certifications hub for how KCNA feeds into CKA, CKAD and CKS.

What it deliberately does not test

Two things, and knowing them up front saves real study time. Hands-on speed: you are never graded on cluster state, so drilling kubectl muscle memory belongs to the performance-based exams above KCNA on this ladder, not to this one — see the kubectl fluency baseline when you're ready for that layer. And deep operational detail — etcd backup and restore, kubeadm cluster upgrades, CNI plugin internals, admission webhook authoring. KCNA wants you to know that these things exist and roughly what they're for, not to perform them under a clock.

The official domains and their weights

☺ Like you're 10: The test splits into four parts, and they are not the same size. Nearly half the whole exam is plain Kubernetes basics.

The domain names, percentages and competency lists below are transcribed from the CNCF's published Kubernetes and Cloud Native Associate (KCNA) Exam Curriculum — thirteen competencies across four domains, weights summing to exactly 100%:

Two placements are worth noticing before you build a study plan. Observability sits inside Cloud Native Architecture, not folded into troubleshooting — the curriculum treats it as an architectural property of a whole system, which is the right way to think about it. And Debugging sits under Application Delivery while Troubleshooting is a separate competency over in Container Orchestration: debugging is about your application's own behavior, troubleshooting is about the cluster running it.

What you actually need to know, domain by domain

☺ Like you're 10: Here's the real stuff — the parts of Kubernetes and the wider ecosystem the questions are actually drawn from.

Kubernetes Fundamentals — the 44%

Core concepts is architecture plus objects, and it's this course's own opening act — see Kubernetes architecture and control plane internals for the full depth. On the control plane: kube-apiserver (the only component that ever talks to etcd, and the front door for every request), etcd (the cluster's single source of truth), kube-scheduler (chooses which node a Pod lands on), and kube-controller-manager (runs the built-in reconciliation loops — see the API & the controller pattern). On every node: kubelet, kube-proxy, and a CRI-compatible runtime such as containerd. Then the workload objects — Pod, ReplicaSet, Deployment, StatefulSet, DaemonSet, Job, CronJob — and what each one is actually for, covered in the object model. Containerization is the layer underneath: images as stacked layers plus a manifest, the OCI image and runtime specs, and why containers share the host kernel while a virtual machine does not. Scheduling means requests and limits, node selectors, affinity, and taints and tolerations. Administration means namespaces, RBAC, and the declarative kubectl apply workflow.

apiVersion: apps/v1
kind: Deployment                # manages a ReplicaSet, which manages Pods
metadata: { name: storefront, namespace: shop }
spec:
  replicas: 3
  selector:
    matchLabels: { app: storefront }      # must match the Pod template labels
  template:
    metadata:
      labels: { app: storefront }
    spec:
      containers:
        - name: web
          image: registry.example.com/storefront:2.1.0   # a pinned tag, never "latest"
          resources:
            requests: { cpu: "100m", memory: "128Mi" }    # the SCHEDULER reserves this
            limits:   { cpu: "500m", memory: "256Mi" }    # the KERNEL enforces this
          readinessProbe:                 # "can I receive traffic yet?"
            httpGet: { path: /healthz, port: 8080 }
          livenessProbe:                  # "should I be restarted?"
            httpGet: { path: /healthz, port: 8080 }
---
apiVersion: v1
kind: Service                   # a stable virtual IP + DNS name for those Pods
metadata: { name: storefront, namespace: shop }
spec:
  type: ClusterIP               # ClusterIP | NodePort | LoadBalancer | ExternalName
  selector: { app: storefront } # selects Pods by LABEL, never by name
  ports: [ { port: 80, targetPort: 8080 } ]

That one file answers a good slice of this domain by itself. A request drives where the scheduler places the Pod; a limit is enforced at runtime by the kernel, and crossing the memory limit gets a container OOMKilled. A failing readiness probe pulls a Pod out of the Service's endpoints without restarting it; a failing liveness probe restarts it. And a Service always finds Pods by matching labels, never by name — which is exactly what makes a Pod disposable in the first place.

Container Orchestration — the 28%

Networking: the flat model where every Pod gets its own IP and reaches every other Pod without NAT, Service types, kube-proxy, cluster DNS, and Ingress — see networking & the CNI and Services & networking. Storage: ephemeral volumes such as emptyDir, and the persistent trio of PersistentVolume, PersistentVolumeClaim and StorageClass, plus dynamic provisioning and the CSI — see storage & the CSI and storage. Security: the difference between authentication and authorization, RBAC, ServiceAccounts, and why a Secret is only base64-encoded rather than genuinely encrypted by default — see RBAC & admission control and, at a much deeper hardening level than KCNA needs, security: defense in depth.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy              # deny-by-default the moment a Pod is selected
metadata: { name: storefront-allow-web, namespace: shop }
spec:
  podSelector: { matchLabels: { app: storefront } }
  policyTypes: [Ingress]
  ingress:
    - from:
        - podSelector: { matchLabels: { role: frontend-proxy } }
      ports: [ { protocol: TCP, port: 8080 } ]
---
apiVersion: v1
kind: PersistentVolumeClaim      # a REQUEST for storage; the class provisions it
metadata: { name: storefront-data, namespace: shop }
spec:
  accessModes: [ReadWriteOnce]   # RWO: attachable to one node at a time
  storageClassName: fast-ssd     # names a StorageClass -> dynamic provisioning
  resources:
    requests: { storage: 10Gi }

Troubleshooting is tested as interpretation: given a symptom, what's the likely cause? Learn what kubectl get pods actually prints — a mix of true Pod phases and container-level reasons, which is exactly why they don't all live in the same field. Pending is a phase: unschedulable, because nothing has the requested resources or a taint is blocking it. ImagePullBackOff is a container waiting reason: a bad tag, a private registry, or a missing pull secret. CrashLoopBackOff is also a waiting reason: the container starts and exits, repeatedly. OOMKilled is a terminated-container reason: it crossed its memory limit. Evicted means the Pod itself was failed and removed under node pressure. The five actual Pod phases are only Pending, Running, Succeeded, Failed and Unknown — see troubleshooting methodology and the troubleshooting blueprint.

Delivery, debugging and architecture — the last 28%

Application Delivery is how software actually reaches a cluster: packaging with Helm and Kustomize, the GitOps model where a controller inside the cluster continuously pulls desired state from Git and reconciles toward it (see GitOps on Kubernetes and operators & CRDs), and the deployment strategies — rolling update, blue/green, canary. Debugging is the developer-facing half of that domain:

# The single most useful command: recent events + full object state
kubectl describe pod storefront-7d9f5b6c4-abcde -n shop

# Logs — add -p for the PREVIOUS container after a crash
kubectl logs deploy/storefront -n shop --tail=100
kubectl logs storefront-7d9f5b6c4-abcde -n shop -p

# Cluster events, newest last — explains Pending and Evicted
kubectl get events -n shop --sort-by=.metadata.creationTimestamp

# Rollouts: check status, then undo if the new version is bad
kubectl rollout status deploy/storefront -n shop
kubectl rollout undo   deploy/storefront -n shop

You won't type these under a clock on KCNA — you'll be asked which one you'd reach for first, and the answer is almost always describe, then logs. That reasoning gets drilled properly once you're past KCNA, in the kubectl fluency baseline and this course's CKA study plan.

Finally, Cloud Native Architecture — the smallest domain and the widest-reading one. Observability: metrics, logs and traces as three distinct signals, and the shift from "is it up?" to "is it behaving?" — see observability on Kubernetes. Cloud Native Ecosystem & Principles: what "cloud native" means as a term, immutable infrastructure, declarative APIs, autoscaling (see scheduling & resource management), and service meshes (see service mesh fundamentals). Cloud Native Community & Collaboration is the one candidates most often skip and most easily miss marks on: the CNCF's own role as a foundation, and its project maturity ladder — Sandbox → Incubating → Graduated — the three stages every hosted project climbs as it earns broader trust, shown in the diagram above. The CNCF project landscape covers this in full, including where projects like Kubernetes itself, Prometheus and Envoy sit today.

How to prepare using this course

☺ Like you're 10: There's already a page here for nearly every part of the test — this is the order to read them in.

Start with How to Study for a CNCF Exam for the general method, then work KCNA's own pages: the KCNA study plan & practice bank for a full schedule sized to the domain weights above, and Mock Exam · Set 1 plus Set 2 for full timed runs once you feel ready. This course's foundations sequence — What is Kubernetes?, Kubernetes architecture, the object model and the API & controller pattern — covers the 44% by itself, in the order the Pod Squad walks it. Practice with a real, disposable cluster on kind or minikube whenever a concept refuses to stick — KCNA is knowledge-based, but nothing fixes a shaky mental model of a Pod faster than watching one actually get scheduled. Keep a running list of anything that trips you up in field notes, use the glossary the moment a term doesn't fully click, and read exam day, proctoring & environment the night before you sit any remote-proctored CNCF exam, this one included.

If you're approaching Kubernetes specifically because you're building or operating a platform on top of it, the sibling Platform Engineering course's own KCNA page covers the same exam from that angle in real depth — the honest case for taking it versus skipping it as an experienced operator, and exactly how KCNA stacks under CNPA and CNPE. It's worth reading once you've got the domains above settled, rather than duplicated here.

Exam logistics — and how to verify them

☺ Like you're 10: It's an online test you take from home while someone watches through your webcam. The price and exact rules change over time, so always check the official page before you pay.

Some facts about KCNA are structural and safe to state plainly. Others are exactly the sort of detail the Linux Foundation revises without much ceremony. This section keeps the two apart on purpose.

One number you don't have to guess at: the Linux Foundation's Multiple Choice Exam FAQ states plainly that a score of 75% or above must be earned to pass, and that rule covers every Linux Foundation multiple-choice exam, KCNA included — treat 75% as the real bar rather than a rumor about "the mid-70s." What remains genuinely unpublished is the exact question count: the exam pages no longer state one, so a commonly reported figure around sixty questions is a pattern from candidate write-ups, not a promise from the curriculum. Price (commonly cited near US$250, with one free retake), the twelve-month eligibility window to sit it once purchased, and the roughly two-year certification validity are all on the official product page and do get revised — read them there rather than budgeting from any third-party page, including this one.

↗ Official KCNA page — Linux Foundation ◆ CNCF certification page ◆ Official CNCF curriculum repository

Where KCNA sits, and what to do next

☺ Like you're 10: This badge is the first rung. From here you either climb the rest of this course's ladder, or head sideways into a wider CNCF program.

KCNA is the base of this course's complete core-Kubernetes ladder. The certifications hub lays out the whole shelf side by side; here are the sensible directions from here.

Go up this course's ladder

The classic route is KCNA → CKA or CKAD → CKS. All three are performance-based — a genuine change of gear, speed and hands rather than pure comprehension. CKA is the administrator's path; CKAD is the developer's; CKS is the hardening specialization at the top, and the only exam on the shelf with a hard prerequisite of its own. Adjacent to KCNA at the same associate tier sits KCSA, the Kubernetes-security-flavored sibling exam, which reuses a good share of the fundamentals you'll already have solid.

Go wider into the CNCF catalogue

Hold all five of this course's certifications — KCNA, KCSA, CKA, CKAD and CKS — active at once, and the CNCF recognizes you as a Kubestronaut; see the certifications hub for how that program works and what it takes to maintain it. If you want the other ten CNCF certifications, the Linux Foundation's LFCS, and the full Golden Kubestronaut ladder above plain Kubestronaut, that whole breadth lives in the sibling Golden Astronaut course rather than being duplicated in this one. And if the platform layer above Kubernetes — not just the substrate — is where your interest actually points, the sibling Platform Engineering course's own KCNA page and its CNPA exam are the next stop after this one.

Go build — the part that actually compounds

A badge is a signal; a running cluster is a skill. Keep a small one alive on kind or minikube: deploy something real, give it a Service and an Ingress, attach a PersistentVolumeClaim, put a NetworkPolicy in front of it, and watch what kubectl describe tells you when you deliberately break each piece. That's a miniature platform, and it teaches more in a weekend than any answer key does — and it's exactly what the next exam up this ladder starts grading you on directly.