How to Prepare for the CKA Exam

Preparing for the Certified Kubernetes Administrator (CKA) exam comes down to one governing principle: every hour of preparation should end with your hands on a cluster. The CKA is performance-based — two hours of live administration tasks in real Kubernetes environments — so reading and watching are only ever the warm-up for doing. The plan below turns that principle into a concrete schedule: set up a practice environment in the first week, work through the curriculum domain by domain with deliberate drills, then spend the final stretch on timed rehearsal and benchmarking until your practice scores clear the passing bar with room to spare.

One scoping note before the plan. This article prescribes how to study; it assumes you already know what the exam is. If you have not yet confirmed the format, domain weights, pricing and registration mechanics, read the Certified Kubernetes Administrator (CKA) Guide first — and if you are still weighing whether the exam's demands match your current level, the honest assessment in How Hard Is the CKA Exam? is the place to settle that.

Step 1: Anchor your plan to the current curriculum

Start by downloading the current curriculum from the official Linux Foundation CKA page and pinning it somewhere visible. As of August 2026 the exam is based on Kubernetes v1.35, and the environment tracks new minor versions within four to eight weeks of each release, so the live page — not a blog post, not last year's course notes — is your source of truth.

The five domains and their weights are your time-allocation budget:

• Troubleshooting — 30%
• Cluster Architecture, Installation & Configuration — 25%
• Services & Networking — 20%
• Workloads & Scheduling — 15%
• Storage — 10%

Let the weights discipline you. Troubleshooting and cluster architecture together carry 55% of the marks, yet they are the areas self-learners practise least because tutorials favour tidy, working examples. Your plan should invert that: more than half your hands-on time belongs to building clusters and breaking them.

Check any course or book you plan to use against the February 2025 curriculum revision, which added Gateway API alongside Ingress, brought in Helm and Kustomize, made CRI/CSI/CNI integration troubleshooting explicit, added dynamic volume provisioning, and replaced Pod Security Policies with Pod Security Standards. Material that predates the revision will drill you on at least one removed topic and miss several current ones.

Step 2: Build your practice environment in week one

You cannot pass a hands-on exam without a place to put your hands, so environment setup is week one's job — not something deferred until after the theory.

You have three workable options, and the right answer for most candidates is "at least two of them":

1. A local multi-node cluster using a lightweight tool on your own machine. This is your daily driver: instant, free, endlessly rebuildable. Its limitation is that pre-packaged local clusters hide exactly the installation and component-level plumbing the exam's second-largest domain tests.
2. Clusters you bootstrap yourself on virtual machines — local VMs or small cloud instances — using the standard cluster-bootstrapping workflow. This is non-negotiable for the Cluster Architecture, Installation & Configuration domain: you need to have stood up a cluster from bare nodes, joined workers to it, and upgraded it, more than once.
3. Disposable browser-based playgrounds for odd moments of practice when your main setup isn't to hand.

Two environment rules pay off all the way to exam day. First, practise in a plain terminal with a terminal editor — the exam gives you a terminal, not your IDE, and delivery runs through the PSI Bridge secure-browser platform on a single monitor, so rehearsing in a maximally comfortable setup builds habits the exam will confiscate. Second, get fluent with the Kubernetes documentation site as a working tool, because performance-based CNCF exams permit access to specified official documentation during the exam. Confirm the exact allowed-resources policy in the Linux Foundation candidate documentation, then practise navigating the docs quickly enough that a lookup costs you thirty seconds, not five minutes.

Step 3: The week-by-week plan

The schedule below is written as eight weeks because that suits a working professional giving the CKA consistent part-time effort with some prior Kubernetes exposure. It is a template, not a prescription — there is no official figure for required study hours, and your real timeline depends on your starting point. Compress it if you administer clusters daily; stretch it if Kubernetes is new. The sequence matters more than the calendar.

Weeks 1–2: Environment, workloads and the kubectl habit

Build your practice environments (Step 2), then work the Workloads & Scheduling domain: Deployments, ReplicaSets, DaemonSets, Jobs, scheduling controls, resource requests and limits, ConfigMaps and Secrets. This domain comes first not because of its 15% weight but because it builds the kubectl fluency everything else rides on.

From day one, make speed a habit rather than a later add-on:

• Generate manifests with kubectl's dry-run output instead of writing YAML from scratch, then edit.
• Learn the explain and shorthand facilities until they are reflexive.
• Do every exercise twice — once to solve it, once to solve it fast.

Finish week two by deploying an application with Helm and applying a Kustomize overlay, both squarely on the current curriculum.

Weeks 3–4: Cluster architecture, installation and configuration

Bootstrap a cluster from plain VMs. Then do it again without your notes. Join a worker node, drain and cordon nodes, back up and restore the key-value datastore backing the control plane, and perform a version upgrade of the control plane and workers. Spend real time on the interfaces the 2025 revision emphasised — container runtime (CRI), storage (CSI) and networking (CNI) integration — because "the cluster is unhealthy at a component level" is prime exam territory.

This fortnight is the plan's least glamorous and most valuable. A quarter of the exam's marks live here, and this is also where you build the mental model of what runs where that makes troubleshooting tractable later.

Week 5: Services, networking and storage

Cover Services of each type, Ingress and the Gateway API, DNS behaviour inside the cluster, and network policies — verifying every construct with actual traffic, not just a created object. Then storage: PersistentVolumes, PersistentVolumeClaims, StorageClasses and dynamic provisioning, mounting volumes into workloads and proving data survives a pod restart.

The verification habit you practise this week — make the change, then prove it works — is worth marks directly, because the exam grades the cluster's final state, and a Service that doesn't actually route traffic earns nothing however correct its YAML looks.

Week 6: Troubleshooting as a deliberate discipline

Now attack the 30% domain head-on. Troubleshooting cannot be read into existence; it has to be drilled. The most effective method is break-and-fix: sabotage your own cluster, walk away for an hour, come back and repair it against a timer. Stop a node component and diagnose the symptoms. Misconfigure a manifest's image, its probes, its service selector. Break DNS. Fill a node so pods won't schedule.

Work to a repeatable diagnostic sequence — observe the symptom, check events and logs, form a hypothesis, test it, verify the fix — until the sequence survives time pressure. If you have a study partner, sabotage each other's clusters; problems you didn't plant are far closer to exam conditions.

Weeks 7–8: Timed rehearsal and benchmarking

The final fortnight is rehearsal, and rehearsal means the clock is always running. Your exam purchase includes two killer.sh simulator sessions of 36 hours each — the simulator presents 17 questions per session and is deliberately demanding. Spend one session at the start of week 7 as a diagnostic and keep the second for the final days as a dress rehearsal. Between them, drill with other timed material: mixed-domain task sets, two-hour blocks, no pauses.

Benchmark deliberately rather than vaguely. After every timed session, score yourself against the 66% passing bar, then log three numbers per task: right or wrong, minutes spent, and whether you verified the result. Feed the log back into your remaining study time — a weak domain gets the next day's drills; a slow-but-correct pattern gets speed work; skipped verifications get a rule that no task is finished until checked. A set of CKA practice questions organised by exam objective is useful here precisely because it lets you isolate one weak domain and hammer it, rather than always rehearsing the full mix. Treat all practice material as a tool for finding and fixing weaknesses in your understanding of the objectives — memorising specific answers defeats the purpose and fails against a live cluster anyway, since the exam grades what you can do, not what you recognise.

Your exit criterion for booking confidence: two consecutive full-length timed sessions clearly above the passing bar, with time left over for verification passes.