CKA — Kubernetes Administrator
The Certified Kubernetes Administrator is the Linux Foundation and CNCF's flagship credential for people who operate Kubernetes clusters — not the applications running on them, the clusters themselves. It's a hands-on, performance-based exam: no multiple choice, just a broken or unbuilt cluster and a clock. For an SRE team, that matters because a growing share of production reliability work now happens on top of Kubernetes as the substrate, and a Pod stuck in Pending or a Service with no endpoints doesn't care that your job title says "reliability" instead of "administrator." This page covers what the CKA actually tests, why it's adjacent to — not a substitute for — the SRE discipline this course teaches, and who should bother sitting it. For the full domain-by-domain breakdown, command references, and a six-week study plan, this course's companion Platform Engineering course covers the CKA in depth — that's where to go once you've decided it's worth your time.
Imagine a giant apartment building with elevators, pipes, and a boiler room. Most badges you can earn are about living well in the building — decorating a room, being a good neighbor. The CKA is a different kind of badge entirely: it's for the person who goes down to the boiler room, fixes a stuck elevator, and figures out why water pressure dropped on floor twelve — using real tools, on a real building, with someone watching the clock. An SRE isn't the building's boiler-room person by default, but when the elevator jams during a party (an incident), knowing your way around the boiler room helps a lot.
What the CKA actually tests
☺ Like you're 10: It's a two-hour test where you're handed real broken clusters and asked to fix them — not a quiz you answer from memory.
The CKA has existed since 2017 and is one of the most widely held Kubernetes credentials in the industry. It is deliberately narrow in scope: control plane, nodes, networking, and storage — the cluster as infrastructure — not the applications deployed onto it and not the delivery tooling wrapped around it. There's no question bank of A/B/C/D options. You're dropped into a browser-based terminal with several pre-built clusters and given tasks like "drain this node and upgrade it to the next minor version" or "this Service resolves but nothing answers — find out why." Grading happens against the end state of the cluster, which means two things in practice: speed is a real, trainable skill because most people who fail run out of clock rather than knowledge, and verifying your own work with kubectl get and kubectl describe is part of the job, not an afterthought.
The CKA tests whether you can run a cluster. It does not test SLIs, SLOs, error budgets, blameless postmortems, or any of the reliability practice this course is built around — those live entirely on the other side of the line. Passing the CKA proves you can keep the boiler room running; it says nothing about how much reliability you should promise the tenants, or what you do when the promise gets broken.
Format, cost, and prerequisites — verify before you book
☺ Like you're 10: Here's roughly what it costs and how long it takes, but exam details change, so check the real page before you pay anyone.
The numbers below are what the Linux Foundation and CNCF generally publish and what candidates consistently report as of this writing. Certification logistics — price, duration, passing threshold, retake policy, and the exact curriculum version — move without much notice, so treat this table as a planning aid, not a source of truth.
| Item | What's generally published |
|---|---|
| Format | Online, remotely proctored, performance-based — live clusters in a browser terminal, no multiple choice |
| Duration | 2 hours |
| Passing score | 66% |
| Validity | 2 years from the pass date |
| Retake | Registration has historically included one free retake |
| Price | Around USD $445 list; bundles and regional pricing are common |
| Prerequisites | None formally required — but the exam assumes real comfort at a Linux shell and with core Kubernetes objects |
| Permitted resources | A published allowlist of documentation sites, opened in a tab inside the exam environment — historically the Kubernetes docs and blog |
Price, duration, pass mark, retake policy, and the permitted documentation allowlist all change without much announcement. This page is an independent, unofficial snapshot. Confirm current details on the Linux Foundation CKA page and the CNCF certification page before you pay, and read the candidate handbook — room-scanning and permitted-tab rules are enforced strictly.
The domains, briefly
☺ Like you're 10: Five topics, unevenly weighted, and nearly a third of the whole test is just "something's broken, go find it."
The current CNCF curriculum publishes five domains that sum to exactly 100%. The shape is the headline: Troubleshooting alone carries 30% — more than Storage and Workloads and Scheduling combined. That weighting is itself a useful signal for an SRE: the exam rewards the same diagnostic instinct — describe before you log, check the node before you blame the app — that on-call work rewards.
That's the whole picture this page is going to give you — the published competency bullets under each domain, the kubeadm upgrade sequence, the etcd snapshot flags, and a real troubleshooting drill sequence are all covered properly, domain by domain, on the Platform Engineering course's CKA page. Duplicating that material here would just be a worse copy of a page that already does it well; go there when you're ready to actually study.
Why this matters if you run Kubernetes as your substrate
☺ Like you're 10: When a page wakes you up and the cluster is the culprit, "I don't really know Kubernetes" is not an option at 3am.
The overlap isn't with the SRE discipline's ideas — it's with the ground those ideas get applied to. An on-call engineer debugging a latency spike who can't tell the difference between a scheduling failure and a networking failure from the outside is going to burn error budget slower than one who can; both look identical as a symptom and are diagnosed completely differently. Kubernetes reliability patterns covers this course's own take on that territory — PodDisruptionBudgets, readiness and liveness probes, topology spread constraints — and the CKA is where the raw cluster-mechanics muscle underneath those patterns actually gets built and tested.
The same overlap shows up in three other places this course covers directly. Capacity planning and performance on Kubernetes means understanding resource requests and limits, the HorizontalPodAutoscaler, and cluster autoscaling — CKA-adjacent mechanics with SRE-shaped consequences. Chaos engineering experiments run against a cluster — killing a Pod, draining a node, injecting a network partition — are only safe to design when you understand how the scheduler and controllers will actually react; misjudging that turns a contained experiment into a real outage. And production readiness reviews for anything shipping onto Kubernetes should be checking exactly the things the CKA drills: are resource limits set, is there a PodDisruptionBudget, does the StorageClass have the reclaim policy you think it does.
Who should sit it — and who should skip it
☺ Like you're 10: If Kubernetes tickets keep landing on your desk and you keep having to ask someone else, that's the signal. If you already know this cold, spend the money elsewhere.
Sit it if you're an SRE or on-call engineer whose production systems run on Kubernetes you don't fully control at the cluster level — you can deploy and read dashboards, but a stuck finalizer or a Pending PVC sends you looking for someone else. The CKA closes exactly that gap, and for many employers it doubles as a hiring signal independent of what it teaches you personally.
Skip it, or at least deprioritize it, if any of these describe you. You already operate clusters daily and would be studying material you use every week — that time is better spent on this course's own SRE-specific certifications or on CKS if security is the actual gap. You run only fully managed control planes and will genuinely never touch kubeadm or take an etcd snapshot yourself — a full quarter of the exam is installation and lifecycle work your cloud provider owns. Or you're new to Kubernetes entirely, in which case a knowledge-based on-ramp like the Platform Engineering course's own KCNA page is a gentler place to start — the CKA punishes people who are still learning what a Pod is on the clock.
Go deeper: the companion Platform Engineering course
☺ Like you're 10: This page told you whether to care. The other course tells you exactly how to pass.
This page exists to answer one question — is the CKA worth an SRE's time, and why — not to be a study guide. The full domain-by-domain competency list, the exact kubeadm upgrade order, working etcdctl snapshot and restore commands, a NetworkPolicy walkthrough, a troubleshooting command sequence, and a six-week study plan all live on the Platform Engineering course's CKA page, written for exactly this exam at the depth it deserves. If you decide the CKA is worth sitting after reading this page, that's where to actually go study.
Once you hold the CKA, the next rung on the same ladder is CKS, which requires an active CKA and goes deep on cluster hardening, supply-chain security, and runtime threat detection — worth it if security incidents, not just availability incidents, land on your on-call rotation. If instead you want the SRE-native equivalent of a practical, credential-backed skill check, this course's own certifications page and the SRE Practitioner profile are the better next stop.
Benny the Beaver: I've been quietly studying for the CKA. Etcd snapshots, kubeadm upgrades, the works.
Foxy: Wait, isn't that a platform-engineering exam? We're the reliability team, not the cluster-building team.
Benny the Beaver: Sure, but half my pages last quarter were "something's wrong with the cluster" before anyone knew whether it was scheduling, networking, or storage. I want to know which one on sight.
Timmy the Turtle: Fair — but don't let "I can run a cluster" quietly become "therefore I know what reliability to promise on it." Those are different questions and the CKA only answers one of them.
Professor Owl: Right tool, right job. The CKA teaches you the substrate. This course teaches you what to build on top of it, and how much of it you're allowed to break before you owe someone an explanation.
Benny the Beaver: Deal. I'll sit the CKA. You keep the error-budget math away from me — that's Sol's job.
1. What kind of exam is the CKA — multiple choice or something else — and how is it graded? 2. Which single domain carries the largest weight in the current curriculum, and roughly how large? 3. Name two things the CKA does not test that are core to this course's own discipline. 4. Give one concrete reason an SRE running Kubernetes as their substrate would benefit from CKA-level cluster literacy. 5. Name one situation in which a platform engineer or SRE should skip the CKA.
Check your answers
- It's performance-based, not multiple choice — candidates are given real, live clusters in a browser terminal and graded on the end state of the cluster after completing each task, not on how they got there.
- Troubleshooting, at roughly 30% of the exam — larger than Storage and Workloads and Scheduling combined.
- Any two of: SLIs/SLOs and error budgets, blameless postmortems, toil measurement and reduction, incident command structure, or any other SRE-practice mechanism — the CKA is entirely about cluster operations, not reliability practice.
- Any reasonable answer along the lines of: scheduling and networking failures look identical from the outside during an incident but are diagnosed completely differently, and cluster-level literacy shortens that diagnosis; or capacity planning, chaos engineering, and production readiness reviews on Kubernetes all depend on understanding the same cluster mechanics the CKA tests.
- Any of: you already operate clusters daily and the exam would teach you little; you run only a fully managed control plane and will never touch kubeadm or etcd yourself; you're new to Kubernetes and should start with a knowledge-based exam like KCNA first; or your actual gap is SRE practice itself, better closed by this course's own certifications.