Lesson 19.1 · CKA Exam Drilling · 11 min read

The exam: what it is and what it is not

In plain words

Imagine a driving test where the examiner doesn't care how you drive, only where the car ends up: parked in bay 7, facing forward, handbrake on. You get 17 short instructions in two hours, each in a different car park, and a stranger checks all the cars afterwards. If you park perfectly in the wrong car park, it counts as nothing.

That's the CKA: 15 to 20 performance-based tasks, two hours, 66% to pass, graded by a script on end state only. Each task tells you where to work (an ssh host or a kubectl config use-context line), and running that line first is the whole game. Names, namespaces and file paths must be exact; tasks are weighted and partially credited.

The CKA tests speed, not knowledge

The problem. Knowing Kubernetes and proving it under time pressure are different skills. The CKA (Certified Kubernetes Administrator) is a hands-on exam from the Linux Foundation and the CNCF (Cloud Native Computing Foundation, the body that looks after Kubernetes): you get real clusters and a terminal, not multiple-choice questions. This chapter trains the speed.

What you need to know already: chapters 15-18 - workloads, networking, storage, scheduling, RBAC, cluster operations. The speed kit from 15.3 (alias k=kubectl, $do).

Everything in chapters 15-18 is the knowledge. The CKA assumes it and asks a different question: can you turn a two-line task into correct cluster state in about seven minutes, sixteen times in a row, on machines you have never seen, with a browser tab of docs as your only help? People who know Kubernetes well fail it on time. People who drilled pass it with time to spare.

So this chapter adds almost no new Kubernetes. It is the same cluster under exam conditions: short tasks, a budget per task, a context switch before each one, and grading on the final state only.

The facts (checked September 2026)


Format	15-20 performance-based tasks (you do the work in a real cluster and a script checks the result), command line only
Duration	2 hours
Pass mark	66%, not curved
Kubernetes version	v1.35 (the environment follows the newest minor within 4-8 weeks of its release)
Price	$445, includes one free retake within 12 months and two killer.sh simulator sessions (killer.sh = an official practice exam that is harder than the real one)
Validity	2 years
Results	by email, usually within 24 hours
Allowed resources	kubernetes.io/docs, kubernetes.io/blog, helm.sh/docs (the docs of Helm, a Kubernetes packaging tool - see the domains lesson), gateway-api.sigs.k8s.io (CKA only)

The docs rule is precise: you may use the search box on kubernetes.io/docs, but you may not follow a search result that leaves the allowed sites. No notes, no second screen, no other tabs.

(simulator) The lab cluster runs v1.34.1. Nothing the drills ask differs between 1.34 and 1.35.

The environment

You sit the exam in the PSI Secure Browser (PSI = the company that runs the online exam and watches you through the webcam - "proctoring"): it shows a remote Linux desktop with a terminal and a Firefox that can open the allowed docs. Each task tells you where to work. Since the 2025 environment change that is usually an ssh host (host names below are made up; the shape is what you will see):

Task 7 (weight 7%)
Solve this question on: ssh cka3962
...

# on the exam: the task tells you which host to ssh to
ssh cka3962
k get nodes
NAME            STATUS   ROLES           AGE   VERSION
cka3962         Ready    control-plane   19d   v1.35.1
cka3962-node1   Ready    <none>          19d   v1.35.1
exit
candidate@base:~$

What the Linux Foundation guarantees on each task host: kubectl with the k alias and bash completion, yq (jq for YAML, 7.11), curl, wget, man pages. The base host you start on does not have them - so k failing on the base host is normal, you forgot to ssh. Nested ssh (ssh from a task host to another host) is not supported: exit back to base first. sudo -i gives you root where a task needs it.

Older exams and many practice environments put every cluster behind a kubeconfig context instead, and the task starts with the line to run:

Use context: kubectl config use-context k8s-c2

Both are the same discipline: the first thing you type for a task is the line that puts you on the right cluster. In this chapter tasks carry a context (kubectl config use-context hk8s); node tasks also need ssh to a node.

(simulator) The lab has one cluster. The exam contexts in your ~/.kube/config (k8s, hk8s, bk8s, wk8s, ek8s, ik8s - the names the older CKA used) all point at it. What is graded is the habit: every object a task asks for must have been written while that task's context was the current one. Each round starts you in a different context on purpose.

Keyboard traps in the remote desktop

Copy/paste in the terminal is Ctrl+Shift+C / Ctrl+Shift+V (plain Ctrl+C sends SIGINT, as it should in a terminal). Other apps use normal Ctrl+C/V.
Ctrl+W in a browser closes the tab. In the exam that tab may be your terminal. Use Ctrl+Alt+W, or never learn the Ctrl+W delete-word habit in the first place.
The Insert key is off: enter insert mode in vim by typing i.
The base node cannot be rebooted. Do not try.
Copy names from the task text (click to copy is supported) rather than retyping them. A typo in a resource name is a zero for that task.

How it is graded

A script checks cluster state and files after the exam. It does not read your history. Consequences:

Only the end state counts. How you got there does not matter - a generator, an edited YAML, kubectl patch, all equal.
Names, namespaces and paths are exact. /opt/course/3/pod.txt is not /opt/course/3/pod. project-tiger is not default.
Tasks are weighted (the weight is shown, typically 2-10%). Several checks per task: partial credit exists. A task 80% done usually scores most of its points; a task never started scores none.
Nothing is graded while you work, so verifying is your job. The graded state is whatever you leave behind - a Deployment still rolling out when time is up may be graded as not ready.

What the preparation looks like

The plan's protocol, which this chapter mirrors:

Daily short tasks (KillerCoda scenarios in the real world, the drills here), weighted to troubleshooting, RBAC and networking - the heavy domains.
killer.sh session one at the start of the block. It is harder than the exam (15-20% harder by the plan's numbers) - treat the score as calibration, not a verdict. Each session gives you the same question set for 36 hours: do it timed once, then redo it untimed until every task is clean.
A wrong-answer log: every miss with its reason, redone until automatic.
killer.sh session two 48 hours before the exam.
Book the exam at a time where a retake would not wreck your week. The platform sometimes fails.

Candidates who complete the killer.sh and KillerCoda mocks report pass rates above 80%; those who prepare mainly from video courses report 45-55%. The variable is terminal time.

How this chapter is built

Lessons (this one and the next five) on the exam, the domains, the speed kit, time, the classic point-losers, and the docs.
The exam terminal mission: the speed kit, from memory, in two minutes.
One drill per task type - 31 of them, spread across the five domains, each one short, timed to the exam's pace, randomized every round (names, namespaces, ports, faults, contexts), graded on world state. They are the core of the chapter: repeat them until each is under its budget.
The random five-task block: five mixed tasks, five contexts, 35 minutes.
Three mock exams: 12, 12 and 16 tasks under a timer, graded like the real one.
A debrief with 40+ exam and interview questions.

Why it helps

Knowing the exam's rules is worth points before you learn anything new. Understanding that only the end state is graded tells you any route is fine (a generator, a patch, an edit), and that you must verify, because nothing tells you whether you succeeded. Knowing that partial credit exists changes how you handle a task you can't finish.

The environment details save you from panics that cost minutes: k: command not found means you're still on the base host and forgot to ssh; Ctrl+W can close your terminal tab; paste is Ctrl+Shift+V. Knowing that corporate laptops often can't run the PSI browser, and that killer.sh is harder than the exam, means you plan the week sensibly instead of being surprised on the day.

FAQ

Does it matter how I solve a task?

No. A script checks the cluster state and files after the exam; it doesn't read your shell history. A generator, a hand-written manifest, kubectl patch or edit all count the same. What matters is that the right object exists with the right name, in the right namespace, on the right cluster, and that it's in the requested state when time is up.

Why does k say command not found?

You're on the base host, not a task host. On the current exam, each task names an ssh host ("Solve this question on: ssh cka3962"), and kubectl, the k alias and completion exist only there. Run the task's ssh line first. Nested ssh isn't supported, so exit back to base before the next task's ssh.

Is there partial credit?

Yes. Each task is several checks, and each one scores. "Create a ServiceAccount, a Role and a RoleBinding" might be three or four checks, so if you run out of time, the parts you did still count. What earns nothing is correct work in the wrong namespace or on the wrong cluster.

What Kubernetes version does the exam use?

A recent minor: the environment follows the newest release within a few weeks of it coming out, v1.35 as of September 2026. The lab here runs 1.34.1, which makes no difference for the drills. Check the Linux Foundation's exam page before booking, since the version and details are updated there.

What keyboard traps should I know about?

Copy and paste in the terminal is Ctrl+Shift+C and Ctrl+Shift+V (plain Ctrl+C sends an interrupt). Ctrl+W in the browser closes a tab, which may be your terminal. The Insert key doesn't work, so type i in vim. Copy names from the task text by clicking rather than retyping, because a typo in a name is a zero.

In an interview Junior

The CKA is graded on end state only. How does that change how you work?

A script checks the cluster and the files afterwards; it never reads your history. So:

How you got there does not matter - a generator, edited YAML or kubectl patch all count. Use the fastest.
Where matters completely: the right objects on the wrong cluster or in the wrong namespace score zero. The first thing typed for every task is its ssh host or kubectl config use-context line, then -n NS on every command.
Names and paths are exact: /opt/course/3/pod.txt is not /opt/course/3/pod. Copy them from the task text.
Nothing is checked while you work, so verifying is your job: get, describe, auth can-i, cat the answer file.
Partial credit exists - a task is several checks, so an 80% task still scores most of its points; a task never started scores none.
A rollout still running when time is up may be graded as not ready.

Also asked: How do you keep from making changes in the wrong cluster or namespace? · How did you prepare for the CKA? · What is allowed during the CKA exam?

Practise this lesson in the terminal Free, in your browser - a real Ubuntu terminal to try it in, with missions that check your work.