The CKA (Certified Kubernetes Administrator) is an open-book exam. You have access to kubernetes.io/docs throughout the entire 2-hour test. That sounds generous until you realize that the exam has 17 tasks and you need to complete them all in 120 minutes — which is just over 7 minutes per task. If you're searching docs for basic command syntax, you're failing the time constraint. The docs are for looking up YAML examples and flags you don't use weekly. Everything else needs to be muscle memory.
Mumshad Mannambeth, the founder of KodeKloud and a CNCF training partner instructor, describes the pattern clearly: "On the actual CKA, I spent 22 minutes on an etcd backup task that should have taken 5, because I didn't have the certificate paths memorized. The paths are always at /etc/kubernetes/pki/etcd/ and learning that once saves you every time."
The CKA exam format and what it tests
The CKA is a performance-based exam administered through the Linux Foundation's exam delivery platform (PSI). You get a browser-based terminal with access to multiple Kubernetes clusters. Each task specifies which cluster context to use, and you must switch contexts before answering. Forgetting to switch context and working in the wrong cluster is one of the most common failure causes — and it's invisible while you're working.
| Exam Characteristic | Detail |
|---|---|
| Cost | $395 (includes one free retake) |
| Duration | 2 hours |
| Number of tasks | ~17 |
| Passing score | 66% |
| Allowed resources | kubernetes.io/docs, kubernetes.io/blog |
| Validity | 3 years |
The CKA's 5 domain areas and their weights:
| Domain | Weight |
|---|---|
| Storage | 10% |
| Troubleshooting | 30% |
| Workloads and Scheduling | 15% |
| Cluster Architecture, Installation and Configuration | 25% |
| Services and Networking | 20% |
Troubleshooting at 30% is the highest-weighted domain. This means the exam heavily tests your ability to diagnose and fix broken clusters and nodes, not just create resources from scratch.
The kubectl commands you must know cold
These commands need to be in your fingers, not in your search history.
Core resource management
kubectl get pods -n <namespace> -o wide
kubectl get all -n <namespace>
kubectl describe pod <podname> -n <namespace>
kubectl logs <podname> -n <namespace>
kubectl logs <podname> -n <namespace> -c <containername>
kubectl exec -it <podname> -n <namespace> -- /bin/sh
kubectl delete pod <podname> -n <namespace>
kubectl apply -f <manifest.yaml>
kubectl delete -f <manifest.yaml>
Imperative commands (faster than writing YAML for simple resources)
kubectl run nginx --image=nginx --restart=Never
kubectl create deployment nginx --image=nginx --replicas=3
kubectl expose deployment nginx --type=ClusterIP --port=80
kubectl create configmap my-config --from-literal=key1=value1
kubectl create secret generic my-secret --from-literal=password=mysecret
kubectl create serviceaccount my-sa
The --dry-run trick for generating YAML quickly
The fastest way to create YAML on the exam is to generate it with --dry-run=client -o yaml and redirect to a file:
kubectl create deployment web --image=nginx --dry-run=client -o yaml > web-deployment.yaml
kubectl run mypod --image=nginx --restart=Never --dry-run=client -o yaml > pod.yaml
Editing a generated YAML file takes less time than writing one from scratch and is less error-prone than copying from docs.
Rollout and scaling commands
kubectl rollout status deployment/<name>
kubectl rollout history deployment/<name>
kubectl rollout undo deployment/<name>
kubectl rollout undo deployment/<name> --to-revision=2
kubectl scale deployment <name> --replicas=5
kubectl set image deployment/<name> nginx=nginx:1.20
Node management commands
kubectl cordon <nodename> # Marks node unschedulable
kubectl uncordon <nodename> # Marks node schedulable again
kubectl drain <nodename> --ignore-daemonsets --delete-emptydir-data
kubectl taint nodes <nodename> key=value:NoSchedule
kubectl taint nodes <nodename> key=value:NoSchedule- # Remove taint
kubectl label nodes <nodename> disktype=ssd
kubectl annotate nodes <nodename> description="critical-node"
The drain command is tested directly — you must be able to safely evacuate a node before maintenance. The flags --ignore-daemonsets and --delete-emptydir-data are nearly always required. Without --ignore-daemonsets, the drain command refuses to proceed if DaemonSet pods exist. Without --delete-emptydir-data, pods using emptyDir volumes block the drain.
RBAC commands
kubectl create role pod-reader --verb=get,list,watch --resource=pods
kubectl create rolebinding read-pods --role=pod-reader --user=jane
kubectl create clusterrole cluster-admin-readonly --verb=get,list --resource=*
kubectl create clusterrolebinding admin-readonly --clusterrole=cluster-admin-readonly --user=admin
kubectl auth can-i get pods --as jane -n default
The kubectl auth can-i command is critical for verifying RBAC configurations on the exam. After creating a Role and RoleBinding, always verify with --as <user> that the permissions are actually correct before moving to the next task.
etcd backup: the command that saves clusters
etcd — the distributed key-value store that holds all Kubernetes cluster state. Every object, configuration, and secret your cluster knows about lives in etcd. Losing etcd without a backup means losing the entire cluster configuration.
etcdctl — the command-line client for interacting with etcd. On the CKA, you use etcdctl to take and restore snapshots.
The etcd backup command in full with all required flags:
ETCDCTL_API=3 etcdctl snapshot save /opt/etcd-backup.db \
--endpoints=https://127.0.0.1:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key
Every flag is required:
ETCDCTL_API=3— sets the API version; without this, you get v2 API errors--endpoints— the etcd server address (alwayshttps://127.0.0.1:2379on kubeadm clusters)--cacert— the CA certificate for verifying the server--cert— the client certificate for authenticating to etcd--key— the private key for the client certificate
The certificate paths are always /etc/kubernetes/pki/etcd/ on kubeadm-installed clusters. Memorize this path — checking it in the docs during the exam costs minutes you don't have.
Restoring from a snapshot:
ETCDCTL_API=3 etcdctl snapshot restore /opt/etcd-backup.db \
--data-dir=/var/lib/etcd-backup
After restore, update the etcd manifest (/etc/kubernetes/manifests/etcd.yaml) to point the --data-dir flag to the new location. The kubelet watches this directory and restarts the etcd static pod automatically when the manifest changes.
The most common exam mistake: forgetting to set ETCDCTL_API=3 and getting an error from the v2 API. Set it as an environment variable at the start of any etcd task: export ETCDCTL_API=3.
kubeadm upgrade: the step-by-step sequence
Cluster upgrades appear on the CKA. The sequence must be performed in the correct order — upgrading kubeadm before kubelet, control plane before workers:
Upgrade the control plane node first
Drain the control plane node before upgrading
Upgrade kubeadm, then apply the upgrade plan
Upgrade kubelet and kubectl on the control plane
Uncordon the control plane node
Repeat for each worker node (drain, upgrade, uncordon)
# On control plane
kubectl drain controlplane --ignore-daemonsets
apt-get update && apt-get install -y kubeadm=1.28.0-00
kubeadm upgrade apply v1.28.0
apt-get install -y kubelet=1.28.0-00 kubectl=1.28.0-00
systemctl daemon-reload && systemctl restart kubelet
kubectl uncordon controlplane
# On worker nodes
kubectl drain node01 --ignore-daemonsets
# SSH to node01, then:
apt-get update && apt-get install -y kubeadm=1.28.0-00 kubelet=1.28.0-00 kubectl=1.28.0-00
kubeadm upgrade node
systemctl daemon-reload && systemctl restart kubelet
# Back on control plane:
kubectl uncordon node01
The systemctl daemon-reload before systemctl restart kubelet is required when the kubelet binary changes. Skipping it causes kubelet to run the old binary despite the package being updated.
Time management strategy with 17 tasks in 120 minutes
With 7 minutes per task as your budget, some tasks will take 2 minutes and some will take 15. The tasks are not weighted equally — some are worth 4% and some are worth 13%. Managing the distribution is the key skill that separates first-attempt passers from retakers.
- Flag difficult tasks and skip them initially. The exam interface lets you flag questions. If a task requires troubleshooting a broken cluster and you're not immediately seeing the issue, flag it and return at the end. A flagged task you return to fresh beats a task you abandoned after 20 frustrating minutes with no progress.
-
Read each task twice before starting. Misreading the requirement and completing the wrong configuration wastes more time than the extra minute of reading. A task that asks you to create a pod in namespace-a that you create in namespace-b gets zero points regardless of how well you executed the wrong answer.
-
Verify context switches every time. Before every command, check that you're in the right cluster: kubectl config current-context. The context switch is the single most important habit to build in practice.
-
Test your work. After creating a pod or deployment, verify it's running: kubectl get pods. After creating an RBAC binding, verify it works: kubectl auth can-i <verb> <resource> --as <user>. Don't assume your command worked.
- Prioritize by point value when visible. Higher-point tasks on troubleshooting and cluster setup are worth more than simple pod creation tasks. If you can see the point values, spend proportional time on proportional points.
Numbered checklist for starting each CKA task:
Read the task completely — identify the cluster, namespace, and specific requirement
Note which cluster context is specified
Run
kubectl config use-context <cluster>to switch contextsRun
kubectl config current-contextto verify the switch workedExecute the task
Verify the result matches what was asked
Move to the next task
The kubernetes.io/docs navigation strategy
The open-book policy allows access to kubernetes.io/docs and kubernetes.io/blog. These pages to bookmark or know how to navigate quickly:
kubectl Cheat Sheet (
kubernetes.io/docs/reference/kubectl/cheatsheet/) —kubectlcommand syntax for rarely-used flags like--from-env-fileor--field-selectorConfigure Pods and Containers — YAML examples for resource limits, security contexts, and volume mounts
Network Policies (
kubernetes.io/docs/concepts/services-networking/network-policies/) — NetworkPolicy YAML is complex enough that copying a doc example and editing it is faster than writing from scratchetcd backup and restore (
kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/) — the exactetcdctlflags if you blank on themRBAC (
kubernetes.io/docs/reference/access-authn-authz/rbac/) — ClusterRole and ClusterRoleBinding examples
Do not use the docs for: basic kubectl get, describe, apply, delete syntax; pod and deployment YAML structure; or node management commands. These must be muscle memory. The docs should never be your first stop — only your fallback for YAML structure you use less than weekly.
Imperative vs declarative: when to use each on the exam
Use imperative commands when:
Creating a simple pod, deployment, or service with standard settings
The task can be accomplished in one or two commands
You need to verify configuration quickly with
kubectl auth can-i
Use declarative (YAML manifests) when:
The task requires multiple specifications that can't be set imperatively (resource limits, init containers, volume mounts, specific affinity rules)
You need to modify an existing resource and the change requires a manifest edit
The task says "create a manifest file" as part of the deliverable
The hybrid approach is fastest: use --dry-run=client -o yaml to generate a starter YAML, then edit that file to add the specific requirements, then apply it. This is faster than writing YAML from scratch and more reliable than trying to fit complex requirements into imperative one-liners.
Specific PBQ-style exercises to practice before the exam:
Create an etcd snapshot, corrupt the current etcd data directory, and restore from the snapshot
Drain a node, upgrade its packages to a specific version, uncordon it, and verify the cluster version
Create a ClusterRole granting read access to all resources, bind it to a ServiceAccount, and verify with
kubectl auth can-iTroubleshoot a node in
NotReadystate by diagnosing and fixing a kubelet configuration errorCreate a NetworkPolicy that denies all ingress to a namespace except from pods with a specific label
What the open-book policy actually means
You can access kubernetes.io/docs and kubernetes.io/blog (not GitHub or third-party sites). The practical use cases during the exam:
YAML examples: When you need a complex Pod spec with a specific type of volume, look it up. Don't waste memory on rarely-used volume mount syntax.
API version: When you need to confirm whether a resource uses
apps/v1ornetworking.k8s.io/v1, check the docs.ConfigMap and Secret from file syntax: The exact
--from-filevs--from-literalvs--from-env-fileflags are worth looking up if you blank.NetworkPolicy spec: NetworkPolicy YAML is complex enough that copying a doc example and modifying it is faster than writing from scratch.
Do not use the docs for: basic kubectl get, describe, apply, delete syntax; pod and deployment YAML structure; etcd backup commands; or RBAC resource names.
See also: CKAD vs CKA: what each exam tests and which to take first, Building a home Kubernetes lab for CKA exam preparation
References
Linux Foundation. (2024). CKA Exam Curriculum. https://github.com/cncf/curriculum
Kubernetes. (2024). kubectl Cheat Sheet. https://kubernetes.io/docs/reference/kubectl/cheatsheet/
Kubernetes. (2024). Cluster Administration: etcd. https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/
Mannambeth, M. (2023). Certified Kubernetes Administrator (CKA) with Practice Tests. Kodekloud. https://kodekloud.com/courses/certified-kubernetes-administrator-cka/
Marko, L. (2022). Kubernetes in Action, 2nd Edition. Manning Publications. ISBN: 978-1617297618
Linux Foundation. (2024). CKA Important Instructions and Policies. https://docs.linuxfoundation.org/tc-docs/certification/tips-cka-and-ckad
Frequently Asked Questions
Is the CKA exam open book?
Yes. The CKA allows you to access kubernetes.io/docs and kubernetes.io/blog during the exam. No other external resources are permitted. The open-book policy is helpful for complex YAML syntax but doesn't compensate for slow command recall — with 17 tasks in 2 hours, you need core kubectl commands memorized to manage time effectively.
What is the CKA passing score?
The CKA passing score is 66%. With approximately 17 tasks of varying point weights, you need to complete roughly 11-12 tasks correctly. Higher-weighted tasks like cluster troubleshooting and etcd backup contribute more to your final score than simple resource creation tasks.
What is the etcd backup command for the CKA exam?
The etcd backup command is: ETCDCTL_API=3 etcdctl snapshot save /opt/etcd-backup.db --endpoints=https://127.0.0.1:2379 --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key. Set ETCDCTL_API=3 as an environment variable first to avoid using the default v2 API.
How many questions are on the CKA exam?
The CKA has approximately 17 performance-based tasks rather than multiple-choice questions. Each task requires you to interact with a live Kubernetes cluster to complete a specific administrative objective. The number of tasks can vary slightly between exam instances.
Should I use imperative or declarative kubectl commands on the CKA?
Use imperative commands for simple resources (run, create, expose) and when they can complete the task in one command. Use declarative YAML for complex resources requiring multiple specifications. The fastest approach is generating YAML with --dry-run=client -o yaml and then editing it — faster than writing YAML from scratch and more flexible than imperative-only.