The CKAD tests whether you can take an application and run it properly on Kubernetes: configured from the outside, health-checked, secured, exposed and updated without downtime. Like the CKA, it is entirely hands-on: 15 to 20 tasks in a live terminal in two hours, graded by checking the cluster.
Where the CKA is about running clusters, the CKAD stays at the application level. You will not upgrade a control plane or fix a kubelet. You will write a lot of Pod specs, quickly.
Warm up first: the CKA practice lab covers the kubectl speed skills both exams share, such as namespaces, dry-run YAML, Deployments, ConfigMaps, Secrets, Services and RBAC, in a browser-based cluster.
Who the CKAD is for
Developers who deploy to Kubernetes, and DevOps engineers who write the manifests and Helm charts for application teams. You should be comfortable with containers (the Docker tutorial covers it) and with Kubernetes basics before starting.
The exam environment
The CKAD uses the same environment as the CKA, described in the Linux Foundation's instructions:
- Each task tells you which host to
sshinto. Work there, thenexit. kis already aliased to kubectl with Bash completion, andyqandcurlare installed.- Copy and paste in the terminal are Ctrl+Shift+C and Ctrl+Shift+V. The Insert key is disabled, so use
iin vim. - Allowed documentation: kubernetes.io/docs, the Kubernetes blog and helm.sh/docs.
Domain 1: Application Environment, Configuration and Security (25%)
The biggest domain. Most of it is getting configuration and identity into Pods correctly.
ConfigMaps and Secrets, consumed both ways:
k create configmap app-config --from-literal=APP_MODE=production
k create secret generic db-creds --from-literal=DB_PASSWORD=s3cr3t
spec:
containers:
- name: app
image: nginx:1.27
envFrom:
- configMapRef:
name: app-config
env:
- name: DB_PASSWORD
valueFrom:
secretKeyRef:
name: db-creds
key: DB_PASSWORD
volumeMounts:
- name: config
mountPath: /etc/app
volumes:
- name: config
configMap:
name: app-config
Requests, limits and quotas: set resources on containers, and know what a ResourceQuota and a LimitRange do to a namespace. A Pod that will not create in a quota-limited namespace usually lacks requests. The requests and limits tutorial covers both.
SecurityContext: run as a non-root user, drop capabilities, make the root filesystem read-only:
securityContext:
runAsUser: 1000
runAsNonRoot: true
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
capabilities:
drop: ["ALL"]
ServiceAccounts: create one and set serviceAccountName on the Pod. Know automountServiceAccountToken: false for Pods that do not need API access.
Domain 2: Application Design and Build (20%)
- Pick the right workload: a Deployment for stateless apps, a DaemonSet for one Pod per node, a Job for a one-off task, a CronJob for a schedule:
k create job backup --image=busybox:1.36 -- sh -c "echo done"
k create cronjob report --image=busybox:1.36 --schedule="*/5 * * * *" -- sh -c "date"
- Multi-container Pods: init containers that run first and must succeed, and sidecars that run alongside the main container and share its volumes. See the multi-container Pods tutorial.
- Volumes:
emptyDirfor scratch space shared between containers, PersistentVolumeClaims for data that must survive the Pod. - Container images: read and fix a Dockerfile, and build an image. The Dockerfile best practices page covers what tasks tend to ask.
Domain 3: Application Deployment (20%)
Rolling updates and rollbacks:
k create deployment web --image=nginx:1.27 --replicas=3
k set image deployment/web nginx=nginx:1.28
k rollout status deployment/web
k rollout history deployment/web
k rollout undo deployment/web
Blue/green and canary without extra tools: run two Deployments with different version labels behind one Service. For blue/green, switch the Service selector from version: blue to version: green. For a canary, give both Deployments the label the Service selects on, and set their replica counts to the split you want, such as 9 to 1.
Helm and Kustomize: install a chart with overridden values, upgrade it, roll it back, and apply a Kustomize overlay with k apply -k. The Helm tutorial covers the commands.
Domain 4: Services and Networking (20%)
- Services: expose a Deployment with
k expose deployment web --port=80 --target-port=8080, and debug one whose endpoints are empty. Almost always the selector does not match the Pod labels. See Service has no endpoints. - Ingress: write a rule that routes a host or path to a Service. See the Ingress tutorial.
- NetworkPolicy: read and write simple policies, for example only allowing traffic from Pods with a given label.
Domain 5: Application Observability and Maintenance (15%)
Probes are the most common task in this domain:
readinessProbe:
httpGet:
path: /healthz
port: 8080
periodSeconds: 5
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 10
periodSeconds: 10
A failing readiness probe removes the Pod from its Service; a failing liveness probe restarts the container. The probes tutorial and readiness probe failed cover the difference.
Debugging: k logs, k logs --previous, k describe, k exec, k top pod, and k debug to attach a debugging container. API deprecations: if a manifest uses an old apiVersion, k explain <kind> and k api-resources show the current one.
Speed techniques
- Generate, then edit:
k run app --image=nginx --dry-run=client -o yaml > app.yaml. Most CKAD tasks are "create this Pod with these extra fields", so start from generated YAML every time. - Set a shortcut:
export do="--dry-run=client -o yaml". k explainbeats the docs for field names:k explain pod.spec.containers.securityContext.- Check your YAML before applying:
k apply -f app.yaml --dry-run=servercatches field typos without creating anything. - Confirm each task works with
k get,k describeor a quickcurlfrom a test Pod before moving on.
A five-week study plan
| Week | Focus |
|---|---|
| 1 | Pods, Deployments, Jobs, CronJobs; imperative commands until they are automatic |
| 2 | ConfigMaps, Secrets, ServiceAccounts, SecurityContext, resources and quotas |
| 3 | Multi-container Pods, volumes, probes, debugging |
| 4 | Services, Ingress, NetworkPolicy, rolling updates, blue/green and canary, Helm, Kustomize |
| 5 | Timed practice and both killer.sh sessions |
Practise on a local kind cluster, and time yourself from week 3 onwards.
Frequently Asked Questions
Is the CKAD easier than the CKA?
Most people find it narrower rather than easier. It skips cluster administration, but it expects you to write Pod specs with probes, security contexts, volumes and config quickly and correctly, and the time pressure is the same.
What is the CKAD passing score?
66%, the same as the CKA. Results arrive by email within 24 hours.
Do I need to know Docker for the CKAD?
Yes, at a practical level. One of the domains covers defining, building and modifying container images, and you need to understand images, ports and volumes to write good Pod specs.
Can I use the documentation during the CKAD?
Yes: kubernetes.io/docs including its search, the Kubernetes blog and the Helm documentation, inside the exam environment's browser.
CKAD or CKA: which is better for a DevOps job?
The CKA is named more often in DevOps, platform and SRE job descriptions. The CKAD suits developers and engineers who mainly deploy applications. Because they overlap a lot, many people take both.
How long is the CKAD valid?
Two years, and it includes one free retake if you do not pass the first attempt.