The Cloud Panda

CKA exam environment tips

The CKA tests what you can do in a terminal in two hours. Most lost points aren't missing knowledge, they're slips: the wrong cluster, a typo in a manifest, a task left half-checked.

Last reviewed . Exam rules change: the Linux Foundation's candidate handbook and the exam's important-instructions page are the source of truth. Read both in the week before your exam.

Before exam day

  • Run the official system check on the computer, network and room you will use, not a different one. Corporate laptops with VPNs and endpoint agents are a common source of trouble.
  • Practise in a small window. The exam runs in a remote desktop inside a secure browser. Practise with a terminal and one browser tab side by side on a single screen, so the layout isn't new on the day.
  • Learn the docs, not just Kubernetes. You can use the official Kubernetes documentation during the exam. Know where the examples for NetworkPolicy, PersistentVolume, etcd backup and kubeadm upgrades live, so you can find them in seconds with the search box.
  • Learn the terminal's copy and paste. In most Linux terminals it's Ctrl+Shift+C and Ctrl+Shift+V. Ctrl+W may close a browser tab instead of deleting a word.

Always know where you are

Tasks run on different clusters and hosts. Answering the right question on the wrong cluster scores zero.

  • Run the task's setup command first, every time. Each task tells you which context to use or which host to ssh to. Copy it from the task text and run it before reading further.
  • Leave every ssh session when you're done. Type exit until you're back at the base prompt before the next task. Nested ssh sessions are how people end up on the wrong machine.
  • Check the prompt. The hostname in the prompt tells you where you are. For root on a node, use sudo -i and remember to exit that too.
  • Name the namespace every time. Pass -n <namespace> on each command rather than changing the context's default namespace, which follows you into the next task.

Write less YAML

Typing manifests from memory is slow and error-prone. Let kubectl write the skeleton:

export do="--dry-run=client -o yaml"
kubectl create deployment web --image=nginx:1.27 --replicas=3 $do > web.yaml
kubectl run tmp --image=busybox:1.36 $do -- sleep 3600 > tmp.yaml
kubectl create role reader --verb=get,list,watch --resource=pods -n app $do
  • Use kubectl explain for field names you half-remember: kubectl explain pod.spec.containers.livenessProbe. It's faster than the docs for a single field.
  • Keep a file per task (t4.yaml, t5.yaml) so you can re-apply or fix it later without starting over.
  • Set up vim for YAML once at the start: printf 'set expandtab tabstop=2 shiftwidth=2\n' >> ~/.vimrc. Tabs in YAML are a classic silent failure.
  • Some fields can't be edited in place. For immutable fields on a running Pod, use kubectl replace --force -f pod.yaml to delete and recreate it in one step.

Edit the control plane safely

The API server, scheduler, controller manager and etcd on a kubeadm cluster are static Pods: the kubelet runs whatever it finds in /etc/kubernetes/manifests.

  • Back up before you edit, and keep the copy outside the manifests directory: cp /etc/kubernetes/manifests/kube-apiserver.yaml /root/. A copy left inside the directory can be started as a second static Pod.
  • Expect kubectl to go quiet while the API server restarts. Watch the container runtime instead: crictl ps -a | grep apiserver, then crictl logs <id> if it keeps exiting.
  • Read the kubelet's view when a static Pod doesn't come back at all: journalctl -u kubelet --since "5 min ago". A YAML error in a manifest shows up there.
  • Give it time. The kubelet checks the directory periodically. Wait half a minute before deciding that your change didn't work.

Manage two hours

  • Do a quick pass first. Read each task, solve the ones you can finish in a few minutes, and flag the rest. Tasks are weighted differently, so note the weight as you go.
  • Set a personal limit, for example ten minutes per task. When you hit it, flag the task and move on. A finished easy task is worth more than a half-finished hard one.
  • Leave 10 minutes at the end to revisit flagged tasks and re-check anything that depends on a component you restarted.

Check every answer

  • Read the task again after you finish it. Names, namespaces, ports, labels and file paths must match exactly.
  • Prove it works: kubectl get the object, describe it for events, and for networking tasks test it from a throwaway Pod: kubectl run t --rm -it --image=busybox:1.36 --restart=Never -- wget -qO- http://svc.ns.
  • When an answer goes in a file, cat the file afterwards and check the path is exactly the one asked for.
  • Don't tidy up what you didn't create. Deleting existing objects or restarting nodes you weren't asked to touch can break other tasks.

Practise it before the exam

These habits stick only through repetition on a real cluster. Every one of our labs starts with a context and a task, just like the exam, and checks your work the moment you're done.

Sign up freekubectl cheat sheet