The CKAD exam gives you 120 minutes to solve 15-20 hands-on tasks. Most candidates know what to do — they just can’t do it fast enough. The single most reliable way to buy back time is fluent kubectl. This cheat sheet covers every command, flag, and shortcut you actually need on exam day, organized by exam domain so you can drill them in the order they appear.
Bookmark this page, print it, or pin it to a second monitor while you practice. By the end of this guide, you’ll know exactly which commands save the most time, how to generate clean YAML without ever opening a blank file, and which patterns cover 80% of the exam.
Set Up Your Shell Before You Touch a Cluster
Before any command list, configure the exam terminal. The 30 seconds you spend here saves 20+ minutes over the exam.
# The single most important alias
alias k=kubectl
# Tab completion for kubectl AND the alias
source <(kubectl completion bash)
complete -o default -F __start_kubectl k
# Dry-run shortcut that generates YAML
export do="--dry-run=client -o yaml"
export now="--grace-period=0 --force"
# Vim setup for clean YAML editing
cat <<EOF >> ~/.vimrc
set tabstop=2
set expandtab
set shiftwidth=2
EOF
With these set, k run nginx --image=nginx $do > pod.yaml becomes a one-second muscle-memory action. The CKAD is more about generating manifests than building infrastructure — these shortcuts pay off immediately.
Context and Namespace Switching (First Command of Every Question)
Every CKAD question specifies a namespace and sometimes a cluster context. Failing to switch is the #1 silent point loss — your YAML is correct, but you applied it to the wrong namespace.
# Switch context
kubectl config use-context <cluster-name>
# Set default namespace (saves typing -n every time)
kubectl config set-context --current --namespace=<ns>
# View current context
kubectl config current-context
# List all contexts
kubectl config get-contexts
Make kubectl config set-context --current --namespace=<ns> reflexive at the start of every question.
Pods (the Foundational CKAD Resource)
# Create a pod
k run nginx --image=nginx
# Generate pod YAML without creating it
k run nginx --image=nginx $do > pod.yaml
# Pod with command and args
k run busybox --image=busybox --command -- sleep 3600
# Pod with env vars
k run nginx --image=nginx --env="KEY=value" --env="DB_HOST=db.svc"
# Pod with port exposed
k run nginx --image=nginx --port=80
# Pod with labels
k run nginx --image=nginx --labels="tier=frontend,env=prod"
# Pod with resource requests/limits
k run nginx --image=nginx \
--requests=cpu=100m,memory=128Mi \
--limits=cpu=200m,memory=256Mi $do > pod.yaml
# Pod that runs once and exits
k run runonce --image=busybox --restart=Never --command -- echo hello
# Force delete a stuck pod
k delete pod <name> $now
Deployments
# Create deployment
k create deploy nginx --image=nginx --replicas=3
# Generate deployment YAML
k create deploy nginx --image=nginx --replicas=3 $do > deploy.yaml
# Scale deployment
k scale deploy nginx --replicas=5
# Update image (rolling update)
k set image deploy/nginx nginx=nginx:1.25
# Update env var
k set env deploy/nginx LOG_LEVEL=debug
# Pause/resume rollout
k rollout pause deploy nginx
k rollout resume deploy nginx
# Rollout history and rollback
k rollout history deploy nginx
k rollout undo deploy nginx
k rollout undo deploy nginx --to-revision=2
# Watch rollout status
k rollout status deploy nginx
# Restart all pods (rolling)
k rollout restart deploy nginx
For deeper coverage, see our CKAD Deployments rolling updates and rollbacks guide.
Services
# Expose deployment as ClusterIP
k expose deploy nginx --port=80 --target-port=8080
# Expose as NodePort
k expose deploy nginx --port=80 --type=NodePort
# Generate service YAML
k expose deploy nginx --port=80 --target-port=8080 $do > svc.yaml
# Create service directly
k create svc clusterip my-svc --tcp=80:8080
k create svc nodeport my-svc --tcp=80:8080
ConfigMaps and Secrets (Major CKAD Topic)
# ConfigMap from literals
k create cm app-config --from-literal=APP_ENV=prod --from-literal=APP_DEBUG=false
# ConfigMap from a file
k create cm app-config --from-file=config.properties
# ConfigMap from a directory
k create cm app-config --from-file=./configs/
# ConfigMap from env-file (KEY=VALUE per line)
k create cm app-config --from-env-file=app.env
# Secret from literal
k create secret generic db-creds \
--from-literal=username=admin \
--from-literal=password=s3cret
# TLS secret
k create secret tls my-tls --cert=tls.crt --key=tls.key
# Docker registry secret
k create secret docker-registry regcred \
--docker-server=registry.io --docker-username=user \
--docker-password=pass [email protected]
# View a secret value (base64 decoded)
k get secret db-creds -o jsonpath='{.data.password}' | base64 -d
For consumption patterns (env vars, volume mounts, projected volumes), see our CKAD ConfigMaps and Secrets guide.
Jobs and CronJobs
# Job
k create job pi --image=perl -- perl -Mbignum=bpi -wle 'print bpi(2000)'
# Job from a CronJob template
k create job manual-run --from=cronjob/backup
# CronJob (every 5 minutes)
k create cj backup --image=busybox --schedule="*/5 * * * *" -- /bin/sh -c 'date'
# Generate CronJob YAML
k create cj backup --image=busybox --schedule="*/5 * * * *" $do > cj.yaml -- /bin/sh -c 'date'
# Suspend and resume a CronJob
k patch cronjob backup -p '{"spec":{"suspend":true}}'
k patch cronjob backup -p '{"spec":{"suspend":false}}'
For backoff limits, parallelism, completions, and concurrency policies, see our CKAD Jobs and CronJobs guide.
Multi-Container Pod Patterns
The CKAD heavily tests init containers and sidecars. There’s no clean imperative way to add either — you generate a single-container pod with --dry-run and edit the YAML.
# Generate base, then add initContainers / extra containers in vim
k run app --image=nginx $do > pod.yaml
vim pod.yaml
For full templates of init, sidecar, ambassador, and adapter patterns, see our CKAD multi-container pod patterns guide.
Probes: Liveness, Readiness, Startup
There’s no imperative shortcut. You always edit YAML. Memorize the three probe shapes:
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 5
periodSeconds: 10
readinessProbe:
exec:
command: ["cat", "/tmp/ready"]
initialDelaySeconds: 3
periodSeconds: 5
startupProbe:
tcpSocket:
port: 8080
failureThreshold: 30
periodSeconds: 10
For when each probe applies and how to debug them, see our CKAD probes guide.
Resource Requests, Limits, and QoS
# Set on existing deployment
k set resources deploy nginx --limits=cpu=200m,memory=256Mi --requests=cpu=100m,memory=128Mi
# Generate pod with resources
k run app --image=nginx \
--requests=cpu=100m,memory=128Mi \
--limits=cpu=200m,memory=256Mi $do > pod.yaml
QoS classes (assigned automatically by Kubernetes):
- Guaranteed: requests == limits for all containers
- Burstable: requests < limits, or some containers have requests/limits
- BestEffort: no requests or limits set
The exam may ask you to create a pod in a specific QoS class — match requests and limits accordingly.
Volumes for Developers
# emptyDir (transient, shared between containers in a pod)
# Add manually to YAML:
volumes:
- name: cache
emptyDir: {}
# ConfigMap as a volume
volumes:
- name: config
configMap:
name: app-config
# Secret as a volume
volumes:
- name: tls
secret:
secretName: my-tls
# PVC mount
volumes:
- name: data
persistentVolumeClaim:
claimName: data-pvc
PVC inspection:
k get pvc
k describe pvc data-pvc
k get pv
k get sc
Labels, Selectors, and Annotations
Labels and selectors are the duct tape of Kubernetes — Services, Deployments, NetworkPolicies, and many other resources use them to find pods.
# Add a label
k label pod nginx tier=frontend
# Overwrite a label
k label pod nginx tier=backend --overwrite
# Remove a label (note trailing minus)
k label pod nginx tier-
# Select pods by label
k get pods -l tier=frontend
k get pods -l 'tier in (frontend,backend)'
k get pods -l '!tier' # pods missing the label
# Add an annotation
k annotate pod nginx description="frontend service"
# Remove an annotation
k annotate pod nginx description-
Inspecting Resources (Get, Describe, Logs, Exec)
# Get with extra columns
k get pods -o wide
k get pods --show-labels
k get pods -l tier=frontend
k get pods --field-selector=status.phase=Running
# Watch live updates
k get pods -w
# Describe (the diagnosis hammer)
k describe pod nginx
# Logs
k logs nginx
k logs nginx -c sidecar # specific container
k logs nginx --previous # crashed container's last logs
k logs -l app=web --tail=50 # by label
k logs -f nginx # follow
# Exec into a pod
k exec -it nginx -- sh
k exec -it nginx -c sidecar -- sh # specific container
# Run a command in a pod
k exec nginx -- ls /etc
# Copy files
k cp ./local.txt nginx:/tmp/remote.txt
k cp nginx:/tmp/remote.txt ./local.txt
JSONPath and Custom Columns (Save Time on Filter Questions)
Several CKAD questions ask for output in a specific format. JSONPath beats piping through grep and awk.
# Get all pod names
k get pods -o jsonpath='{.items[*].metadata.name}'
# Pod IPs
k get pods -o jsonpath='{.items[*].status.podIP}'
# Custom columns (clean output)
k get pods -o custom-columns=NAME:.metadata.name,STATUS:.status.phase,NODE:.spec.nodeName
# Sort by a field
k get pods --sort-by=.metadata.creationTimestamp
k get pods --sort-by=.spec.containers[0].image
Helm (New on CKAD in 2026)
Recent CKAD updates include basic Helm questions. Memorize these:
# Add a repo
helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update
# Install a chart
helm install my-app bitnami/nginx
# List releases
helm list
# Upgrade a release
helm upgrade my-app bitnami/nginx --set replicaCount=3
# Uninstall
helm uninstall my-app
# Show values
helm show values bitnami/nginx
Helm questions on the CKAD are typically lightweight — install, upgrade with a value override, list, uninstall.
Debugging Patterns
# A pod is not running — what's wrong?
k describe pod <pod> # Look at Events at the bottom
k logs <pod>
k logs <pod> --previous
# A service has no endpoints
k get endpoints <svc> # No endpoints = label selector doesn't match
k get pods --show-labels # Verify pod labels match svc selector
# Test DNS / connectivity from a pod
k run tmp --rm -it --image=busybox:1.28 --restart=Never -- \
nslookup my-svc.dev.svc.cluster.local
k run tmp --rm -it --image=busybox --restart=Never -- \
wget -qO- --timeout=3 http://my-svc/api
For a full diagnostic playbook, see our CKAD application troubleshooting guide.
Top 10 Time-Saving Aliases
| Alias | Command | When to use |
|---|---|---|
k | kubectl | Always |
k g po | kubectl get pods | Default check |
k d po <name> | kubectl describe pod | Diagnose pod issues |
k l <pod> | kubectl logs | Debug app errors |
k l <pod> --previous | crashed container logs | Diagnose CrashLoopBackOff |
k ex -it <pod> -- sh | kubectl exec -it | Get shell in pod |
k g ev | kubectl get events | See recent cluster events |
k apply -f . | apply all manifests in dir | Apply at scale |
k delete po <p> $now | force delete | Stuck pods |
k run tmp --rm -it ... | ephemeral debug pod | Network/DNS tests |
Question-Order Strategy on the CKAD
Don’t go in order. Spend the first 5 minutes scanning all questions and noting point values. Then:
- First: All questions worth 8+ points that you can solve immediately. Bank easy points.
- Second: Medium questions in your strongest domains.
- Third: Multi-container, probes, and Helm — they need YAML edits, save them when you have a clean runway.
- Last: Flagged hard questions. Bank partial credit by writing a
--dry-runYAML even if the apply isn’t perfect.
The candidates who pass aren’t the ones who answer every question — they’re the ones who maximize points-per-minute.
How to Practice This Cheat Sheet
Reading isn’t enough — the CKAD tests muscle memory. Drill until automatic:
- Days 1-7: Practice each section on a real cluster (kind, minikube, kubeadm). Type every command.
- Days 8-14: Take timed practice questions using only this reference.
- Days 15+: Take full-length scored mock exams under exam conditions.
The fastest way to validate your speed is a realistic, scored mock. Our CKAD Mock Exam Bundle replicates the exam UI, time pressure, and scoring rubric so you know your real score before you pay $395.
Frequently Asked Questions
Q: Can I use bash completion on the CKAD exam? A: Yes. The exam terminal runs Linux with bash. Source completion at the start of every cluster session — biggest single speed boost available.
Q: How much YAML do I need to memorize?
A: Memorize the imperative commands and use --dry-run=client -o yaml to generate manifests. Only multi-container pods, probes, NetworkPolicy, and PVCs need raw YAML knowledge.
Q: Are imperative commands enough to pass the CKAD? A: For ~70% of questions, yes. The other 30% need YAML edits (probes, multi-container, init containers, volumes) — but always start from a generated manifest, never a blank file.
Q: Can I copy from the official Kubernetes docs during the exam? A: Yes. Bookmark Pods, Deployments, ConfigMaps & Secrets, Probes, and Jobs pages — those are the most-copied snippets.
Q: Do I need to know vim for the CKAD?
A: You need a terminal editor. Vim is fine if you know :set paste, :wq, and basic navigation. Don’t learn a new editor in exam week.
Q: How is CKAD different from CKA in terms of kubectl usage?
A: CKAD is more workload-focused (Pods, Deployments, Jobs, Helm) and less infrastructure-focused. You won’t run kubeadm or do etcd backups, but you’ll write more pod-spec YAML.
Ready to put this cheat sheet to the test? Take a full-length scored simulator with our CKAD Mock Exam Bundle and find out exactly where you’d score today.