How I Passed the CKA in 2026

yltw — Thu, 16 Jul 2026 11:42:57 +0000

I sat the Certified Kubernetes Administrator exam recently. As of writing this, I don't actually know if I passed. The results take up to 24 hours and I'm in that enjoyable window where I'm simultaneously convinced I aced it and convinced I fat-fingered a namespace somewhere and blew 15 points.

Either way, I spent roughly 2 months preparing for this thing while working on a full-time job, and I figured I'd write down what actually worked — and what definitely didn't — while it's still fresh.

Some Context: Why This Exam Is Harder Than It Looks

I work as a software engineer day-to-day, and like most engineers in 2025, I've grown comfortably dependent on AI assistants for a lot of the "what's the flag for this again" moments. The CKA does not care about this. It's a fully hands-on, terminal-based exam with a two-hour clock, no autocomplete for your brain, and the particular joy of watching a kubectl command hang while your time ticks away.

If you've never taken a hands-on exam like this before (I hadn't), the learning curve isn't just Kubernetes — it's also relearning how to actually type commands quickly and correctly under pressure. That took longer than I expected.

How I Actually Prepared

Phase 1: Udemy course for the foundations

I started with a Udemy course to get solid on the core concepts. It was good. The networking section was less good — it didn't cover quite everything you'll need for the exam, so I'd recommend supplementing it. I used Gemini a lot here to fill gaps when a concept wasn't clicking. Being able to ask "explain this to me like I'm going to be tested on it, not like I'm building a dissertation" is genuinely useful.

Phase 2: Killer.sh — the humbling

The first time I ran the Killer.sh mock simulator, I scored 16 out of 75 and ran out of time.

I want to be clear: this is not a sign you should give up. Killer.sh is deliberately harder and denser than the real exam. It's designed to make you feel bad so that when you sit the actual thing, the questions feel manageable by comparison. That said, 16/75 is a bracing number to stare at, and it told me exactly where I was: too slow, and not confident enough with the tooling.

Phase 3: Drilling for speed

Going back through the Udemy labs with a different goal in mind — not just getting the right answer, but getting the right answer fast — made a significant difference. The muscle memory you need isn't really about memorising commands. It's about eliminating hesitation: knowing which resource to reach for, how to quickly pull a YAML template, when to skip a question and come back.

Phase 4: Killer.sh, round two

Second mock: 53/93 within the two-hour window, and 58/93 with an extra 12 minutes after time. A completely different experience from the first run. Still not perfect, but I felt genuinely ready.

What I'd Do Differently

My timeline was tighter than ideal, partly because I hadn't done a hands-on exam before and underestimated how long the muscle memory phase takes. If I were doing this again (or when I prepare for the CKS), I'd follow this order:

Official K8s Docs → Killercoda → Udemy Labs → Book the exam → Grind Killer.sh mocks

The key difference: Killercoda earlier in the process, so you're getting reps in a real terminal environment from the start rather than catching up later.

Things That Actually Matter on Exam Day

Clipboard and browser basics

Use Ctrl + Shift + C / Ctrl + Shift + V inside the exam terminal — regular copy-paste doesn't work. Use Ctrl + F in the Firefox docs tab to jump directly to the YAML you need rather than scrolling. These sound obvious but when you're stressed and rushing, muscle memory for even this stuff helps.

Don't babysit hanging commands

If a control plane command is hanging, don't sit there watching it. Open a second terminal tab, move to the next question, come back later. This saved me probably 10–15 minutes across the exam.

The 5-minute rule

If a question has eaten five minutes and you're still unsure, flag it and move on. Get the points you're confident about first. Come back to the hard ones with whatever time remains. This is obvious advice but it's easy to ignore when you're in the middle of something that feels solvable.

Fixing broken clusters: steal good configs

If you're asked to fix a broken cluster component, check how a healthy node in the same (or a different) cluster has it configured. Copying a working config as your baseline is faster and safer than trying to construct one from memory.

Never write YAML from scratch

Use kubectl get -o yaml to pull an existing resource and adapt it. Writing manifests from scratch under time pressure is how you introduce typos that cost you points.

When a node goes NotReady

This order has never failed me:

systemctl status kubelet and journalctl -u kubelet -f
crictl ps and crictl logs
/var/log/pods directly if the container runtime is behaving strangely

File Paths and DNS Worth Memorising

Control plane static pods: /etc/kubernetes/manifests
Kubelet config + certs: /var/lib/kubelet (PKI in /var/lib/kubelet/pki)
CNI config: /etc/cni/net.d/
Service DNS: <service>.<namespace>.svc.cluster.local
Pod DNS: <pod-ip-with-hyphens>.<namespace>.pod.cluster.local

The Command Directory

Commands I actually used, not an exhaustive list of everything kubectl can do.

Cluster context and discovery

kubectl get all
kubectl get pod -l env=prod
kubectl -n <namespace> get deploy,ds,sts,pv,pvc
kubectl --kubeconfig <file> config current-context
kubectl cluster-info --kubeconfig <file>
kubectl api-resources --namespaced -o name

Kustomize

kubectl kustomize <dir>
kubectl kustomize <dir> | kubectl diff -f -
kubectl kustomize <dir> | kubectl apply -f -

Cluster maintenance

openssl x509 -text -noout -in <cert_file>
kubeadm certs check-expiration
kubeadm certs renew <name>
kubeadm token create --print-join-command
systemctl daemon-reload && systemctl restart kubelet
crictl ps -a
crictl logs <container_id>
crictl inspect <container_id>

RBAC

kubectl auth can-i <verb> <resource> --as=system:serviceaccount:<namespace>:<serviceaccount-name>

Workloads and networking

# Base64 without line-wrapping (important)
echo -n "secret-data" | base64 -w 0

# Expose a pod as a ClusterIP service
kubectl expose pod nginx-resolver --name=nginx-resolver-service --port=80 --target-port=80 --type=ClusterIP

# Temporary debug pod, auto-removed on exit
kubectl run test-nslookup --image=busybox:1.28 --rm -it --restart=Never -- nslookup nginx-resolver-service

# Create a pod with multiple labels
kubectl -n <ns> run <pod-name> --image=<image> --labels "key1=val1,key2=val2"

# Curl a service FQDN from inside a pod
kubectl -n <ns> exec <pod-name> -it -- curl <service>.<namespace>.svc.cluster.local

# Rolling restart after a ConfigMap change
kubectl rollout restart deploy <deployment-name> -n <ns>

# Check host routing
ip route show

One Honest Thought on the Exam Format

Hands-on exams made obvious sense before AI could generate a working YAML manifest in seconds. The implicit assumption was that typing commands correctly under pressure proved you understood them. I'm not sure that logic holds the same way anymore. That said, I don't think the CKA is without value — being dropped into broken environments and having to reason your way out is genuinely different from syntax recall. That's a real skill, and probably harder to fake. But I do wonder if the two-hour clock is testing the right thing, or just the most measurable one. Maybe the format needs to evolve rather than disappear — less "can you type this fast" and more "can you diagnose this without a lifeline." The latter feels like what actually matters now.

Final Note

Read every question fully before you start typing. Nervous speed-reading is how you misconfigure a namespace and lose points you should have had. Breathe.

Good luck!

DEV Community: yltw