Open Book Does Not Mean Open Season: What to Memorize for the CKA

Telling a candidate that an exam is open book produces a predictable and slightly dangerous relief. The reasoning goes: if the answers are available, the preparation is lighter. For the CKA the opposite is closer to true. An open book exam with a two hour limit is a reading speed test wearing a costume, and the way to beat it is to need the book as little as possible.

What you are actually allowed to open

The Linux Foundation publishes the permitted list, and it is narrower than most candidates assume. During the CKA you may use:

• https://kubernetes.io/docs/
• https://kubernetes.io/blog/
• https://helm.sh/docs/
• https://gateway-api.sigs.k8s.io/

Language translations of the Kubernetes documentation are permitted too, though the English versions are recommended for the simple reason that they are updated first.

Two restrictions matter. You may use the search box on the Kubernetes documentation site, but you must not open external search results from it. And the material is for your own work on the tasks, not for third party assistance or research. The full policy sits in the Linux Foundation’s certification resources allowed page, and it is worth reading in the original before exam day rather than trusting anyone’s summary, including this one.

The presence of Helm and Gateway API on that list is a quiet signal about the current curriculum. Neither is there by accident.

The arithmetic of looking things up

Roughly fifteen to twenty tasks, one hundred and twenty minutes. Call it six or seven minutes per task if you spread it evenly, which you should not, but it sets the scale.

A documentation lookup that goes well costs perhaps forty seconds: you know the page, you land on it, you copy the block you came for. A lookup that goes badly costs three or four minutes, because you are reading prose to find a field name while a timer runs and your confidence quietly leaks away.

Do that badly four times and you have spent an eighth of the exam reading. At a 66% pass mark you can afford to get tasks wrong. You cannot afford to spend the clock deciding which tasks to get wrong.

So the memorization target is not the content of the documentation. It is the map.

What to know cold

Which resource solves which problem. Given “traffic from outside the cluster should reach these pods, with TLS,” you should reach for the answer without deliberation. This is the single highest-value thing to drill, because it is the decision that precedes every lookup. If you are unsure whether the task wants a Service, an Ingress, or a Gateway, no amount of documentation will rescue you inside six minutes.

The imperative commands that generate manifests. kubectl create deployment, kubectl expose, kubectl run with --dry-run=client -o yaml, kubectl create job --from=cronjob. Starting from generated YAML and editing it is faster and less error prone than typing a manifest from memory, and it removes an entire category of indentation mistake.

Where the examples live. Not the URL, the shape. Knowing that the network policy examples sit in the concepts section rather than the tasks section saves the thirty seconds you would spend guessing.

The verbs that inspect. describe, logs including --previous, get events --sort-by, top. Troubleshooting is 30% of the exam and almost all of it starts with looking at something correctly.

Context switching. Every task names a cluster. Setting context is muscle memory or it is a zero.

What not to bother memorizing

Field names on objects you rarely touch. Full manifest structures for anything more complicated than a Pod. The exact flags of kubeadm subcommands. Storage class parameters for providers you have never used. Anything where the documentation gives you a copyable block and you know which block it is.

This is the part candidates coming from multiple choice exams find uncomfortable, because it feels like not studying. It is studying, just aimed at recall of structure rather than recall of syntax.

How to practise it

The drill that maps to this exam is not reading and it is not watching. It is running a cluster, breaking it deliberately, and fixing it on a clock.

A practical loop:

1. Pick a failure to induce. A bad image tag, a missing ConfigMap, a NetworkPolicy that denies what it should permit, a node cordoned, a full disk on a worker.
2. Induce it without writing down what you did.
3. Come back an hour later and diagnose from symptoms.
4. Time yourself, and note every moment you reached for the documentation and what you were looking for.

That last step is where the study plan writes itself. The lookups you repeat are the things to memorize. The lookups you do once are the things to leave in the book.

Two Killer.sh simulator sessions come with the exam registration, and they are harder than the exam by design. Use them late rather than early, and use them to test pacing rather than knowledge. The same principle shapes our CKA Study Guide, which is explicit chapter by chapter about what to memorize and what to look up.

The underlying point

Open book exams reward people who have organized their knowledge rather than people who have accumulated it. The candidate who knows twenty things precisely and knows where to find the rest will outperform the candidate who half-remembers two hundred.

That is a better model of the actual job, which is the most defensible thing about the way this exam is built.

Sources: Linux Foundation, Certification Resources Allowed, Linux Foundation, Important Instructions: CKA and CKAD.