KCNA — Kubernetes and Cloud Native Associate

The Kubernetes and Cloud Native Associate (KCNA) is the front door to the CNCF certification ladder — a knowledge-based, multiple-choice exam asking one question in four accents: do you understand what Kubernetes is, what it does for you, and what the ecosystem around it is for? Nothing on it requires speed at a terminal; everything requires a correct mental model. For a platform engineer that makes KCNA either the most efficient week of study you’ll ever do, or a badge to skip. This page says which, reproduces the four official domains and weights exactly as the CNCF publishes them, and maps each to lessons you can start reading here today.

What the KCNA is — and who it is for

☺ Like you’re 10: It’s an online multiple-choice test about how Kubernetes and the cloud native world work. There’s no cluster to fix — just questions to answer.

KCNA is the CNCF and Linux Foundation’s associate-tier, knowledge-based Kubernetes credential: online, remote-proctored, multiple-choice, no terminal and no live cluster. It certifies conceptual fluency — you know what a Pod is, what the control plane does, why containers are not virtual machines, what a Service solves, and what the CNCF landscape is a landscape of. It is deliberately broad and shallow, sweeping from container images through scheduling, networking, storage and troubleshooting, out into delivery and the governance of the community itself.

Who should sit it

• People new to Kubernetes — a structured, defensible map of the territory in a few weeks.
• Developers who consume a platform — Dot the Duck’s people, who want to stop cargo-culting the YAML they were handed.
• Adjacent roles and career switchers — managers, consultants and newcomers who must reason credibly about Kubernetes without pretending to operate it.

What it deliberately does not test

Two things, and knowing them saves weeks. Hands-on speed: you are never graded on cluster state, so drilling kubectl muscle memory is CKA and CKAD preparation, not KCNA preparation. And deep operational detail — etcd backups, kubeadm upgrades, CNI internals, admission webhooks. KCNA wants you to know those exist and what they are for, not to perform them.

Why a platform engineer might take it — and when to skip it

☺ Like you’re 10: If Kubernetes is still blurry to you, this badge sharpens it fast. If you already run clusters for a living, it mostly tells you things you know.

The honest case for taking it

Platform engineering is built on Kubernetes. Every page here — GitOps, CRDs and operators, self-service, policy — assumes the substrate underneath is already familiar. If it isn’t, everything above stays vague, and KCNA is the cheapest structured way to make it concrete. It also drags you across parts of the ecosystem platform engineers routinely skip: container runtimes and the OCI spec, CNCF project maturity levels, and the community structures deciding where your tools are heading.

When to skip it

Skip KCNA if you already operate clusters in production and can explain the control plane, Services, scheduling and RBAC without looking anything up. You’ll pass without studying, so the badge tells a hiring manager nothing they wouldn’t infer from your job title. Spend that time on CKA, CKS, or go straight at CNPA and CNPE. Skip it too if a job description names a different credential — chase the named cert, not the ladder.

How it relates to CNPA and CNPE

Stacking, not overlap: KCNA certifies the substrate, CNPA the discipline built on it, CNPE that you can build it live under a clock. None gates another, but that order wastes the least time.

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 of it is plain Kubernetes basics.

The names, percentages and competency lists below are transcribed from the CNCF’s Kubernetes and Cloud Native Associate (KCNA) Exam Curriculum — not our interpretation of it:

Every competency, domain by domain

Two placements surprise people. Observability sits under Cloud Native Architecture, not under troubleshooting — the curriculum treats it as an architectural property of a system, which is exactly right. And Debugging sits under Application Delivery while Troubleshooting is separate, over in Container Orchestration: debugging is about your application, troubleshooting about the cluster running it.

Where the weight really sits

The shape is blunt. Kubernetes Fundamentals alone is 44%; add Container Orchestration and 72% of the paper is “do you understand Kubernetes?” The two cloud-native-flavoured domains are 28% between them, and they’re the ones candidates under-read because they feel like reading rather than studying. That’s a trap both ways: skimp on the 72% and you fail; skimp on the 28% and you leave the most memorisable marks on the paper behind.

What you actually need to know

☺ Like you’re 10: Here’s the actual stuff — the parts of Kubernetes and the ecosystem the questions come from.

Kubernetes fundamentals — the 44%

Core concepts is architecture plus objects. Control plane: kube-apiserver (the only component that talks to etcd, and the front door for everything), etcd (cluster state), kube-scheduler (picks the node), kube-controller-manager (the built-in reconciliation controllers). On every node: kubelet, kube-proxy and a CRI runtime such as containerd. Then the workload objects — Pod, ReplicaSet, Deployment, StatefulSet, DaemonSet, Job, CronJob — and what each is for. Containerization is the layer beneath: images as layers plus a manifest, the OCI specs, and why containers share the host kernel while VMs do not. Scheduling: requests and limits, node selectors, affinity, taints and tolerations. Administration: namespaces, RBAC, and the declarative kubectl apply workflow.

apiVersion: apps/v1
kind: Deployment                 # manages a ReplicaSet, which manages Pods
metadata: { name: checkout, namespace: shop }
spec:
  replicas: 3
  selector:
    matchLabels: { app: checkout }        # must match the Pod template labels
  template:
    metadata:
      labels: { app: checkout }
    spec:
      containers:
        - name: app
          image: ghcr.io/acme/checkout:1.4.3   # immutable 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: checkout, namespace: shop }
spec:
  type: ClusterIP                # ClusterIP | NodePort | LoadBalancer | ExternalName
  selector: { app: checkout }    # selects Pods by LABEL, never by name
  ports: [ { port: 80, targetPort: 8080 } ]

That one file answers much of the domain. requests drive scheduling while limits drive runtime enforcement; a failing readiness probe removes a Pod from the Service endpoints without restarting it, while a failing liveness probe restarts it; and Services find Pods by label, never by name — which is exactly what makes Pods disposable.

Container orchestration — the 28%

Networking: the flat model (every Pod gets an IP and reaches every other Pod without NAT), Service types, kube-proxy, cluster DNS, Ingress versus the newer Gateway API, and NetworkPolicy — see networking and Cilium. Storage: ephemeral volumes such as emptyDir, and the persistent trio of PersistentVolume, PersistentVolumeClaim and StorageClass, plus dynamic provisioning, access modes and CSI — see storage & state. Security: authentication versus authorization, RBAC, ServiceAccounts, why Secrets are only base64-encoded by default, and admission control as a gate — see security and secrets management.

apiVersion: v1
kind: PersistentVolumeClaim      # a REQUEST for storage; the class provisions it
metadata: { name: checkout-data, namespace: shop }
spec:
  accessModes: [ ReadWriteOnce ] # RWO: one node at a time (typical block storage)
  storageClassName: fast-ssd     # names a StorageClass -> dynamic provisioning
  resources:
    requests: { storage: 10Gi }
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role                       # namespaced; ClusterRole is cluster-wide
metadata: { name: pod-reader, namespace: shop }
rules:
  - apiGroups: [""]              # "" is the core API group
    resources: ["pods", "pods/log"]
    verbs: ["get", "list", "watch"]     # read-only: no create/update/delete
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding                # a Role grants nothing until it is BOUND
metadata: { name: dot-reads-pods, namespace: shop }
subjects: [ { kind: User, name: dot, apiGroup: rbac.authorization.k8s.io } ]
roleRef: { kind: Role, name: pod-reader, apiGroup: rbac.authorization.k8s.io }

Troubleshooting is tested as interpretation: given a symptom, what’s the likely cause? Learn the statuses kubectl get pods prints — a mix of true Pod phases and container-level reasons, which is why they don’t all appear in the same field: Pending (a phase — unschedulable: nothing has the requested resources, or a taint blocks it), ImagePullBackOff (a container waiting reason — bad tag, private registry, missing pull secret), CrashLoopBackOff (waiting reason — starts and exits repeatedly), OOMKilled (a terminated-container reason — exceeded its memory limit) and Evicted (the Pod was failed and removed under node pressure). The five phases themselves are only Pending, Running, Succeeded, Failed and Unknown.

Delivery, debugging and architecture — the last 28%

Application Delivery is how software reaches a cluster: CI/CD in a cloud native shape, packaging with Helm and Kustomize, the GitOps model where a controller inside the cluster pulls desired state from Git and reconciles it continuously, and the deployment strategies — rolling update, blue/green, canary. Debugging is the developer-facing half:

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

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

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

# Rollouts: check, then undo
kubectl rollout status deploy/checkout -n shop
kubectl rollout undo   deploy/checkout -n shop

You won’t type these under a clock — you’ll be asked which one you’d reach for, and the answer is almost always describe first, then logs. The troubleshooting playbook, workload triage and command reference drill that reasoning.

Finally, Cloud Native Architecture. Observability: metrics, logs and traces; Prometheus and its pull model; OpenTelemetry as the vendor-neutral instrumentation standard; the four golden signals; SLIs, SLOs and error budgets. Ecosystem and Principles: what cloud native means, microservices versus monoliths, immutable infrastructure, declarative APIs, autoscaling, serverless, service meshes, and the open standards — OCI, CRI, CNI, CSI. Community and Collaboration is the one platform engineers skip and shouldn’t: the CNCF’s role, project maturity levels (Sandbox → Incubating → Graduated), SIGs and TAGs, and open source governance. The CNCF landscape and tool index cover it.

How to prepare using this site

☺ Like you’re 10: For every part of the test, there’s already a page here that explains it. Read them in this order and you’ve read the whole syllabus.

This site was written for the CNPE, a layer above KCNA, so almost every KCNA topic is here — usually deeper than the exam needs. Use the middle column to pass, the right column when a concept refuses to stick.

Three weeks is comfortable if you’ve touched Kubernetes at all; stretch to five if it’s entirely new. Week one goes to the fundamentals (nearly half the exam), week two to orchestration plus the troubleshooting playbook, week three to delivery, architecture and revision with the flashcards, quiz and glossary.

Exam logistics — and how to verify them

☺ Like you’re 10: It’s an online test you take from home with someone watching through your webcam. The price and length change, so always check the official page before you pay.

Some things about KCNA are structural and safe to state; others are exactly the sort of detail the Linux Foundation revises without ceremony. This page separates the two on purpose.

What we can state with confidence

What you must check on the official page

These move: duration, question count, pass mark, price, retake policy, eligibility window and certification validity. One of them you do not 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 the Multiple Choice Exam” — that is a published requirement covering every Linux Foundation multiple-choice exam, KCNA included, so treat 75% as the real bar rather than a rumour about the mid-70s. The same FAQ gives multiple-choice candidates 90 minutes, with the CNPA as the single 120-minute exception. What remains genuinely unpublished is the question count: the exam pages no longer state one, so the familiar “about 60 questions” is a reported pattern, not a promise, and it comes from candidate write-ups rather than from the curriculum PDF above, which specifies only domains and competencies. The price, retake entitlement, eligibility window and validity — near US$250 with one free retake, twelve months to sit it, two years of validity — are on the product page and do get revised, so read them there rather than budgeting from any third-party site, including this one.

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

Where KCNA sits in the ladder — and what to do next

☺ Like you’re 10: This badge is the first rung. From here you go up the Kubernetes ladder, or sideways into platform engineering.

KCNA is the base of the CNCF certification family. The certifications overview maps the whole shelf; here are the three sensible directions out.

Go up the Kubernetes ladder

The classic route is KCNA → CKA or CKAD → CKS. Both are performance-based — a real change of gear: speed and hands, not just comprehension. CKA is the administrator’s path and the more useful one for a platform engineer; CKAD is the developer’s. CKS is the security specialisation, and it does carry a prerequisite, unlike almost everything else on the shelf.

Go sideways into platform engineering

If the platform layer is where you want to live, go KCNA → CNPA → CNPE; this site has a whole sub-course for CNPA with a timed mock exam. Adjacent associates: KCSA for Kubernetes security and CGOA for GitOps, which overlaps the delivery domain you just studied.

Go build — the part that compounds

A certificate is a signal; a running cluster is a skill. Keep a small one alive: deploy something real, give it a Service and an Ingress, attach a PersistentVolumeClaim, put a NetworkPolicy in front, wire Prometheus to it, then reconcile the lot from Git with Argo CD. That is a miniature platform, and it teaches more in a fortnight than any answer key — the lab track walks that path and the field notes show it in the wild. And keep an eye on the official curriculum: the version you studied is not guaranteed to be the version you sit.