Free study guide · DevOps

How to pass the Certified Kubernetes Application Developer (CKAD)

What the exam covers, how to plan your study, and how to read its questions. From the CertLumen course for this exam, kept up to date with the official exam guide.

What the exam covers

A study plan that works

The default path for developers who know Linux and have used kubectl before. It covers all 21 lessons and all 10 labs in order, with a section drill after each section and daily flashcards. Mock Exams 1 and 2 come on days 13 and 14, with Mocks 3 and 4 as optional extra practice. The practice exams are multiple-choice, so also use the labs and your two killer.sh sessions for the real, timed, terminal experience. Section 4 (Environment, Configuration and Security) is worth 25% and gets the most days. Schedule the real exam once you reach 80% on the mocks and finish a killer.sh session with time to spare. Plan on about 1–2 hours a day.

Exam strategy

How the exam works

The CKAD is a performance-based exam: you solve tasks at a command line on live Kubernetes clusters, not multiple-choice questions. The Linux Foundation's tips page says to expect 15 to 20 tasks in 2 hours. A proctor watches you through audio, video and screen sharing. The score report is emailed within 24 hours, normally, and you need 66% to pass. Each task has a weight shown with it, and most tasks can earn partial credit, so a half-finished task is worth more than a skipped one.

The terminal you will use

You work in a remote desktop provided by PSI. Each task starts with an infobox that tells you which cluster context to use and which host to ssh to; run exit afterwards to return to the base system. kubectl with the k alias and bash completion, plus yq, curl, wget and man, are installed on the task hosts. You cannot nest SSH. In the Linux terminal copy with Ctrl+Shift+C and paste with Ctrl+Shift+V. The INSERT key is prohibited, so use i and Esc in vim.

Pacing: 2 hours, about 17 tasks

Average about 6 to 7 minutes a task, but they are not equal. Weights run from about 2% to 8%. Read all the weights quickly at the start, do the cheap high-value ones first, flag long tasks and come back.

The k alias is already there on the task hosts, but the exports are not, and setting them costs 20 seconds. now makes pod deletes instant; use it only on Pods you created, not on controllers.

Speed rules

• Generate, don't type: k run web --image=nginx $do > p.yaml, k create deploy web --image=nginx --replicas=3 $do, k create job, k create cronjob, k create role, k create rolebinding, k create ingress, k expose.
• Use kubectl explain pod.spec.containers.securityContext --recursive for field names before you open the docs.
• When you need YAML that kubectl cannot generate (probes, volumes, NetworkPolicy, PV, PVC), copy it from kubernetes.io/docs, paste it into a file and edit. Search with the docs' search box and open the concept or task page.
• Prefer k edit for small changes to live objects and k replace --force -f for Pods whose fields are immutable.
• Always verify: k get, k describe, k logs and k rollout status after the change.

How to read a task

Tasks are short, precise and literal. Names, namespaces, labels, ports and file paths in the task must be matched exactly: a Pod called web-app is not webapp. Underline the verbs (create, expose, scale, fix, save to a file) and the nouns that give you the resource type (every node, once a day, only from, sidecar).

Traps that cost points on the CKAD

• Wrong namespace or context. The most common avoidable failure. Use -n explicitly or set the namespace on the context.
• Selector versus labels. A Service, Deployment or NetworkPolicy selects Pod labels from the template, not the metadata of the Deployment.
• command versus args. command replaces ENTRYPOINT and args replaces CMD.
• Immutable fields. Deployment selectors, Pod specs, RoleBinding roleRef, and a Pod's serviceAccountName cannot be changed in place.
• ConfigMap and Secret updates. Env variables and subPath mounts never refresh; volume mounts refresh eventually.
• runAsNonRoot needs a numeric user when the image runs as root.
• Default-deny egress also blocks DNS.
• AND versus OR in NetworkPolicy is decided by whether the selectors share a list item.
• Helm needs -n. helm list shows only the current namespace; use -A to find the release.
• Typos in indentation. Run kubectl apply --dry-run=server or k apply -f and read the error before moving on.

Using the documentation well

You may keep one browser with kubernetes.io/docs, kubernetes.io/blog and helm.sh/docs. Know where things live so you never browse: the Tasks section has copy-ready YAML for probes, volumes, Pod security, ConfigMaps and Secrets, ServiceAccounts and Services; Concepts has NetworkPolicy, Ingress, PV and PVC examples; the kubectl Quick Reference has jsonpath, rollout and top syntax. Search for the object name plus 'task' or 'concept' and open the first kubernetes.io hit.

What to do in the last week

1. Take Mock Exam 3 and Mock Exam 4 and redo anything below 80%.
2. Run your second killer.sh session as a real timed 2-hour attempt; the questions differ from the first session, and you should compare your time per task.
3. Re-do every lab with the lesson closed.
4. Write these from memory: a hardened Pod, a NetworkPolicy with AND selectors, a PV/PVC/Pod trio, a CronJob with concurrencyPolicy, an Ingress with TLS.
5. Run the PSI system check on the exam computer and fix the room and desk.
6. The evening before, review the cheat sheet and keyword cues only.

Words that point to the answer

Phrases in a question that usually point to one answer. The course has the full list.

Revise from the cheat sheet

The course's cheat sheet has a page for each of these:

• Design and build: images, workloads, Pods and volumes
• Deployment: strategies, rolling updates, Helm and Kustomize
• Observability: deprecations, probes, monitoring and debugging
• Environment, configuration and security
• Services and networking