Certified Kubernetes Administrator (CKA)
A hands-on, performance-based certification proving you can install, configure, and troubleshoot production Kubernetes clusters from the command line.
- src
- Linux Foundation Training & Certification — CKA certification pricing page (training.linuxfoundation.org)
- chk
The CKA is respected because it cannot be passed by memorising answers. You solve real cluster problems from a command line in two hours, so passing is a signal that you can operate Kubernetes rather than describe it.
What the weights tell you to study
Troubleshooting alone is 30%, which is the exam telling you what the job actually is: diagnosing why something broke, not building green-field clusters. Add Cluster Architecture at 25% and over half the marks sit in two domains. A candidate who has only practised happy-path deployments will run out of time.
Study in weight order rather than curriculum order. The official ordering starts with architecture and says nothing about where the marks are.
What the exam is actually like
Time is the constraint, not knowledge. Most people who fail knew the material and typed too slowly. Every candidate report says the same thing, and it is why the prep path puts shell setup on day one rather than treating it as a detail — kubectl aliases, completion and --dry-run=client -o yaml need two months of use to become automatic under pressure.
You get the documentation, and it will not save you. The permitted resources are the kubernetes.io docs and the Gateway API docs, including translations — you may search within them, but you may not open an external search result. Candidates who have not internalised the material lose the exam to searching, because reading a page you have never read before costs minutes you do not have.
Tasks are independent and unevenly weighted. Each one states its weight. Skipping a hard 4% task to bank two easy 7% ones is the correct call, and it is a decision worth practising in simulations rather than discovering live.
Context switching is real. Tasks run against different clusters and you must switch context between them. Solving a task perfectly in the wrong cluster scores zero, and it happens to people every sitting.
Where the marks are lost
Networking is the domain that surprises people: services, ingress and network policies fail in ways that look identical from kubectl get output and are diagnosed completely differently. etcd backup and restore is the opposite case — purely procedural, worth full marks, and reliably present, which makes drilling it the highest-return hour of preparation on the whole exam.
Before you book
The exam is valid for two years, and the fee includes one free retake. That changes the calculation: sitting it slightly under-prepared is a cheaper mistake than most certifications allow, and the first attempt tells you exactly which domains need work.
Budget real hands-on hours against a multi-node cluster. Reading will not get you through performance-based tasks in two hours.
New to Linux and the command line?
This path assumes fundamentals you may not have yet. Our Foundations Pack is out and free — Linux, the shell and Git, with exercises that mark your work and explain why you got it wrong. We're writing an agents pack next; leave your email if you want to hear when it ships.
One email when the pack launches. No spam, unsubscribe any time.
Exam domains
Cluster Architecture, Installation & Configuration
25%Workloads & Scheduling
15%Services & Networking
20%Storage
10%Troubleshooting
30%Preparation path
- 1
Set up a real multi-node cluster
Install kubeadm on 2-3 VMs so you have somewhere to break things. kind or minikube work for single-node practice, but node-level failures — a kubelet that will not start, a node stuck NotReady — are a third of the exam and need more than one node to reproduce.
~8 hours - 2
Configure your shell before studying anything else
Set up the kubectl alias, completion and the --dry-run=client -o yaml habit on day one, then use them for every subsequent step. Candidates lose the exam on typing speed, not knowledge, and two months of practice with the shortcuts is what makes them automatic under time pressure.
~2 hours - 3
Study Troubleshooting and Cluster Architecture first
These two domains are 55% of the score, and they are the ones you cannot cram. Work them in weight order rather than in curriculum order — the official ordering starts with architecture but says nothing about where the marks are.
~45 hours - 4
Cover Networking, Workloads and Storage
The remaining 45%. Networking is where most candidates lose marks they expected to keep — services, ingress and network policies each fail in ways that look identical from kubectl get output and are diagnosed completely differently.
~35 hoursServices, Load Balancing, and NetworkingKubernetes · FreeNetwork PoliciesKubernetes · FreePersistent VolumesKubernetes · FreeKubernetes: Up and RunningBrendan Burns, Joe Beda, Kelsey Hightower, Lachlan Evenson · Paid · aff — Affiliate link — we may earn a commission at no extra cost to you. A free alternative is always listed alongside. - 5
Practise etcd backup and restore until it is muscle memory
It appears regularly, it is worth full marks, and it is entirely procedural — which makes it the highest-return single task on the exam. Restore into a broken cluster rather than only taking snapshots of a healthy one, because that is the version that gets asked.
~6 hours - 6
Break your own cluster on purpose
Stop the kubelet, corrupt a manifest, exhaust a node's memory, apply a network policy that blocks the traffic you need. Diagnosing a failure someone else caused is the exam; diagnosing one you caused is how you learn the symptom-to-cause mapping fast enough.
~12 hours - 7
Take full-length timed simulations
Two hours, a timer, and only the official documentation open — the exam permits kubernetes.io and nothing else. Review every missed task and, more importantly, every task you got right slowly, because time is the constraint that fails prepared candidates.
~12 hours
Frequently asked questions
Career Roadmaps
- DevOps Engineer RoadmapA structured path from Linux fundamentals through cloud infrastructure, automation, containers, and monitoring to a production-ready DevOps engineering career.
- Platform Engineer RoadmapThe path DevOps engineers move into — building an internal developer platform as a product, covering Kubernetes as substrate, IaC at scale, GitOps, golden paths, portals, policy, multi-tenancy and adoption.
- Site Reliability Engineer RoadmapA path from DevOps fundamentals into the specialized discipline of site reliability engineering, covering SLOs, observability, incident response, data reliability, and capacity planning.
- Cloud Architect RoadmapA path into cloud architecture as the job it actually is — trade-off analysis, migration of systems you did not write, disaster recovery you have rehearsed, decision records, and influence without formal authority.
- Cloud Security Engineer RoadmapA path into cloud security as an engineering discipline, covering the shared responsibility model, identity, network segmentation, encryption, workload hardening, detection, governance as code, threat modelling and incident response.
- Database Reliability Engineer RoadmapA path into database reliability engineering — replication and consistency, restores you have actually verified, zero-downtime schema migrations, corruption detection, databases on Kubernetes, and RTO and RPO as a contract.