Certified Kubernetes Application Developer (CKAD) #20: Exam Tips, Time Management, and the Patterns People Miss

From #1 through #19 we covered all five domains. This post is a compressed read-through to go over one more time right before you walk into the hands-on exam. There are no new domains here — only how to run the 2-hour practical and the traps where candidates most often leak points across the whole series. Because this is an exam where you build things directly in an empty terminal rather than picking from multiple choice, the same knowledge passes or fails depending on how you operate.

The 2-hour operating strategy #

Running it task by task #

CKAD asks you to solve roughly 15–20 tasks in 2 hours. Unlike multiple choice, you don’t split time evenly per item — each task shows its point weight on screen, and that weight is your priority.

The first rule of time management #

Don’t get absorbed in a single task. If a task is taking long relative to its weight, build it as far as you can, flag it, and move on. The passing line is 66%, so it’s fine to give up on one or two hard tasks. The most common failure is clinging to one stuck 4-point task and losing two easy 8-point ones.

Start with the high-weight, easy ones #

Skim the task list from start to finish once, mentally tagging each task’s difficulty relative to its weight. The way to clear the passing line is to bank points fast by handling tasks that finish in one generator line or use familiar resources first, then push the labor-intensive tasks to the back.

A refresher on the kubectl speed setup #

Finish the setup from #1 within a minute of the exam starting. It’s an investment that saves tens of seconds per task.

# kubectl as k
alias k=kubectl

# dry-run + YAML output as do
export do="--dry-run=client -o yaml"

# immediate deletion as now (for quickly deleting and recreating a Pod)
export now="--force --grace-period=0"

# autocompletion (extend to k too)
source <(kubectl completion bash)
complete -o default -F __start_kubectl k

In ~/.vimrc, add settings that prevent YAML indentation accidents.

set expandtab
set tabstop=2
set shiftwidth=2
set number

There are also some vim moves worth keeping in muscle memory. To indent a whole YAML block, select the lines in visual mode (V), indent one level with >, and repeat with .. If you want to inspect indentation one notch closer, use :set list to visually distinguish tabs from spaces.

Lean hard on imperative generators #

In CKAD, writing manifests by hand from scratch loses time. For most resources, it’s faster and less typo-prone to pull a skeleton with run, create, or expose and then edit only the fields you need.

# Pod skeleton
k run nginx --image=nginx $do > pod.yaml

# Deployment skeleton (with replicas)
k create deploy web --image=nginx --replicas=3 $do > deploy.yaml

# Job / CronJob skeleton
k create job pi --image=perl $do > job.yaml
k create cronjob report --image=busybox --schedule="*/5 * * * *" $do > cj.yaml

# ConfigMap / Secret
k create configmap app-config --from-literal=KEY=value $do > cm.yaml
k create secret generic app-secret --from-literal=PASSWORD=1234 $do > secret.yaml

# Service (exposing a Deployment)
k expose deploy web --port=80 --target-port=8080 $do > svc.yaml

For fields that generators can’t produce (probe, securityContext, volume, and so on), open the skeleton YAML and fill them in using kubectl explain to find the path. It’s often faster than opening the docs in a browser.

k explain pod.spec.containers.livenessProbe
k explain deployment.spec.strategy --recursive

Use the official docs quickly #

CKAD allows browsing kubernetes.io/docs and its subpages during the exam. So you don’t need to memorize every YAML field. But there are two operating principles.

• Search over bookmarks. It can be hard to carry over bookmarks you pre-built into the exam browser, so train the path of typing keywords like liveness probe or networkpolicy into the docs search bar to jump straight to the example YAML.
• Doc time is exam time too. The timer keeps running while you dig through the docs. Build skeletons for frequently used resources instantly with generators, and use the docs only to confirm the detailed fields generators can’t produce.

When you copy a YAML snippet from the docs, the indentation comes along, so right after pasting it’s safer to turn off auto-indent interference with :set paste.

The patterns people miss #

These are the recurring patterns that leak points on the practical. More points are lost to operational mistakes than to gaps in knowledge.

1) Not switching context and namespace #

Each task is only graded if solved in the specified cluster and namespace. If you don’t run first the use-context command given in the task description, even a correct answer scores zero because it was created in a different cluster.

k config use-context <the context specified in the task>
k config set-context --current --namespace=<the task's namespace>

2) Writing by hand instead of using dry-run #

Typing YAML into an empty screen from scratch is slow and error-prone. Almost every task that needs a manifest starts with k ... --dry-run=client -o yaml > file.yaml.

3) YAML indentation and tabs #

If tabs and spaces mix, or the indentation is off by one space, apply fails. Always apply expandtab and shiftwidth=2 from ~/.vimrc at the start.

4) Mismatched requested file name and path #

An instruction like “save it to /opt/course/2/pod.yaml” means the grader looks at that path. If you don’t match the path and file name exactly, you get no points even when the output is correct.

5) Not reading the task to the end #

A single task often has multiple conditions attached. If you only change the image and skip the replicas adjustment, or you add the label but miss injecting the env, you only get partial credit. Pin down every condition in the task description before you start.

6) Forcing YAML where imperative works #

Tasks like adding a label, changing an image, scaling, and rollout finish in a single command line — building and editing YAML is a waste of time.

k set image deploy/web nginx=nginx:1.25
k scale deploy/web --replicas=5
k label pod nginx tier=frontend
k rollout undo deploy/web

7) Not running apply after editing #

If you fix the YAML file but don’t run apply, the cluster never reflects it. After editing, don’t forget k apply -f file.yaml.

8) Typos in label and selector #

If a Deployment’s selector.matchLabels differs from the Pod template’s labels, creation fails; if a Service’s selector is misaligned with the Pod labels, traffic never reaches them. When you arbitrarily change a label the generator matched up, be careful not to change only one side.

Partial credit and verification #

CKAD is graded task by task, and some tasks award partial credit. Even for a task you don’t think you can solve perfectly, building it as far as you can still brings in points. And do a short verification each time you finish a task.

# whether the resource you made actually came up
k get pod,deploy,svc -n <namespace>

# whether the Pod is Running, with no restarts
k get pod nginx -o wide

# whether the applied fields are as intended
k describe pod nginx | less
k get deploy web -o yaml | grep -A3 strategy

Verification finishes within 30 seconds, but it prevents the most common point loss of all — “a task you thought was done had actually failed.”

Confusing concept pairs #

Here are the pairs that are easiest to momentarily confuse mid-task, compressed into a one-line difference.

The last row is a recurring trap. Putting restartPolicy: Always in the Pod template of a Job or CronJob gets the creation rejected. Use OnFailure or Never.

A per-domain pre-exam checklist #

The core commands and fields that should come straight to your fingers in each domain.

Domain 1: Application Design and Build (20%) #

• Multi-container Pod: two or more in spec.containers, init via spec.initContainers
• A sidecar can also be expressed in initContainers with restartPolicy: Always
• Job/CronJob: restartPolicy OnFailure/Never, completions, parallelism, backoffLimit
• CronJob schedule, concurrencyPolicy (Forbid/Allow/Replace)

Domain 2: Application Deployment (20%) #

• k create deploy, k set image, k scale, k rollout status/undo
• rolling update: strategy.rollingUpdate.maxSurge, maxUnavailable
• Helm: helm install, upgrade, rollback, -f values.yaml
• Kustomize: kustomization.yaml, k apply -k

Domain 3: Application Observability and Maintenance (15%) #

• k logs (-f, --previous, -c), checking events with k describe
• The three probes: livenessProbe, readinessProbe, startupProbe (exec/httpGet/tcpSocket)
• Debugging with k debug, k port-forward, ephemeral container

Domain 4: Application Environment, Configuration and Security (25%) #

• ConfigMap/Secret: envFrom, valueFrom, volume mount
• Specifying a ServiceAccount, RBAC Role, RoleBinding
• SecurityContext: runAsUser, fsGroup, readOnlyRootFilesystem, capabilities
• QoS determined by requests/limits, LimitRange
• Volume: emptyDir, PVC, projected, ephemeral

Domain 5: Services and Networking (20%) #

• Service via k expose, type ClusterIP/NodePort/LoadBalancer/ExternalName
• Confirming the Service selector matches the Pod labels
• Ingress rules, paths, backend
• NetworkPolicy podSelector, ingress/egress, policyTypes (understand the default-deny behavior)

A pre-exam check for online proctoring #

CKAD is an online-proctored exam where you connect to a PSI remote terminal and work there. Confirm the following before the exam starts.

ID #

• An ID with English text (a passport is recommended), with the name matching your registration details exactly
• Present both sides of the ID to the camera as the proctor’s chat instructs

Exam environment #

• Everything cleared off the desk, notes and posters removed from the walls
• Use only one monitor with dual setups; disconnect the secondary screen
• Block family and roommates from entering; secure a quiet, private space

System #

• Enter 30 minutes before the exam and pass the system check
• Close background apps, notifications, and VPN; a stable wired network is recommended
• The very first thing after the exam starts: set up alias k, do, autocompletion, and .vimrc

Wrap-up #

What this post locked in:

• The 2-hour operation. Per-task weight is the priority. High-weight, easy ones first; when stuck, flag and move on; don’t get bogged down
• The speed setup. alias k, do, now, autocompletion, and vim indentation within the first minute
• Generators and explain. Skeletons imperatively, detailed fields via k explain and search
• Using the docs. Search over bookmarks; doc time is exam time too
• The eight recurring mistakes. context/namespace, not using dry-run, indentation, file names, not reading the task fully, unnecessary YAML, missing apply, label/selector typos
• Partial credit and verification. Build as far as you can and confirm with k get
• Confusing concept pairs, per-domain core commands, online-proctoring checks

Next: the full-scale hands-on mock exam #

This is the last post.

In #21 Full-scale hands-on mock exam (an integrated all-domain scenario + explanations), you’ll solve an integrated scenario with a domain distribution close to the real exam, with detailed explanations attached. It’s the final step where you solve it timed like the exam environment and shore up the weak domains one more time.