CKA exam tips for 2026: time management, kubectl speed and the exam environment

The CKA exam in numbers

The CKA facts below come from the Linux Foundation certification page and candidate documentation. The two numbers that shape your strategy are the task count and the time: 15-20 performance-based tasks in 120 minutes. The pass mark of 66% means you can leave some work unfinished and still pass, which is why triage matters as much as speed.

The exam environment, as the instructions describe it

You work in a remote Linux desktop inside the PSI Secure Browser. The exam content is in a panel on the left; the desktop has a terminal and a Firefox window for the allowed documentation. Each task names a host in an infobox. You connect to it with ssh, do the work there, and exit back to the base system, whose hostname is base. Nested ssh is not supported, and you must not reboot the base node.

• Elevated privileges on any host: sudo -i, or sudo per command.
• Tools on every SSH host: kubectl with the k alias and Bash completion, yq, curl, wget and man pages.
• Copy and paste in the terminal: Ctrl+Shift+C and Ctrl+Shift+V; use Ctrl+Alt+W instead of Ctrl+W.
• The Insert key is disabled; enter insert mode in vim with i.
• An on-screen keyboard is available for characters your keyboard layout cannot produce.

Time management: a triage routine for two hours

With 15-20 performance-based tasks and 120 minutes, a single stubborn task can cost two easy ones. A triage routine stops that from happening. Read every task once quickly, do the short ones first, and give each longer task a fixed budget before you flag it and move on. A task you can finish and verify is worth more than two you leave half done.

1. 1Skim all tasks and note the ones you can finish in a few minutes.
2. 2Do those first, verifying each result with a get or describe before moving on.
3. 3Start the longer tasks with a budget of about 8 minutes each; flag and leave any that exceed it.
4. 4Return to the flagged tasks with the remaining time, closest to finished first.
5. 5Keep the last few minutes to re-check the namespace and host of anything you changed late.

Imperative kubectl commands that save minutes

Typing a manifest from memory is slow and error-prone. Kubectl can generate most objects for you, either directly or as YAML you then edit. The pattern to drill is kubectl create or run with --dry-run=client -o yaml redirected to a file, followed by a quick edit and kubectl apply. Combined with the k alias and Bash completion that are already configured, it cuts most tasks to a handful of commands.

The image names and flags above are examples; what matters is the pattern. Practise them until you type them without thinking, then practise the edits that follow, because most tasks need one or two fields the generator does not set.

What each domain asks you to do

The CKA curriculum for v1.37 lists five domains. Troubleshooting is the largest at 30%, followed by Cluster Architecture, Installation and Configuration at 25%. The newer items in the curriculum deserve attention because older preparation material may not cover them: Helm and Kustomize for installing cluster components, the Gateway API for ingress traffic, CRDs and operators, and a highly available control plane.

Troubleshooting drills worth repeating

Troubleshooting rewards a fixed order of checks more than clever guesses. When something does not work, look at the object, its events, its logs and the thing it depends on, in that order. For node and control plane faults, the kubelet and the static Pod manifests are where most problems hide. Repeat the same handful of broken scenarios until you can find the fault in a few minutes.

• Pod not running: k describe pod for events, k logs (with --previous for a crash), then the image, the probes and the resources.
• Service not answering: compare the Service selector with the Pod labels, then check the endpoints and the target port.
• Node NotReady: ssh to the node, check systemctl status kubelet and journalctl -u kubelet.
• Control plane component down: inspect the static Pod manifests under /etc/kubernetes/manifests on the control plane node.
• DNS failures: test resolution from a Pod and check the CoreDNS Pods and their ConfigMap.

The final two weeks

In the last two weeks, switch from learning to rehearsing. Use the Killer.sh simulator included with the registration: the FAQ gives two attempts per registration, each with 36 hours of access from activation, so take the first about ten days out and the second a few days before. Between them, redo every task you got wrong, timed. Read the candidate instructions once more and run the PSI system check on the machine you will use.

Keep your practice cluster on the exam's minor version where you can, because flags and API versions change between releases. CKA hands-on labs are in preview: the GoldenKube CLI runs its scenarios on your own machine, but it has no public release yet.

On the day before, stop adding material. Review your list of recurring mistakes, check your ID against the exam checklist, and prepare the room according to the rules in the shared guide on Linux Foundation exams.

Habits that stop silent point losses

Many lost CKA points are not knowledge gaps. They are tasks done correctly in the wrong place, or done almost completely. A short routine at the start and end of every task prevents most of them, and it costs well under a minute.

1. 1Before typing anything, connect to the host or switch to the context the task names, and check the namespace it asks for.
2. 2Generate YAML with --dry-run=client -o yaml instead of writing it from memory, then edit only what the task asks.
3. 3Use kubectl explain for a field you are unsure of; it is faster than searching the docs.
4. 4After applying, read the object back with kubectl get or describe and compare it with every detail in the task text.
5. 5For anything that should run, wait until it is Running or Ready; a created but crashing Pod usually scores nothing.
6. 6Note the task number of anything unfinished and return to it after the first pass.