CKA — Kubernetes Administrator
This page profiles a certification with almost nothing to do with security, in a course that's entirely about security. The reason is simple and non-negotiable: you cannot book the Certified Kubernetes Security Specialist (CKS) exam without an active, non-expired Certified Kubernetes Administrator (CKA) already in hand — it's the only certification in the CNCF's Kubernetes lineup with a hard prerequisite gate, enforced at registration, not just recommended in a syllabus. If Kubernetes security is where you're headed, this is the box you check first. What follows is what the CKA actually is, what it tests, and — just as important — what it deliberately does not test, because that gap is exactly what CKS exists to fill.
Before you're allowed to take the advanced lifeguard course — the one about rescuing someone from a riptide — the pool insists you already passed the basic swimming test. Not because rescuing people and swimming laps are the same skill, but because you can't teach riptide rescue to someone who might still need help just staying afloat. The CKA is that basic swimming test for Kubernetes. It doesn't ask a single question about attackers. CKS assumes you already passed it, and builds the "hostile water" lessons on top.
Why a DevSecOps course profiles an exam with no security domains
☺ Like you're 10: This page isn't here to teach you Kubernetes security — it's here to point at the one door you have to walk through before that lesson is even bookable.
Every certification this course otherwise touches is chosen because it tests something a security engineer does. The CKA breaks that pattern on purpose. It's included for one reason: the Linux Foundation and CNCF built CKS to assume cluster-administration fluency rather than re-teach it, and they enforce that assumption structurally — at the moment you try to schedule the CKS exam, the system checks for an active CKA on file and simply refuses the booking if one isn't there. No other pairing in the CNCF's certification catalog works this way. KCSA, CKAD, and every associate-level exam stand alone. CKA and CKS are structurally welded together.
That welding is deliberate curriculum design, not bureaucracy. CKS's own domains — cluster hardening, system hardening, minimizing microservice vulnerabilities, supply chain security, monitoring and runtime security — all presuppose you can already stand up a cluster, read a kubelet log, and reason about a Service without help. Retesting that foundation inside CKS would burn exam time better spent on the security-specific material. So the CNCF externalized it: pass CKA once, and CKS gets to start from "you already know how a cluster works" instead of from zero. If you're weighing whether to sit the CKA at all, the honest framing is: you're not really choosing to learn Kubernetes administration for its own sake here — you're clearing the one gate that stands between you and the CKS profile, which is where this course's actual interest in Kubernetes lives.
What the CKA actually is: performance-based, on live clusters, zero multiple choice
☺ Like you're 10: There's no quiz to guess your way through — you're handed a real, broken-ish cluster and a terminal, and the only thing that counts is whether you leave it working.
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 has existed since 2017 and is one of the most widely held cloud-native certifications in the industry, largely because so many adjacent exams — CKS chief among them — point back to it as a foundation.
It is entirely performance-based: an online, remotely proctored exam that drops you into a browser-based terminal with several pre-built, real Kubernetes clusters and hands you a sequence of tasks — drain and upgrade a node, restore etcd from a snapshot, fix a Service that resolves a name but never answers a request, track down why a Pod is stuck in Pending. There is no question bank, no multiple choice, nothing to recognize from a study guide. Grading looks at the end state of the cluster after you're done, not the commands you typed to get there, which has a practical consequence worth internalizing before exam day: an answer you didn't verify with kubectl get or kubectl describe is an answer you don't actually know you gave. Speed matters too — most candidates who fail report running out of clock, not running out of knowledge.
CKA and CKS share an exam style — performance-based, live environment, graded on cluster state — without sharing exam content. That's exactly why the prerequisite works: CKS can assume you already know how to move fast and verify your work on a live cluster, and spend its own two hours entirely on security-specific tasks instead of re-teaching exam mechanics.
The official domains and weights
☺ Like you're 10: Five topics, unevenly sized — nearly a third of the whole exam is just "something broke, go find it and fix it."
These are the five domains published in the CNCF's CKA curriculum at the time of writing (curriculum version v1.35 in the CNCF's own numbering — it updates roughly twice a year to track current Kubernetes releases, so confirm you're studying the version live when you book, not this one by default). They carry no sub-weights and sum to exactly 100%.
Troubleshooting (30%) is a method, not a set of objects to memorize — diagnosing broken nodes, broken cluster components, unresponsive Services, and misbehaving workloads by reading logs and events in a fixed order rather than guessing. Cluster Architecture, Installation and Configuration (25%) is kubeadm territory: bootstrapping a control plane, joining nodes, upgrading a cluster across a minor version, taking and restoring an etcd snapshot, and basic RBAC — Roles, RoleBindings, ServiceAccounts. Servicing and Networking (20%) covers Pod-to-Pod connectivity, Service types, Ingress and the newer Gateway API, CoreDNS, and NetworkPolicy — at the level of "can you make traffic flow correctly," not "can you audit a policy for security gaps." Workloads and Scheduling (15%) is Deployments, rolling updates and rollbacks, ConfigMaps and Secrets used as plain configuration inputs, autoscaling, and scheduling controls like affinity and taints. Storage (10%), the smallest domain, is StorageClasses, PersistentVolumes and PersistentVolumeClaims, access modes, and reclaim policy.
Notice what's absent from that list entirely: no domain named security, hardening, or supply chain. RBAC shows up, but as "can you write a Role that grants the right verbs" — not "can you audit a cluster's bindings for privilege creep." Secrets show up, but as a way to inject configuration into a Pod — not as something that needs encryption at rest or an external secrets manager. NetworkPolicy shows up, but as basic connectivity — not as a hardening control you'd design a zero-trust namespace around. That's not an oversight. It's the whole reason CKS exists as a separate exam.
What CKA does not test — the gap CKS exists to close
☺ Like you're 10: Passing the basic swimming test proves you won't drown in calm water. It says nothing about whether you can handle a riptide — that's a different, harder test, on purpose.
This is the section worth reading twice if you're deciding whether the CKA is "enough" Kubernetes security knowledge on its own. It isn't, and it was never meant to be. Compare the two curricula side by side and the split is stark:
| CKA | CKS | |
|---|---|---|
| Core question | Can you run a cluster? | Can you run a cluster an attacker can't easily move through? |
| RBAC | Write a Role and bind it correctly | Audit bindings for least privilege; catch over-broad ClusterRoles |
| Pod security | Not covered | Pod Security Standards, admission control, breaking out of a container |
| Image supply chain | Not covered | Image scanning, signing, provenance, minimizing base-image attack surface |
| Secrets | Mount one into a Pod | Encrypt them at rest; consider an external secrets manager |
| Runtime | Not covered | Behavioral detection (Falco), audit logging, incident response on a live cluster |
| Prerequisite | None | Active, non-expired CKA — checked at booking |
Everything in that CKS column is unpacked properly in Kubernetes Security Deep Dive and on the CKS profile itself — Pod Security Standards, admission control, RBAC audited for least privilege rather than just written correctly, and the supply-chain half this course covers in container & supply-chain security. The point to take from this page alone is narrower: don't walk out of a CKA exam thinking you've validated Kubernetes security skills. You've validated that you can be handed a cluster and keep it alive. That's necessary. It isn't the same job.
A passed CKA gets misread as "I understand Kubernetes security" more often than any other credential on this site's certification pages. It doesn't claim that, and the exam blueprint will back that up if you read it — there is no security domain in it at all. Treat CKA as the operational floor you stand on, not the security ceiling you've reached.
Format, cost, and prerequisites — verify before you book
☺ Like you're 10: The exam's shape shifts every so often — read the official page before you pay for anything.
The details below are what the Linux Foundation and CNCF generally publish and what candidates consistently report at the time of writing. Every one of these has changed at some point in the exam's history, so treat this as planning information, not something to quote back at anyone.
| Item | What is generally published |
|---|---|
| Format | Online, remotely proctored, performance-based — real tasks on live clusters in a browser terminal |
| Duration | 2 hours |
| Passing score | 66% |
| Validity | 2 years from the date you pass — and CKS checks this expiry date directly at booking |
| Retake | Registration has historically included one free retake |
| Price | Around USD $445 list; bundles, regional pricing, and Linux Foundation discount codes are common |
| Prerequisites | None formally published for the CKA itself — but real Linux shell comfort (systemctl, journalctl, vim) is assumed |
| 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, permitted documentation, and curriculum version all change. Nothing on this page is authoritative — this site is independent and unofficial. Confirm current details on the official Linux Foundation CKA page and the CNCF certification page before paying, and read the candidate handbook in your Linux Foundation portal — one detail worth double-checking specifically for this course's purposes is exactly how CKA-expiry-before-CKS-booking is enforced on the date you register, since that's the mechanic this whole page exists to flag.
Who in this course should actually sit it
☺ Like you're 10: If CKS is the destination, this is the one stop you can't skip. If it isn't, there's a good chance you don't need this detour at all.
Sit the CKA if CKS is a real goal, not a someday-maybe — there's no way around it, and it's better to treat the prerequisite as step one of the CKS plan rather than a separate decision made later under time pressure. It's also worth sitting if your day job already has you administering clusters directly — draining nodes, debugging Services, restoring etcd — since in that case the exam mostly confirms and certifies work you're already doing, security angle aside.
Skip it, at least for now, if your security work is entirely upstream of the cluster — SAST, SCA, secrets scanning, pipeline gates covered in SAST, DAST & SCA and security in CI/CD — and you have no plan to move into cluster-level hardening. Skip it too if you already hold an active CKA: there's nothing more for this page to tell you, go read the CKS profile directly. And if Kubernetes itself is still new to you, the CKA will punish that gap hard — performance-based exams have no partial credit for "I understand the concept but typed the command wrong under pressure." Build basic cluster fluency first; the Kubernetes Security Deep Dive page assumes you already have it, same as CKS does.
Foxy: Wait — this whole page and there's no threat model, no gate, no scanner? What is this doing in a security course?
Professor Owl: It's not teaching security. It's teaching you what stands between you and the exam that does. CKS won't even let you register without an active CKA — the system checks.
Timmy the Turtle: That's the part I care about. It's not a suggestion, it's a locked door. No active CKA, no CKS booking. Full stop.
Benny the Beaver: So what does CKA actually test, if not security?
Professor Owl: Whether you can build a cluster, upgrade it, back up etcd, and figure out why a Pod won't start. All real. None of it security.
Ellie the Elephant: So it teaches you to write a Role. It doesn't teach you to audit one for a binding that's far too broad.
Timmy the Turtle: Exactly. That gap is the entire reason CKS exists as a separate exam instead of one longer one. Pass this, then go read the CKS page properly.
1. Why does a DevSecOps course profile the CKA at all, given it has no security domains? 2. Name the five official CKA domains and their weights, largest to smallest. 3. Give two concrete examples of things CKS tests that CKA does not. 4. What exactly does the CKA-to-CKS prerequisite check, and when does the check happen? 5. Name one situation where a DevSecOps engineer should skip the CKA for now.
Check your answers
- Because CKS — the certification this course actually cares about — has a hard, system-enforced prerequisite: you cannot book the CKS exam without an active, non-expired CKA. This page exists purely to get that box checked, not to teach Kubernetes security itself.
- Troubleshooting 30%; Cluster Architecture, Installation and Configuration 25%; Servicing and Networking 20%; Workloads and Scheduling 15%; Storage 10%.
- Any two of: Pod Security Standards and admission control for security purposes; image scanning, signing, and supply-chain provenance; encrypting Secrets at rest or using an external secrets manager; runtime/behavioral detection tools like Falco; auditing RBAC bindings for least privilege rather than just writing a Role correctly.
- It checks that the candidate holds an active, non-expired CKA certification, and the check happens at the moment the CKS exam is booked/registered — not on exam day, and not as a soft recommendation.
- Any reasonable answer, e.g.: their security work is entirely upstream of the cluster (SAST/SCA/pipeline gates) with no plan to move into cluster hardening; they already hold an active CKA and should read the CKS profile directly instead; or they're still new to Kubernetes and should build basic cluster fluency before attempting a performance-based exam with no partial credit.