Get 20 Free Credits on Sign Up! Claim Now
Prepare for the CKAD exam with a practical six-week Kubernetes plan covering all current domains, command-line drills, troubleshooting labs, exam strategy, and focused FAQs.
The Certified Kubernetes Application Developer exam rewards fluency, not passive familiarity. You need to turn short requirements into working Kubernetes resources, inspect failures quickly, and use the command line without losing time. This CKAD exam preparation guide 2026 provides a six-week plan built around deliberate practice, current exam objectives, and realistic time pressure.
As of August 2026, the official Linux Foundation page lists Kubernetes v1.35 for the exam environment. The CKAD remains an online, proctored, performance-based exam with two hours to solve command-line tasks. Because the environment is updated after Kubernetes releases, confirm the version and policies on the official CKAD certification page before your scheduled date.
The Cloud Native Computing Foundation and Linux Foundation position CKAD as evidence that a candidate can design, build, configure, expose, observe, and troubleshoot cloud-native applications on Kubernetes. It assumes working knowledge of container images and microservice architecture, but it has no formal prerequisite.
The current official pages list:
The five published curriculum domains are:
| Domain | Weight |
|---|---|
| Application Design and Build | 20% |
| Application Deployment | 20% |
| Application Observability and Maintenance | 15% |
| Application Environment, Configuration and Security | 25% |
| Services and Networking | 20% |
CKAD centers on applications running inside Kubernetes: workloads, configuration, deployment strategies, probes, services, security contexts, and troubleshooting. CKA focuses more broadly on cluster administration and operations.
Choose CKAD if you build or deploy applications and want to demonstrate developer-side Kubernetes fluency. Choose CKA if your role emphasizes cluster lifecycle, control-plane operations, storage, networking, and administrator troubleshooting. If you are comparing paths, review the CKA eight-week Kubernetes study plan.
You do not need CKA before CKAD. You do need enough cluster vocabulary to understand namespaces, scheduling, service discovery, RBAC, admission, and how application resources interact with the platform.
Use a disposable cluster you can reset without fear. A local environment such as kind or minikube is sufficient for most drills, provided its Kubernetes version is reasonably close to the current exam environment. A cloud-managed cluster can help you encounter realistic defaults, but it is not required for core preparation.
Create a dedicated namespace for each session:
kubectl create namespace ckad-lab
kubectl config set-context --current --namespace=ckad-lab
kubectl get all
At the start, measure a baseline. Give yourself 30 minutes to create a Deployment, expose it with a Service, add a ConfigMap, configure readiness and liveness probes, and perform a rolling image update. Record where you used documentation, which commands you mistyped, and how long troubleshooting took.
This 20% domain covers container images, workload selection, multi-container Pod patterns, and volumes. Your goal is to translate a scenario into the smallest suitable resource.
Practice choosing among Deployment, DaemonSet, Job, and CronJob. Explain the decision before writing YAML. A web API with interchangeable replicas usually needs a Deployment. A task that must finish needs a Job. A scheduled cleanup fits a CronJob. A per-node agent suggests a DaemonSet.
Drill imperative generation as a starting point:
kubectl create deployment api --image=nginx:1.27 --replicas=3 --dry-run=client -o yaml > deployment.yaml
kubectl create job migrate --image=busybox:1.36 --dry-run=client -o yaml -- sh -c 'echo migrating' > job.yaml
Then edit the output instead of writing every field from memory. Practice init containers for setup work and sidecars for supporting behavior. Know when containers should share an emptyDir volume and how restart behavior differs between a Pod and a controller.
Application Deployment is another 20%. Focus on Deployments, rolling updates, rollbacks, Helm, Kustomize, and common release patterns such as canary and blue/green.
You should be comfortable with:
kubectl set image deployment/api api=ghcr.io/example/api:v2
kubectl rollout status deployment/api
kubectl rollout history deployment/api
kubectl rollout undo deployment/api
kubectl scale deployment/api --replicas=5
Do not merely memorize commands. Create a broken rollout by using an invalid image tag, diagnose the pending state, and recover. Use kubectl describe pod, Events, and rollout status together.
For Helm, practice installing an existing chart, inspecting releases, changing values, upgrading, and rolling back. For Kustomize, build a base plus an overlay that changes the namespace, image tag, labels, or replicas. Understand what the rendered resources will become before applying them.
At 25%, this is the largest domain. Cover ConfigMaps, Secrets, ServiceAccounts, resource requests and limits, quotas, security contexts, capabilities, authentication concepts, authorization, admission, and extensibility through custom resources and Operators.
Create configuration in more than one way:
kubectl create configmap app-config --from-literal=LOG_LEVEL=info --from-literal=FEATURE_X=true
kubectl create secret generic db-credentials --from-literal=username=app --from-literal=password='practice-only'
Mount data as environment variables and as files.
Practice a restricted container:
securityContext:
runAsNonRoot: true
allowPrivilegeEscalation: false
capabilities:
drop: ["ALL"]
Add CPU and memory requests and limits, then inspect scheduling or runtime behavior when values are unrealistic. Create a ServiceAccount and understand how it is associated with a Pod. You do not need to become a cluster security administrator, but you must recognize how application identity and workload permissions fit together.
Finish with a mixed lab: deploy an application that consumes a ConfigMap and Secret, uses a ServiceAccount, declares resources, mounts a volume, and runs with a constrained security context.
This 15% domain is your recovery toolkit. Practice probes, logs, debugging, built-in monitoring commands, and awareness of deprecated APIs.
Write startup, readiness, and liveness probes and explain their different jobs. Readiness decides whether a Pod should receive traffic. Liveness decides whether a container should be restarted. Startup probes protect slow-starting workloads from premature liveness failures.
Use a disciplined troubleshooting sequence:
kubectl get pods -o wide
kubectl describe pod api-7f9d
kubectl logs api-7f9d -c api
kubectl logs api-7f9d -c api --previous
kubectl get events --sort-by=.metadata.creationTimestamp
kubectl top pod
Create failures intentionally: a wrong container command, missing ConfigMap key, failing readiness endpoint, insufficient permissions, and a Service selector that matches no Pods. For each failure, state the symptom, gather evidence, change one thing, and verify recovery.
This 20% domain covers Services, Ingress, and NetworkPolicy. You should be able to expose an application and diagnose every connection in the path.
Build a ClusterIP Service imperatively, then inspect its selector and endpoints:
kubectl expose deployment api --name=api-service --port=80 --target-port=8080
kubectl get service api-service
kubectl get endpoints api-service
kubectl describe service api-service
If the endpoint list is empty, compare the Service selector with Pod labels. If endpoints exist but requests fail, inspect target ports, container listening ports, readiness, and NetworkPolicies.
Practice Ingress rules with the controller available in your lab. Remember that an Ingress resource alone does not provide traffic handling without an Ingress controller.
For NetworkPolicy, start with default deny, then allow only the required namespace, Pod labels, protocol, and port. Validate from an allowed client and a denied client. The exam rewards verification, not assumptions.
Stop studying domains in isolation. Complete mixed sets in 15-, 30-, and 60-minute blocks. Switch contexts and namespaces carefully. Use command-line completion, aliases, --dry-run=client -o yaml, and documentation search only when those techniques make you faster without increasing errors.
The Linux Foundation currently includes two simulator attempts, each with a limited access window after activation. Confirm the exact simulator terms in your portal, then use the first attempt as a diagnostic and the second as a dress rehearsal. Do not activate both casually.
After every timed set, classify lost time:
Convert each category into a short drill for the next day. Timed practice only improves performance when review changes your behavior.
Read the official CKA and CKAD instructions and candidate handbook shortly before the exam because operational rules can change. Current CNCF terms permit Kubernetes documentation in one additional browser tab, subject to their domain restrictions. Use only the resources allowed by the rules shown for your exam.
At the beginning, scan the tasks and their weights. Secure quick points first, flag slow tasks, and return later. For each task:
Save time for a final sweep. A resource that exists but does not meet the requested state is not finished.
Use documentation to confirm syntax, not to replace understanding. Before looking anything up, state the resource kind, important fields, and verification command. After the lab, rebuild it from a blank environment.
Explain troubleshooting decisions aloud. Clear narration exposes fuzzy reasoning and prepares you to discuss Kubernetes work in hiring interviews after the certification. The seven-day AI mock interview plan can help structure feedback on clarity and recovery.
Also maintain broader engineering practice. CKAD demonstrates Kubernetes application skills, but software interviews may still test algorithms and data structures. Use the LRU cache Python interview guide as a focused companion exercise.
Six weeks can be enough for someone already comfortable with containers, YAML, and basic kubectl. A beginner may need longer. Use the baseline lab to decide: if basic Deployments, Services, and troubleshooting are unfamiliar, add foundational weeks before starting timed exam drills.
No. The official CKAD is performance-based. You solve practical tasks from a command-line environment during a proctored online exam.
The official Linux Foundation page currently lists Kubernetes v1.35. The environment is aligned with recent Kubernetes minor releases on a delay, so verify the listed version near your exam date.
Current official rules allow specified Kubernetes documentation through an additional browser tab, with restrictions. Review the resources-allowed policy and instructions for your scheduled exam rather than relying on an old blog post.
No formal prerequisite is listed. CKA and CKAD validate different skill profiles. Some candidates take CKAD first because their daily work is application-focused.
Check the current exam portal and candidate materials for the authoritative passing standard. Policies can change, and your preparation should aim for reliable completion rather than a narrow score target.
Before scheduling, confirm that you can create and modify workloads quickly, debug a failed rollout, configure probes, consume ConfigMaps and Secrets, apply resource and security settings, use Helm and Kustomize, expose workloads, troubleshoot selectors and ports, write NetworkPolicies, and verify every final state.
The strongest CKAD preparation is repetitive but not mechanical: build, break, inspect, repair, and explain. Six focused weeks of that cycle will produce more exam-ready skill than months of watching demonstrations without touching a cluster.
Prepare for the CKA exam with an eight-week Kubernetes study plan covering every weighted domain, hands-on labs, troubleshooting drills, exam strategy, and FAQs.
Compare five career-aligned tech certifications for 2026, what each validates, who should pursue it, and how to turn the credential into real salary leverage.
Learn how to structure your behavioral interview answers using Situation, Task, Action, Result framework.
Read our blog for the latest insights and tips
Try our AI-powered tools for job hunt
Share your feedback to help us improve
Check back often for new articles and updates
CoPrep AI Interview Assistant completely changed how I approach technical interviews. Before CoPrep AI, I'd blank out under pressure and lose my train of thought mid-answer. Now I have a structured way to tackle any question. The real-time guidance helped me stay calm, articulate my reasoning clearly, and recover when I stumbled. I landed my offer after just three weeks of consistent practice. I genuinely can't recommend it enough.