CKS Study Plan
This plan assumes something the CKS itself checks at registration: you already hold an active, non-expired CKA. That's not a formality — see CKS — the exam for the prerequisite explained in full — and it changes what a study plan for this exam actually needs to do. It doesn't need to rebuild kubectl fluency or the object model from nothing; the CKA already proved you have both. What it needs to do is redirect that fluency at one narrower question, asked six different ways: not "does this apply cleanly" but "does this actually close the hole." The exam's own math tells you where the hours belong. Six domains, and unlike the CKA's one dominant domain, CKS spreads its weight across three domains tied at 20% each — Minimize Microservice Vulnerabilities, Supply Chain Security, and Monitoring, Logging and Runtime Security — worth 60% of the score between them. This page lays out an eight-week plan sized to that shape, pointing at this course's own blueprint, deep dives and labs, plus genuine cross-links into DevSecOps's supply-chain and runtime shelves for the two areas this course deliberately keeps light.
Picture the same apartment building the CKS exam page describes — you're already trusted with the manager's master keys, and now you're training specifically for the night-guard badge. A good night guard doesn't spend equal time on every line of the job just because there are six lines on the clipboard. Three of those lines — checking every delivery before it's allowed upstairs, patrolling for a break-in while it's happening, and keeping a logbook someone would actually notice trouble in — are worth double what the other three are, so a sensible trainee puts in twice as many practice shifts on those three. This plan does exactly that: a full week each for the big three, and a full week each for the smaller three too, because a guard who's brilliant at checking deliveries but never learned to lock the boiler-room door still leaves a way in.
The domain-weighted study budget
☺ Like you're 10: Six parts to the test, and they're not sized the same — three of them are worth double the other three, so your calendar shouldn't treat all six equally.
These are the six domains and weights exactly as published in the CNCF's CKS Exam Curriculum, version 1.34 — the same version the CKS exam page transcribes in full, including the worked examples for each one. This page doesn't re-derive that substance; it turns the same six weights into a calendar. There are six domains, no sub-weights, and they sum to exactly 100% — 15 + 15 + 10 + 20 + 20 + 20.
Underneath those six percentages sit 26 published competencies — 5 in Cluster Setup, 4 each in Cluster Hardening, System Hardening, Minimize Microservice Vulnerabilities and Supply Chain Security, and 5 in Monitoring, Logging and Runtime Security. Turning weight into an hours budget, in the curriculum's own domain order:
| Domain | Weight | Competencies | Study-budget hours |
|---|---|---|---|
| 🐦 Cluster Setup | 15% | 5 | ~15 hrs |
| 🐢 Cluster Hardening | 15% | 4 | ~15 hrs |
| 🦉 System Hardening | 10% | 4 | ~10 hrs |
| 🔑 Minimize Microservice Vulnerabilities | 20% | 4 | ~20 hrs |
| 🦫 Supply Chain Security | 20% | 4 | ~20 hrs |
| 🐘 Monitoring, Logging & Runtime Security | 20% | 5 | ~20 hrs |
| Domain core, total | 100% | 26 | ~100 hrs |
Add roughly ~8 hours to stand up a security-oriented lab and ~15 for timed mocks and a final readiness pass, for a full plan of about ~123 hours across eight weeks — call it 15 hours a week. That total is deliberately lighter than the CKA plan's ~125–130, not because CKS is the easier exam — it demonstrably isn't — but because this plan doesn't have to spend a foundations week teaching kubectl fluency the CKA already certified. Compress the proportions into five or six weeks if you already run security tooling daily; stretch to ten if study time is scarce. The ratio between domains, not the total, is what this plan is actually protecting.
An eight-week roadmap
☺ Like you're 10: Here's the actual calendar — which week gets which domain, and exactly which pages on this course, and occasionally on DevSecOps, to use that week.
Eight weeks, sized to the budget above. No single domain gets two full weeks the way CKA's Troubleshooting did — even the biggest CKS domain, at 20%, is smaller than CKA's 30% — so each of the six domains gets exactly one focused week, with the three 20% domains stacked back to back in weeks 5–7 so the momentum carries. The plan opens with a foundations week that isn't a scored domain at all, and closes the same way, entirely on timed practice.
| Week | Focus | Hours | What you actually do |
|---|---|---|---|
| 1 | Foundations & the CKA gate (not scored) | ~8 | Confirm your CKA is still active — the certifications ladder page has the gate spelled out if you're unsure — then rebuild your lab with the toolchain this exam expects: kube-bench, cosign, and a CNI that actually enforces NetworkPolicy, such as Cilium or Calico (plain kindnet silently accepts and ignores the objects). Read CKS — the exam start to finish and skim Security: Defense in Depth as a refresher. |
| 2 | 🐦 Cluster Setup — 15% | ~15 | Default-deny-then-one-allow NetworkPolicy, CIS benchmark checks with kube-bench against etcd/kubelet/API server, Ingress with TLS, blocking Pod egress to the node metadata endpoint, and checksum-verifying platform binaries before installing them. Work Networking & the CNI and the Cluster Setup section of the CKS exam page; build it in Capstone Part 3 and pressure-test it in the networking-failure drill. |
| 3 | 🐢 Cluster Hardening — 15% | ~15 | RBAC built for least exposure, disabling the default ServiceAccount token automount, locking down API access, and upgrading a cluster specifically to close a known CVE rather than as routine maintenance. Work RBAC & Admission Control and the kubeadm guide for the upgrade drill; build it in Capstone Part 5 and the RBAC-hardening drill. |
| 4 | 🦉 System Hardening — 10% | ~10 | Trimming host OS footprint, least-privilege node IAM, minimizing external network access, and the two kernel tools the curriculum names by hand — seccomp and AppArmor — plus sandboxed runtimes selected with a RuntimeClass. The smallest domain by weight; don't let that shrink it to zero attention. Read the System Hardening section of the CKS exam page and DevSecOps's Kubernetes Security Deep Dive for the host/kernel layer this course keeps deliberately light. |
| 5 | 🔑 Minimize Microservice Vulnerabilities — 20% | ~20 | Pod Security Admission end to end — three standards, three modes — Secrets versus real secret management, isolation via namespaces and sandboxed containers, and pod-to-pod encryption. Rebuild the worked restricted Pod on the CKS exam page from memory, then read Platform Engineering's Secrets & Workload Identity; apply it in Capstone Part 5. |
| 6 | 🦫 Supply Chain Security — 20% | ~20 | Minimal base images, generating and reading an SBOM, scanning, static analysis, signing, and an admission-time gate that actually enforces all of it. The domain this course covers most lightly on its own — spend most of the week on DevSecOps's Trivy and Sigstore & cosign guides, plus Kyverno for the enforcement layer; the Supply Chain section of the CKS exam page shows the shape of the gate to recognize. |
| 7 | 🐘 Monitoring, Logging & Runtime Security — 20% | ~20 | An audit Policy wired into the API server, behavioral and runtime detection, naming the phase of an attack from an alert, and container immutability at runtime. Work Observability on Kubernetes and the audit-policy example on the CKS exam page, then DevSecOps's Falco guide for the syscall-level layer an audit log alone doesn't cover. |
| 8 | Mock exams, speed & readiness (not scored) | ~15 | Two full timed mock exams, a daily pass through the kubectl fluency baseline — still the actual bottleneck under a two-hour clock — flashcards for anything still shaky, and the readiness checkpoint below before you book. |
What changes once grading asks "did this actually close the hole"
☺ Like you're 10: Applying a rule without an error message isn't the same as the rule actually working — the exam only credits the second one, and only your own testing tells them apart.
The CKA already taught you that grading looks at end state, not intent. CKS sharpens that same habit into something more specific: for every control you apply, try to do the exact thing it's supposed to now prevent, and confirm — don't assume — that it's prevented. A NetworkPolicy that applied without error and a NetworkPolicy that actually drops the packet are two different facts, and the exam only ever scores the second one.
# after a default-deny NetworkPolicy — prove the deny, don't assume it kubectl exec -n payments deploy/api -- wget -T2 -qO- http://other-svc.storefront.svc.cluster.local \ || echo "blocked, as expected" # after labeling a namespace enforce=restricted — prove the rejection message # actually reads the way you think it does kubectl apply -f privileged-pod.yaml --dry-run=server # should fail; read every line it names # after a Kyverno/Gatekeeper signature gate — prove an unsigned image # is refused at admission, not merely warned about kubectl run probe --image=registry.internal/unsigned-test:latest # should be denied, not just logged
A security control that applies cleanly and a security control that actually stops the thing it's named after are not the same fact, and the exam only ever grades the second one. Build the habit of trying to break your own fix before you move to the next task on any practice run — it's the single highest-leverage minute in this whole plan, and it's the exact muscle the CKS exam page's worked examples are asking you to have.
Resources: this course, borrowed depth, and timed practice
☺ Like you're 10: Two of the six domains here go past what this course teaches on its own — know exactly when the plan means for you to open a different course.
Studying "everything you can find" wastes hours; studying the right resource for the right week doesn't. This table is deliberately honest about which pages belong to this course and which are borrowed.
| Resource | Use it for |
|---|---|
| The published curriculum — github.com/cncf/curriculum | The exact competency wording, and confirming the version matches v1.34. |
| The Kubernetes docs, plus the named security-project docs | CKS historically permits a wider allowlist than the CKA's — practice finding things in the exact sites you'll be allowed on the day. |
| This course's hub — CKS — the exam | The full domain-by-domain substance and worked YAML/bash examples this plan schedules against; read it once in week 1, then return to it domain by domain. |
| This course's own deep dives & tools — networking, RBAC & admission, defense in depth, observability, Cilium, kubeadm | The mechanics behind Cluster Setup, Cluster Hardening and half of Monitoring — this course's own depth. |
| DevSecOps's supply-chain & runtime shelf — Trivy, Sigstore & cosign, Kyverno, Falco, Kubernetes Security Deep Dive | The two domains — Supply Chain Security, and the runtime half of Monitoring — this course deliberately keeps light. |
| Platform Engineering's Secrets & Workload Identity | Secrets-management depth beyond the "a Secret is base64, not encryption" headline, for the Microservice Vulnerabilities domain. |
| The capstone & drills — Capstone Part 5, RBAC-hardening drill, networking-failure drill | Building and breaking real controls on a real cluster — the only practice that resembles the exam. |
| Timed practice on this course — CKS Practice Tasks, Mock Exam · Set 1, Set 2 | Graded-on-end-state drills under a clock — the closest rehearsal for the actual exam format this course offers. |
| An official practice simulator (commonly bundled with registration) | The one resource that matches the exact exam UI and environment — confirm what your specific purchase includes. |
| Second opinions on the same exam — Platform Engineering's CKS page, SRE's CKS page, DevSecOps's CKS page, DevOps's CKS page | The same six domains explained from a different angle — worth reading once this plan feels familiar. |
Keep a running weak-spot log rather than trusting memory — the Field Notes page on this course is built for exactly that, and rereading it in week 8 is usually faster than re-doing a whole domain from scratch.
Readiness checkpoint — are you actually ready to book
☺ Like you're 10: Don't book the exam because the calendar says week 8 — book it once you can actually do these things, cold, under a clock, and once the other badge is still valid too.
Booking on a date rather than on readiness is the single most common way people waste an exam fee, and CKS adds a wrinkle the CKA doesn't have — a second certification's expiry date to watch. Before you pay, you should be able to answer "yes" to all of these without hesitating:
1. Can you write and apply a default-deny NetworkPolicy and prove — not assume — that egress is actually blocked, in under five minutes? 2. Can you label a namespace enforce: restricted and, from the rejection message alone, name every field the offending Pod is missing? 3. Can you generate an SBOM, scan it, sign the image with cosign, and have a live admission gate refuse the same image unsigned? 4. Can you write an audit Policy that logs RBAC changes in full while capping Secrets access at Metadata, without looking up the four levels? 5. Can you set automountServiceAccountToken: false and explain, from memory, exactly what credential it stops from sitting on disk? 6. Is your CKA active today, and will it still be active on the date you'd actually sit the CKS? 7. Have you scored above the published pass mark on both of this course's CKS mock exams, inside the two-hour limit?
If more than one or two of those still feels shaky, that's not a reason to panic — it's a precise list of what to re-run before you spend the fee. Loop back to the matching week above, not to the whole plan. Item 6 is the one item on this list that isn't really about study at all — mark your CKA's expiry date on the same calendar you're using for this plan, today.
Exam logistics — verify these yourself before you pay
☺ Like you're 10: The shape of the test changes now and then, and CKS adds a second clock to watch besides — read the official page before you hand over any money.
The details below are what the Linux Foundation and CNCF publish and what candidates consistently report. They're here to help you plan a calendar, not to be quoted back at anyone.
| Item | What is generally published |
|---|---|
| Format | Online, remotely proctored, performance-based — real hardening and detection tasks on live clusters, graded on end state |
| Duration | Roughly 2 hours |
| Prerequisite | Active, non-expired CKA — enforced at registration, the one formal gate anywhere on this course's ladder |
| Task count | Historically around 15–16 tasks |
| Passing score | Historically in the high-60s |
| Validity | 2 years from the date you pass — a separate clock from your CKA's own expiry, which must independently still be valid when you schedule |
| Retake | Registration has historically included one free retake |
| Price | Around USD $445 list; bundles and regional pricing are common |
| Curriculum | 26 competencies across 6 domains; this plan follows v1.34 — confirm the version current when you sit |
| Permitted resources | Historically wider than the CKA's — Kubernetes docs plus a short list of named security-project docs; confirm the current allowlist before you sit |
This page is an independent, unofficial study resource — not affiliated with the CNCF or the Linux Foundation. Price, duration, pass mark, retake policy, permitted documentation, validity and curriculum version all change over time. Confirm current details on the official Linux Foundation CKS page and the CNCF certification page before you pay for anything, and read the Candidate Handbook in your LF portal. The curriculum itself is published openly at github.com/cncf/curriculum. See Kubernetes Certifications for this course's full ladder, and the sibling Golden Astronaut course for the other nine CNCF certifications, LFCS, and the Kubestronaut and Golden Kubestronaut programs if the CKS is one stop on a longer road for you.
Nutty: I've sorted all twenty-six competencies into eight weeks. Three of them get a full week each even though they're technically "only" one week, same as the small ones.
Gizmo: Sounds like the small ones got shortchanged, then. Just skim System Hardening the night before — it's only 10%, who's even going to notice. 🤑
Timmy: The exam notices, Gizmo. Ten percent of a two-hour exam is real minutes, and "skim it the night before" is exactly how someone leaves a seccomp profile unset.
Benny: Also — I rebuilt the worked Pod from the blueprint page from memory this morning and forgot automountServiceAccountToken: false. One missing line, one extra credential just sitting in the container.
Nutty: Which is exactly why week five isn't "read about Pod Security Admission" — it's "get rejected by it, on purpose, until the rejection stops surprising you."
Remy: And don't save the timed mocks for week eight in your head, either. A five-minute timer on tonight's NetworkPolicy exercise still counts.
Timmy: Right. Every week from week two on ends with one thing you deliberately try to break. Same habit, every single week.
1. Why doesn't this plan need as long a foundations week as the CKA plan does? 2. Name the six CKS domains and their weights, and the three that together make up 60% of the exam. 3. Roughly how many total study hours does this plan budget, and why is that total lighter than the CKA plan's despite CKS being the harder exam? 4. Name one domain this course teaches at full depth on its own, and one domain this plan sends you to DevSecOps for instead — and why the split. 5. What's the difference between "a control applied without error" and "a control that closes the hole," and why does the exam only credit the second one? 6. Name two separate things that both have to be true before you book the CKS.
Check your answers
- Because it doesn't have to teach
kubectlfluency or the object model from nothing — the active CKA this plan assumes already certified both, so week 1 only has to add the security-specific tooling on top of a lab you can already drive. - Cluster Setup 15%, Cluster Hardening 15%, System Hardening 10%, Minimize Microservice Vulnerabilities 20%, Supply Chain Security 20%, Monitoring, Logging and Runtime Security 20% — the last three, tied at 20% each, are 60% of the exam together.
- Roughly ~123 hours: about 100 hours split across the six domains in proportion to their weight, plus ~8 for a security-lab setup week and ~15 for mocks and readiness. It's lighter than the CKA plan's ~125–130 because that CKA fluency is the assumed starting point here, not something this plan also has to build.
- Any reasonable pair, e.g.: Cluster Setup and Cluster Hardening are taught at full depth on this course's own networking and RBAC & admission pages; Supply Chain Security is sent to DevSecOps's Trivy, cosign and Kyverno guides because this course keeps that domain deliberately light rather than duplicating a sibling course's deeper shelf.
- A control "applied without error" only proves the object was accepted by the API server; a control that "closes the hole" is one you've actually tried to defeat and confirmed you can't. The exam's grading script only ever inspects the resulting cluster state after your session ends, so only the second fact earns any credit — the first is invisible to the grader.
- Any two of: scoring above the pass mark on both this course's CKS mock exams inside the two-hour limit; completing the readiness checklist above; and, uniquely to this exam, confirming your CKA is still active today and will still be active on the date you actually sit the CKS.