How to Pass the CKAD Exam in 2026 (First Attempt Strategy)
The complete first-attempt playbook for the Certified Kubernetes Application Developer exam in 2026 — speed setup, the 5 weighted domains, must-practice tasks, and the exam-day decisions that protect your score.

Table of Contents
CKAD has a reputation for being the exam that breaks well-prepared candidates. Not because the content is exotic, but because 16-20 real, hands-on tasks must be completed in exactly 2 hours inside a remote Linux terminal. There is no multiple choice. There is no partial-credit safety net. Speed is the exam. This guide is built around that single fact.
Book first, study second. Set a date 5-6 weeks out before you read another line. The $445 fee creates the urgency that transforms "I will practice kubectl someday" into daily reps. The free retake is your safety net, not your plan A.
What Makes CKAD Hard (It Is Not the Content)
The CKAD sits in a strange position among CNCF exams. The individual concepts — deployments, ConfigMaps, probes, NetworkPolicies — are not particularly deep. A developer who has spent a few months on a Kubernetes-based team has probably touched most of them. The difficulty is entirely mechanical: you must recall, type, and verify faster than the clock.
Consider the math. Two hours. Roughly 17 tasks. That is about 7 minutes per task on average — before accounting for the context-switch overhead of reading each question, changing cluster context, and verifying the result. A task that requires a multi-container Pod spec with a sidecar, an emptyDir volume shared between them, and a liveness probe on the main container is not hard to understand. Writing it from scratch in correct YAML, in under 5 minutes, without typos that break the parser, is a different skill entirely.
This is why CKAD preparation must be terminal-first. Reading blog posts (including this one) is not prep. Watching video courses is not prep. Typing kubectl commands in a real cluster, every day, until the muscle memory is automatic, is prep. Everything else is orientation.
For candidates wondering how CKAD compares to CKA, our CKA vs CKAD breakdown covers the differences in scope, difficulty profile, and career fit. If you are earlier in your Kubernetes journey, the KCNA vs CKAD comparison may be a useful starting point.
CKAD Exam Format & Facts
Know these before you start studying — they shape every preparation decision:
- Duration: 2 hours, performance-based. No extensions.
- Tasks: Approximately 16-20 tasks, each with a listed percentage weight (typically 4-8% each).
- Pass mark: 66%. You do not need to be perfect. You need to be fast and accurate on the bulk of the tasks.
- Cost: $445 USD via the Linux Foundation, which includes one free retake within 12 months and two killer.sh simulator attempts.
- Kubernetes version: v1.30+ in 2026. The exam environment runs a specific minor version listed in the candidate handbook.
- Allowed resources: One browser tab open to
kubernetes.io/docs,kubernetes.io/blog, orgithub.com/kubernetes. Nothing else. No notes, no second monitor. - Environment: PSI Secure Browser. Remote desktop connected to real Kubernetes clusters. You work in a Linux terminal; the cluster is not simulated.
- Focus: Developer tasks — building, configuring, and deploying applications. Not cluster administration. You will not kubeadm-init a cluster or restore etcd. That is CKA territory.
The developer focus is what makes CKAD distinct. If your day job is writing application manifests, managing deployments, configuring probes, and wiring up services, you are studying for the right exam. See our full CKAD study guide for a structured week-by-week plan, and our Kubernetes certifications guide for how CKAD fits into the broader CNCF track.
The 5 CKAD Domains, Weighted
The 2026 CKAD curriculum divides into five domains with published percentage weights. These weights are your study budget. Spend your hours proportionally.
1. Application Environment, Configuration and Security — 25%
The heaviest domain. Covers ConfigMaps and Secrets (creation, injection as env vars, injection as mounted volumes), SecurityContexts (runAsUser, runAsNonRoot, readOnlyRootFilesystem, capabilities), ServiceAccounts and RBAC at the application level (not cluster admin RBAC), resource requests and limits, LimitRanges and ResourceQuotas, and admission controllers relevant to app deployment. Expect multiple tasks here; invest proportionally.
2. Application Design and Build — 20%
Multi-container Pod patterns — sidecar, init container, adapter, ambassador. Jobs and CronJobs (restart policies, completions, parallelism, activeDeadlineSeconds). Building images with Dockerfiles (understanding the build context, multi-stage builds). Volume types — emptyDir, hostPath, PersistentVolumeClaims. Choosing the right workload type (Deployment vs StatefulSet vs DaemonSet vs Job) for a given scenario.
3. Application Deployment — 20%
Deployments and rolling update strategies (RollingUpdate vs Recreate, maxSurge, maxUnavailable). Rollbacks with kubectl rollout undo. Helm basics: install, upgrade, rollback a chart. Kustomize overlays: applying environment-specific patches with kubectl apply -k. Blue-green and canary deployment patterns at the manifest level (label selectors, multiple Deployments behind one Service).
4. Services and Networking — 20%
ClusterIP, NodePort, LoadBalancer, ExternalName service types. Ingress resources and Ingress controllers (nginx is the exam default). NetworkPolicies — default-deny patterns, specific allow rules for namespace and pod selectors. CoreDNS and service discovery: resolving <svc>.<namespace>.svc.cluster.local from a Pod. Common networking troubleshooting: why a Pod cannot reach a Service, why DNS resolution fails.
5. Application Observability and Maintenance — 15%
The lightest domain but do not ignore it. Liveness, readiness, and startup probes (httpGet, exec, tcpSocket; initialDelaySeconds, periodSeconds, failureThreshold). kubectl logs, kubectl exec, kubectl top, and kubectl describe for diagnosing running applications. API deprecations: finding the right apiVersion for a given resource kind in a given Kubernetes version. Container upgrade strategies.
Domain math: Application Environment/Config/Security (25%) + Application Design and Build (20%) = 45% of your score from the first two domains alone. Master ConfigMaps, Secrets, SecurityContexts, multi-container Pods, and Jobs before you spend a single hour on the lighter domains.
The Winning Prep Strategy
Four to six weeks of focused terminal work, structured around the domain weights. Here is the sequence that works:
Phase 1 — Imperative-First (Weeks 1-2)
Before you write a single YAML file from scratch, master the imperative commands that generate YAML for you. The pattern kubectl create <resource> --dry-run=client -o yaml > resource.yaml is the single most important technique on the exam. It gives you a syntactically valid scaffold in 2 seconds and eliminates the indent errors that plague hand-typed manifests.
Drill these until they are automatic: k run pod1 --image=nginx $do, k create deploy web --image=nginx --replicas=3 $do, k create cm app-config --from-literal=env=prod $do, k create secret generic db-creds --from-literal=password=s3cr3t $do, k create job batch1 --image=busybox $do -- /bin/sh -c "echo hello", k create cronjob cron1 --image=busybox --schedule="*/5 * * * *" $do -- /bin/sh -c "date". The $do alias is defined once at the start of the exam and used everywhere.
Phase 2 — Domain-Focused Labs (Weeks 3-4)
Work through each domain in weight order. For each concept, follow this loop: read the kubernetes.io/docs page once, close it, and reproduce the task entirely from memory in your lab. Do not re-read during practice — re-reading is not exam prep. If you get stuck, try for 5 minutes, then look it up, then redo the task from scratch. Repetition under mild pressure builds the right kind of memory.
The CKAD complete guide and CKAD practice questions are useful resources to benchmark which tasks you can complete fluently and which still need reps.
Phase 3 — killer.sh + Weak-Area Patch (Weeks 5-6)
Run killer.sh attempt one under full exam conditions: 2 hours, single monitor, no notes open except kubernetes.io. Score honestly. Killer.sh runs 15-20% harder than the real exam, so a 55-60% score suggests you are within pass range. Spend the remaining study time drilling the 3-4 task types you got wrong or skipped. Run killer.sh attempt two 48 hours before your real exam date to warm up the muscle memory. Do not cram new concepts in the final 48 hours.
Supplement with free CKAD practice questions on ExamCert between lab sessions to keep the conceptual layer sharp alongside the hands-on reps.
kubectl Speed Setup
Set these in the first 60 seconds of the exam. They are not optional niceties — they are the difference between finishing and timing out.
alias k=kubectl— saves 6 characters on every command. Over 17 tasks, that is hundreds of keystrokes reclaimed.source <(kubectl completion bash)andcomplete -F __start_kubectl k— tab completion on thekalias. Essential for resource names, flag names, and namespace names under time pressure.export do='--dry-run=client -o yaml'— the YAML scaffolding shortcut. Use ask run web --image=nginx $do > pod.yamlthen edit the file.export now='--grace-period=0 --force'— for fast pod deletion when you need to redo.k delete pod web $nowremoves it instantly instead of waiting 30 seconds.- vim setup: run
echo "set nu et ts=2 sw=2 ai" > ~/.vimrc— line numbers, expand tabs to spaces, 2-space indent, auto-indent. YAML indentation errors are silent killers; these settings surface them. kubectl explain <resource>.spec.field— in-cluster field documentation. Faster than switching to the docs tab for a single field name.k explain pod.spec.containers.livenessProbeprints the full schema inline.
Must-Practice Tasks
These are the task types that appear on almost every CKAD sitting. Practice each until you can complete it from blank terminal in under 5 minutes.
Multi-Container Pods and Sidecars
Generate the base Pod manifest with $do, then add the second container in spec.containers[]. The sidecar pattern typically shares a volume: define an emptyDir in spec.volumes[] and mount it in both containers. Init containers go in spec.initContainers[] — they must exit 0 before the main container starts. Common exam scenario: an init container that writes a config file to a shared emptyDir volume that the main container reads on startup.
Liveness, Readiness, and Startup Probes
Three probe types, three handler types (httpGet, exec, tcpSocket). Know the key fields: initialDelaySeconds, periodSeconds, failureThreshold, successThreshold (readiness only). A common trap: setting failureThreshold too low causes a pod to restart before the app finishes booting — use startupProbe for slow-starting apps. Use kubectl explain pod.spec.containers.livenessProbe for the exact field names if you blank.
ConfigMaps and Secrets
Four injection patterns, all examined: env var from a single key (valueFrom.configMapKeyRef), all keys as env vars (envFrom.configMapRef), mounted as a volume (creates files per key), and mounted as a specific subPath file. Secrets use identical syntax with secretKeyRef / secretRef. Create both imperatively: k create cm <name> --from-literal=key=value $do and k create secret generic <name> --from-literal=key=value $do.
Jobs and CronJobs
Jobs run one-off tasks to completion. Key fields: completions (how many Pods must succeed), parallelism (how many run at once), backoffLimit (retries on failure), activeDeadlineSeconds (hard time limit). CronJobs wrap a Job template with a cron schedule string. Common exam catch: the Pod template inside a Job must have restartPolicy: Never or OnFailure — the default Always is invalid for Jobs and will be rejected.
Deployments and Rollouts
Create with k create deploy <name> --image=<img> --replicas=N $do. Update the image: k set image deploy/<name> <container>=<new-img>. Check rollout status: k rollout status deploy/<name>. Roll back: k rollout undo deploy/<name>. View history: k rollout history deploy/<name>. Update strategy fields live in spec.strategy.rollingUpdate.maxSurge and maxUnavailable — know how to set these in the manifest.
NetworkPolicies
The most YAML-heavy task on the exam. Always start from the kubernetes.io/docs NetworkPolicy example (the one allowed docs tab earns its keep here). The pattern: default-deny all ingress with an empty podSelector: {} and no ingress: rules, then a second policy with explicit allow rules using podSelector and/or namespaceSelector. Verify with a disposable Pod: k run tmp --rm -it --image=busybox --restart=Never -- wget -qO- http://<target-svc>.
Services and Ingress
Expose a Deployment: k expose deploy/<name> --port=80 --target-port=8080 --name=<svc>. For NodePort: add --type=NodePort. Ingress resources: generate the skeleton with k create ingress <name> --rule="host/path=svc:port" $do, then edit the YAML for pathType (Prefix vs Exact). Verify connectivity from inside the cluster with a temporary busybox Pod.
SecurityContexts
Set at Pod level (spec.securityContext) or container level (spec.containers[].securityContext). Container-level overrides Pod-level. Common exam fields: runAsUser: 1000, runAsNonRoot: true, readOnlyRootFilesystem: true, allowPrivilegeEscalation: false, capabilities.add: ["NET_ADMIN"]. A read-only root filesystem with a writable emptyDir for the app’s temp directory is a common combined task.
Time-Management Tactics
Time management is the exam skill that cannot be drilled directly — it requires deliberate practice under realistic time pressure (killer.sh, timed self-practice). These are the tactics that protect your score:
- Set the 7-minute personal limit per task. Not 10, not 15. Seven. If you have not solved a task in 7 minutes, flag it, note where you are in the YAML, move on. You can return. You cannot recover a task you did not start because you ran out of time.
- Read all tasks in the first 5 minutes. Note the weight percentage on each. Sort mentally: start with medium-weight tasks you know cold (confidence + score), defer high-weight tasks that look unfamiliar (return with fresh eyes), skip low-weight tasks that look tricky (not worth the time).
- Change cluster context before every task. Each task specifies a context name. Run
kubectl config use-context <name>as the literal first action on every task. Working in the wrong cluster is silent — you complete the task, it verifies clean, and you score zero. - Verify after every task.
k get <resource> -n <ns>and check the relevant status. Two seconds of verification prevents a failed task from looking like a passed one. - Use the scratchpad. The exam environment provides a notepad. Write down task numbers you flagged, the namespace/context for each, and what remains to be done. Do not hold this in working memory.
- Save the last 10 minutes for flagged tasks. Do a single pass through your notes, return to flagged items, and spend whatever remains on partial credit — a half-done NetworkPolicy or a partially correct Deployment still scores more than an empty namespace.
Exam-Day Playbook
The day-of decisions that protect the score you spent weeks building:
- Room setup 30 minutes early. Clear desk (only monitor, keyboard, mouse, water in a transparent container with no label). ID ready. Webcam and microphone tested. A proctor failing you for a cluttered desk is a wasted exam fee.
- Open the docs tab immediately. Navigate to kubernetes.io/docs and bookmark the four most-used pages: Concepts → Workloads → Pods (multi-container), Tasks → Configure Pods → Assign Pods to Nodes (affinity), Concepts → Services/Networking → NetworkPolicies, Reference → kubectl CLI → Cheat Sheet. You will navigate to these under time pressure; bookmarks remove the search step.
- Set aliases and vim in task 1.
alias k=kubectl,source <(kubectl completion bash),complete -F __start_kubectl k,export do='--dry-run=client -o yaml',export now='--grace-period=0 --force',echo "set nu et ts=2 sw=2 ai" > ~/.vimrc. These persist for the session. - Do not debug for more than 7 minutes. See time-management tactics above. Repeat this to yourself when you feel the pull to "just fix this one last thing."
- Trust your killer.sh reps. By exam day you have seen the task types. The question wording will be different. The underlying task will not be. Your hands know what to type.
Practice CKAD Scenarios — Free AI Questions
Free CKAD practice exams with scenario-style questions across all 5 domains to build exam-day speed.
Try Free CKAD Practice ExamFrequently Asked Questions
How hard is the CKAD exam?
CKAD is the most time-pressured CNCF exam. The tasks are not conceptually harder than CKA, but fitting 16-20 tasks into 2 hours with no copy-paste shortcuts demands real kubectl fluency. Most candidates who fail do so on time, not knowledge.
How much does CKAD cost in 2026?
$445 USD via the Linux Foundation, which includes one free retake within 12 months and two killer.sh simulator attempts. Bundle deals with CKA or CKS occasionally reduce the per-cert price.
Should I take CKAD before CKA?
If you are a developer who builds and deploys applications on Kubernetes, CKAD first is natural. If you manage clusters or work in SRE/platform roles, start with CKA. Neither is a prerequisite for the other. See our CKA vs CKAD comparison for a full breakdown.
How long should I study for CKAD?
Most candidates with some Kubernetes exposure pass with 4-6 weeks of focused lab practice at 10-15 hours per week. Complete beginners should allow 8 weeks. The key metric is not hours read but tasks completed in the terminal.
Is the CKAD exam open book?
Partially. You are allowed one browser tab open to kubernetes.io/docs, kubernetes.io/blog, and github.com/kubernetes. No personal notes, no second monitor, no other websites. Knowing how to navigate the docs quickly is itself a testable skill.
Plan Your Kubernetes Cert Journey
Free tools to estimate study time, compare certifications, and chart your CNCF roadmap.
