CKAD Study Plan
The CKAD is the developer's exam in this course's ladder — where the CKA asks you to run a cluster, CKAD asks you to build, ship, configure, and watch over what runs on one, and it grades that the same way CKA does: live tasks against live clusters, scored purely on end state. This plan assumes you've already done the work in Common Preparation — the context/namespace reflexes, the --dry-run=client -o yaml habit, the describe/logs/events triage order — so unlike the nine-week CKA plan, there's no dedicated foundations week here. Three weeks, sized to the exam's own 20/20/15/25/20 domain weights: a week to build and ship workloads, a week on the single biggest domain — Environment, Configuration & Security — plus keeping an eye on what you deployed, and a final week wiring up networking before two full timed mock exams. Compress or stretch the calendar to fit your own pace; keep the proportions between domains fixed regardless.
Picture running a small food truck for three weeks straight. Week one, you're just cooking and getting dishes out the window fast — that's building the app and shipping it. Week two is the health inspector's visit, except it never really ends: locking the walk-in fridge, labeling every ingredient, making sure only the right staff can touch the register, and tasting every dish before it goes out so a bad batch doesn't reach a customer. That's the biggest week, because the inspector cares about more things than any other single visit. Week three, you make sure the truck's window sign and menu board actually point hungry customers to the right order — and then, before opening for real, you run two full practice services against a timer to make sure you're fast enough when it counts.
The domain-weighted study budget
☺ Like you're 10: One domain is worth as much as the two smallest combined, so it should get more of your calendar than either of them — not an equal slice just because there are five domains.
These are the five domains from the CNCF's Certified Kubernetes Application Developer (CKAD) Exam Curriculum, version 1.35 — the same curriculum version this course's CKA blueprint pages follow, since both track the same Kubernetes release cadence. Five domains, no sub-weights, summing to exactly 100% — 20 + 20 + 15 + 25 + 20. Application Environment, Configuration & Security is the outlier: at 25% it's worth as much as Application Observability & Maintenance and half of Application Deployment put together, and it's the one candidates most often under-budget because "configuration" sounds smaller than it scores.
Underneath those five percentages sit 25 published competencies. Turning weight and competency count into an hours budget gives a plan you can actually schedule against — and because this plan assumes kubectl fluency already exists, all of this is domain time, with none spent re-learning the CLI itself:
| Domain | Weight | Competencies | Study-budget hours |
|---|---|---|---|
| 🐢 Application Environment, Configuration & Security | 25% | 7 | ~15 hrs |
| 🦫 Application Design and Build | 20% | 6 | ~12 hrs |
| 🤖 Application Deployment | 20% | 4 | ~12 hrs |
| 🐦 Services and Networking | 20% | 3 | ~12 hrs |
| 🐘 Application Observability and Maintenance | 15% | 5 | ~9 hrs |
| Domain core, total | 100% | 25 | ~60 hrs |
Add roughly another 15 hours for two full timed mock exams and a final speed pass, for a full plan of about 75 hours. Spread across three weeks that's close to 25 hours a week — a genuinely intensive pace, well above the CKA plan's 14–15 hours a week, and it's intensive on purpose: this plan has no foundations week, because the kubectl fluency baseline is a stated prerequisite, not something to build here. If 25 hours a week isn't realistic against your calendar, stretch this to five or six weeks and keep the same 25/20/20/20/15 split between domains — the ratio is what matters, not the total.
A three-week roadmap
☺ Like you're 10: Here's the actual calendar — which domains share which week, and exactly which pages on this course to use.
Unlike the CKA plan's one-domain-per-week shape, CKAD's five domains pair naturally into three weeks: build pairs with deploying what you built, environment/configuration pairs with watching what you deployed, and networking closes the domain list on its own before two full weeks' worth of hours goes into mock exams instead of new material.
| Week | Focus | Hours | What you actually do |
|---|---|---|---|
| 1 | 🦫 Design & Build + 🤖 Deployment — 40% | ~24 | Multi-container pod patterns (init, sidecar, ambassador), Jobs and CronJobs, ConfigMaps/Secrets as env vars and volumes, a Pod consuming an existing PVC; then Deployments and rolling updates, kubectl rollout history/undo, a blue-green or canary swap done with labels and a Service selector, and packaging the same workload two ways with Helm and Kustomize. Read The Object Model and the Workloads & Scheduling blueprint page (built for CKA, but the Deployment/Job mechanics are identical); build it hands-on in Capstone Part 2. |
| 2 | 🐢 Environment, Config & Security + 🐘 Observability — 40% | ~24 | Resource requests/limits, ResourceQuotas and LimitRanges, SecurityContexts (runAsNonRoot, dropped capabilities, seccomp), a ServiceAccount bound to a Role and mounted into a Pod, discovering a CRD with kubectl explain; then liveness/readiness/startup probes, reading kubectl logs across a multi-container Pod and with --previous, kubectl debug and ephemeral containers, and checking a manifest against the current API for deprecated fields before it ships. Work scheduling & resource management, security: defense in depth, RBAC & admission control, and operators & CRDs; drill debugging in Debug a Stuck Pod and lock down access in Capstone Part 5. |
| 3 | 🐦 Services & Networking — 20% + mocks & readiness | ~27 | ClusterIP, NodePort and ExternalName Services, Ingress rules routing to more than one backend, a NetworkPolicy that denies by default and then allows exactly one path, and confirming CoreDNS resolution from inside a Pod. Work networking & the CNI and the Services & Networking blueprint page, build it in Capstone Part 3 and break it on purpose in Diagnose a Networking Failure. Then close with Practice Tasks, two full timed Mock Exam · Set 1 and Set 2 runs, a speed pass through the kubectl fluency baseline, and flashcards for anything still shaky. |
Why CKAD rewards fast, correct YAML — not memorized theory
☺ Like you're 10: Nobody grades whether you understood a sidecar container in your head — they grade whether the YAML you actually applied has one running.
CKAD is performance-based like CKA and CKS, which means the same three habits from the kubectl fluency baseline apply here without modification — but CKAD leans on the --dry-run reflex harder than any other exam in this ladder, because so much of the task list is "produce a manifest with these three specific properties" rather than "diagnose what's already broken."
# scaffold, don't hand-type — then edit only what the task actually asked for alias k=kubectl export do="--dry-run=client -o yaml" k create deploy web --image=nginx:1.27 $do > deploy.yaml # open deploy.yaml, add: a resource block, a readiness probe, an extra container as sidecar # a probe you haven't watched pass is a probe you don't know works k apply -f deploy.yaml && k rollout status deploy/web k get pods -o wide k describe pod <pod> | grep -A4 -E "Readiness|Liveness"
The pattern generalizes past Deployments: k run probe --image=busybox $do -- sleep 3600 gets you a Pod skeleton to add a sidecar to; k create sa app-sa $do, k create role <name> --verb=get,list --resource=pods $do, and k create rolebinding ... $do get you the three RBAC objects for the biggest domain without retyping boilerplate you'd get right anyway. Every minute saved scaffolding is a minute available for the part of the task the generator can't do for you — the actual sidecar, probe, or NetworkPolicy rule the task is really testing.
CKAD's task list skews toward "build this correctly" over "find what's wrong" — the opposite skew from CKA's Troubleshooting-heavy 30%. That means the exam rewards typing speed and manifest recall more than it rewards diagnostic instinct. Don't import a CKA-style study rhythm wholesale; if you're studying both, keep separate drill time for "produce it fast" versus "find what broke."
Resources: official, this course, and timed practice
☺ Like you're 10: Three different kinds of resource do three different jobs — don't use a reading page for the thing only a live cluster and a timer can actually teach you.
Studying "everything you can find" wastes hours; studying the right kind of resource for each stage of the plan doesn't.
| Resource | Use it for |
|---|---|
| The published curriculum — github.com/cncf/curriculum | The exact competency wording, and confirming the version matches what you're studying. |
The Kubernetes documentation, kubernetes.io | The same allowlisted docs you're permitted to open during the exam — practice finding things in them now, not for the first time under the clock. |
| This course's CKAD exam page — CKAD — the exam | The full domain-by-domain blueprint this study plan is scheduled against. |
| Deep dives & tool guides — security, RBAC, networking, Helm, Kustomize | Going a layer deeper than the exam requires — useful once a domain's surface feels too thin. |
| The capstone & drills — lab track, Debug a Stuck Pod, Diagnose a Networking Failure, Harden an RBAC Configuration | Building and breaking real workloads with your own hands — the only kind of practice that actually resembles the exam. |
| Timed practice on this course — 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 exam registration) | The one resource that matches the exact exam UI and environment — confirm what your specific purchase includes. |
| A second opinion on the same exam — Platform Engineering's CKAD page | The same five domains explained from a platform-engineer's angle — worth reading once this plan feels familiar. |
Keep a running weak-spot log as you go rather than trusting memory — the Field Notes page on this course is built for exactly that, and rereading it before your mock exams 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 3 — book it once you can actually do these things, cold, under a clock.
Booking on a date rather than on readiness is the single most common way people waste the exam fee. Before you pay, you should be able to answer "yes" to all of these without hesitating:
1. Can you write a Pod spec with an init container and a sidecar, in YAML, from memory, in under five minutes? 2. Can you scaffold a Deployment with --dry-run=client -o yaml and hand-edit in a resource block, a readiness probe, and a rolling-update strategy without looking anything up? 3. Given a Pod stuck CrashLoopBackOff, can you tell from kubectl logs --previous and describe Events whether it's a failed probe or an application crash, in under a minute? 4. Can you create a ServiceAccount, bind it to a Role, and mount it into a Pod as one fast sequence? 5. Can you write a NetworkPolicy that denies all ingress by default and then allows exactly one Pod-to-Pod path, without a first attempt that silently breaks DNS? 6. Have you scored above the published pass mark on both this course's CKAD mock exams, inside the two-hour limit? 7. Have you run the kubectl fluency baseline's speed tier and the exam-prep checklist without new surprises?
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.
Exam logistics — verify these yourself before you book
☺ Like you're 10: The shape of the test changes now and then — 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 tasks on live clusters in a browser terminal, graded on end state |
| Duration | 2 hours |
| Passing score | 66% |
| Validity | 2 years from the date you pass |
| Retake | Registration has historically included one free retake |
| Price | Around USD $445 list; bundles and regional pricing are common |
| Prerequisites | None — unlike CKS, CKAD doesn't require an active CKA first |
| Curriculum | 25 competencies across 5 domains; this plan follows v1.35 — confirm the version current when you sit |
| Permitted resources | A published allowlist of documentation sites, opened in-browser during the exam — read 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, and curriculum version all change over time. Confirm current details on the official Linux Foundation CKAD 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 Golden Astronaut course if CKAD is one stop on the way to the full Golden Kubestronaut set.
Benny: Sidecar's in, probe's green, rollout's done — that's Design, Build, and Deployment before lunch. Not bad for one morning.
Timmy: Before you celebrate — what's the SecurityContext on that container? What ServiceAccount is it running as?
Benny: ...the default one. It runs. Isn't that the point?
Gizmo: Exactly! It runs, ship it. Nobody's grading a SecurityContext nobody can even see. 🤑
Timmy: The exam disagrees, Gizmo — Environment, Configuration & Security is worth a quarter of the whole score, more than Design and Build alone. Runs isn't the bar. Runs correctly is.
Ellie: And I'm the one who'll notice if that probe starts flapping next week because nobody set a resource limit. Watching doesn't stop at "deployed."
Benny: Fine, fine — runAsNonRoot: true, drop the capabilities, and a real ServiceAccount. Redoing it now.
1. What are the five CKAD domains and their weights, from largest to smallest, and what do they sum to? 2. Why does this three-week plan pair Design & Build with Deployment in week 1, rather than giving each its own week? 3. Roughly how many total study hours does this plan budget, and why is the weekly pace higher than the CKA plan's? 4. Name two habits this page recommends for producing YAML quickly, and explain why speed matters more on CKAD than on CKA's Troubleshooting domain. 5. What's the difference in purpose between this course's CKAD blueprint page and its mock exams? 6. Give two concrete checks you should be able to pass before booking the exam.
Check your answers
- Application Environment, Configuration & Security 25%; Application Design and Build 20%; Application Deployment 20%; Services and Networking 20%; Application Observability and Maintenance 15% — summing to exactly 100%.
- Because they're naturally sequential (build something, then ship it) and their combined 40% fills a week's worth of hours cleanly — splitting them into separate weeks would leave each week under-loaded relative to the bigger Environment/Config/Security domain that follows.
- Roughly 75 hours total: about 60 hours split across the five domains by weight, plus about 15 hours for two mock exams and a final speed pass — spread over three weeks instead of CKA's nine, which is why the weekly pace (~25 hrs/week) is higher; this plan skips a foundations week because kubectl fluency is a stated prerequisite.
- Any two of: scaffold with
--dry-run=client -o yamlinstead of hand-typing manifests; never trust a probe or rollout until you've watched it pass withrollout status/describe; keep imperative one-liners (k create sa,k create role) ready for RBAC objects. Speed matters more here because CKAD's task list skews toward producing correct manifests rather than diagnosing what's already broken, the opposite skew from CKA's Troubleshooting-heavy exam. - The CKAD blueprint page teaches each domain's concepts and commands, matched to the curriculum's own wording; the mock exams are timed, graded-on-end-state rehearsals of the actual exam format — one builds the knowledge, the other proves you can execute it under the clock.
- Any two from the readiness checklist — e.g. writing a Pod spec with an init container and a sidecar from memory in under five minutes; scaffolding a Deployment with
--dry-runand hand-editing in a probe and resource block without looking anything up; scoring above the pass mark on both mock exams inside the two-hour limit.