CKA Roadmap: Study by Exam Weight, Not by Book Order
Most CKA study plans follow the chapters of whichever study guide you picked. It feels thorough, and it quietly spends your time in the wrong places.
The numbers make the case better than any argument. Below is how the exam weights its five domains, against how many pages the study guide I used spends on each.
The gap
| Domain | Exam weight | Study guide pages | Share of the book | Gap |
|---|---|---|---|---|
| Cluster Architecture | 25% | 78 | 29.5% | slightly over |
| Workloads & Scheduling | 15% | 86 | 32.6% | 2.2× over |
| Storage | 10% | 24 | 9.1% | about right |
| Services & Networking | 20% | 50 | 18.9% | about right |
| Troubleshooting | 30% | 26 | 9.8% | a third of what it needs |
Page counts across the 264 pages covering the five domains in Benjamin Muschko, CKA Study Guide, 2nd edition (O'Reilly, 2026), which tracks Kubernetes 1.33. Introduction and appendices excluded.
Two things fall out of that table.
Troubleshooting is the heaviest domain and the thinnest one. Thirty percent of the score, under ten percent of the pages. Read the whole book and you are still short exactly where the exam counts most. That gap has to be closed with practice the book does not provide.
Workloads & Scheduling is a time trap. Fifteen percent of the score, a third of the pages. Study in chapter order and you spend roughly a third of your time on a seventh of your marks.
None of this is a criticism of the book. Pods and Deployments are foundations every other domain leans on, and a study guide has to teach them properly. The problem is only in how a reader allocates hours — which is exactly what a roadmap is for.
What that changes
Order by weight, not by chapter. After setting up a cluster, troubleshooting comes first. Then Cluster Architecture, Networking, Workloads, Storage — in descending order of marks.
There is a real tension in that order: debugging a cluster assumes you know what a healthy one looks like. That is why the two setup posts come before anything else. Building the cluster by hand is the fastest way to learn what "healthy" means.
Type more than you read. At most 30% of the time on reading, at least 70% on typing commands. The exam is performance-based — you are graded on a terminal, not a quiz — and recognising a command is not the same as producing it under a clock.
Budget honestly. Reading alone came to about 19.5 hours. Applying the 30/70 rule took the plan to 89 hours over 30 days — about three hours a day, every day, with no slack. If that is more than you have, cut in a deliberate order rather than wherever you run out:
| Cut first if you fall behind | Never cut |
|---|---|
| Gateway API in depth | etcd backup and restore |
| HorizontalPodAutoscaler | Cluster upgrades |
| Topology spread constraints | RBAC basics |
| Aggregated ClusterRoles | Services and DNS |
| NetworkPolicy | |
| All of troubleshooting |
The roadmap
Posts are added as they are written. Each links here, and the series closes with the error log from this preparation and a retrospective.
Phase 0 — A cluster of your own
| # | Post | Status |
|---|---|---|
| 1 | Build a two-node kubeadm cluster on GCP | ✅ published |
| 2 | Set up your terminal for the exam | ✅ published |
Phase 1 — Troubleshooting · 30%
| # | Post | Status |
|---|---|---|
| 3 | Troubleshooting broken applications | coming |
| 4 | Troubleshooting a broken cluster | coming |
Phase 2 — Cluster Architecture · 25%
| # | Post | Status |
|---|---|---|
| 5 | Install and upgrade a cluster with kubeadm | coming |
| 6 | Back up and restore etcd | coming |
| 7 | RBAC, ServiceAccounts and kubectl auth can-i | coming |
| 8 | Helm and Kustomize | ✅ published |
| 9 | Operators and CRDs | ✅ published |
Phase 3 — Services & Networking · 20%
| # | Post | Status |
|---|---|---|
| 10 | Services and CoreDNS | coming |
| 11 | Ingress: rules, classes and the controller that reads them | ✅ published |
| 12 | Migrate from Ingress to Gateway API | ✅ published |
| 13 | NetworkPolicy | coming |
Phase 4 — Workloads & Scheduling · 15%
Deliberately the shortest phase. Six book chapters, compressed into what the exam actually asks for.
| # | Post | Status |
|---|---|---|
| 14 | Workloads in one pass: Pods, Deployments, ConfigMaps, resources | coming |
| 15 | Roll out a ConfigMap change: TLS 1.3 on NGINX | ✅ published |
| 16 | Configure a HorizontalPodAutoscaler | ✅ published |
| 17 | Scheduling: affinity, taints and tolerations | coming |
Phase 5 — Storage · 10%
| # | Post | Status |
|---|---|---|
| 18 | PersistentVolumes, claims and StorageClasses | coming |
Wrap-up
| # | Post | Status |
|---|---|---|
| 19 | The error log: every mistake, and the command that fixes it | coming |
| 20 | Retrospective | coming |
How each post is built
Every lab in the series follows the same six parts, so they read as one piece:
- The task — an exam-style scenario, written from scratch
- The solution — the commands, in order
- Verification — how to prove it worked, with the expected output
- Traps — what went wrong when I did it, taken from the error log
- Speed — how long it took, and the imperative shortcuts that cut it down
- The docs page — the exact page on kubernetes.io, which you can open during the exam
On the command-heavy posts, a checklist appears alongside the steps so you can tick them off and come back later to exactly where you stopped.
Ground rules
No real exam questions. Every scenario here is written from scratch. The exam is covered by a candidate agreement, and nothing in this series reproduces its content.
Real clusters, not sandboxes. The labs run on a two-node kubeadm cluster on GCP. A browser sandbox hides the part where you break something by running a command on the wrong machine — which, going by the error log, is the single most common mistake I made.
Docs over memory. Where something comes from the Kubernetes documentation, the post links the page, because finding that page fast is itself an exam skill.
The exam, briefly
- Performance-based: you solve tasks in a live terminal against real clusters
- About two hours
- The official Kubernetes documentation is available during the exam
The authoritative list of objectives is the CNCF curriculum, which was substantially revised in 2025 — Gateway API and CRDs/Operators both moved into scope. Pricing, passing score and certificate validity are on the Linux Foundation's exam page. They change over time, so they are linked here rather than copied.