On this page
Intro
CKA, Certified Kubernetes Administrator, is a Linux Foundation certification offered with the Cloud Native Computing Foundation. It is a hands-on exam: instead of selecting answers, you solve tasks at a command line in a live Kubernetes environment. That changes how to prepare. Reading is useful, but speed and accuracy at the terminal decide the result, so most of your study time belongs in a practice cluster. CertMonk can help organize concept review alongside that hands-on work. The details come from the Linux Foundation CKA page.
The Linux Foundation lists no prerequisites. In practice, comfort with Linux commands and a text editor in a terminal will save you time on every task.
Exam at a glance
| Detail | CKA |
|---|---|
| Exam code | CKA |
| Questions | Multiple tasks; the reviewed page does not give a task count |
| Time | 2 hours |
| Passing score | See the vendor’s exam page; the reviewed page does not state it |
| Question types | Online, proctored, performance-based tasks solved from a command line running Kubernetes |
| Price | Check the vendor’s site for current pricing |
| Retirement | Not published; the credential is valid for 2 years, and one retake is included |
Source: Linux Foundation CKA page, reviewed November 7, 2026.
Version update. The page lists the exam as based on Kubernetes v1.37. Kubernetes releases frequently, so confirm the version and the current curriculum on the Linux Foundation page and in the candidate handbook before you start. The handbook also explains which documentation you may consult during the exam; the reviewed page does not spell this out, so read it directly.
Exam domains and weights
| Domain | Weight | In plain English |
|---|---|---|
| Troubleshooting | 30% | Find and fix problems in clusters, nodes, workloads and networking. |
| Cluster Architecture, Installation and Configuration | 25% | Build, configure and secure a cluster. |
| Services and Networking | 20% | Expose workloads and control traffic. |
| Workloads and Scheduling | 15% | Deploy applications and control where they run. |
| Storage | 10% | Provide and manage persistent storage. |
Troubleshooting is the largest domain, and it draws on everything else. Use the current curriculum from the Linux Foundation page as your checklist.
What each domain really tests
Troubleshooting
Treat troubleshooting as a method. Start with the symptom, check the object status and events, read logs, then narrow to the component: a pod, a node, the control plane, a service or the network. Practice with deliberately broken clusters, and for each fix write down what evidence pointed to the cause.
Typical scenarios include pods that will not start, nodes that are not ready, services that do not route and components that have stopped. Learn where each control plane and node component runs and how to inspect it.
Cluster Architecture, Installation and Configuration
Know the parts of a cluster and how they interact. Practice building a cluster with standard tooling, then work through role-based access control, managing cluster access, upgrades and backup and restore of the cluster datastore. Study how to extend a cluster through its standard mechanisms and how to prepare a cluster for highly available operation.
Because this is hands-on, rehearse the full procedure for each task, including the commands, until you can do it without notes. Then repeat it against the clock.
Services and Networking
Study how pods communicate: service types, how traffic is routed to pods, ingress and gateway concepts, network policies, and cluster DNS. For each concept, write what object you create and how you confirm traffic flows.
A good exercise is to deploy two applications, expose one, restrict access with a policy and then prove with test commands what is allowed and what is blocked.
Workloads and Scheduling
Cover deployments and rolling updates, configuration and secrets, scaling, and the ways to influence scheduling such as resource requests, limits, labels, taints and tolerations. Practice creating objects quickly from the command line and from a minimal YAML file you edit.
Learn how to read an object’s specification and status so you can see why a workload landed where it did, or why it did not run.
Storage
Understand volumes, persistent volumes and claims, storage classes, access modes and reclaim behavior. Walk through the life of a claim from request to binding to use, and what happens when it is released.
Practice failure cases, such as a claim that stays pending, and note the checks that explain it.
The topics above follow the Linux Foundation’s CKA curriculum; the exercises are our learning approach.
A realistic six-week study plan
This plan assumes you can work at a Linux command line. It is a suggested schedule, not a promise about readiness. Add time if containers or Kubernetes objects are new.
Week 1: set up and learn the tools
Build a practice cluster you can break and rebuild. Learn the command-line client, how to generate YAML quickly and how to find reference documentation fast. Set up your editor and shell shortcuts.
Week 2: cluster architecture and configuration
Practice cluster setup, access control, upgrades and backup and restore. Repeat each procedure until the steps feel routine.
Week 3: workloads and scheduling
Deploy, update and scale applications, then control placement. Add untimed concept questions and note the reasoning behind each uncertain choice.
Week 4: services, networking and storage
Expose workloads, apply network policies and work with persistent storage. Test each result with commands, not assumptions.
Week 5: troubleshooting
Break your cluster on purpose and fix it. Time yourself and keep a log of recurring problems and their symptoms. Leave one session open for catch-up.
Week 6: timed task practice
Run full two-hour practice sessions with realistic task mixes. Afterward, review which tasks cost the most time and why. Spend remaining sessions on those gaps.
Make a deliberate readiness decision. Finishing six weeks is an organizational milestone, not proof of readiness.
Common mistakes and how to avoid them
- Studying by reading alone. The exam is performance-based, so practice at a terminal.
- Typing everything from scratch. Learn to generate and edit YAML quickly.
- Skipping troubleshooting practice. It is the largest domain.
- Not verifying results. Confirm each change with a command before moving on.
- Using an older curriculum. Kubernetes and the exam change, so compare older material with the current one.
- Ignoring time. Two hours is tight, so practice moving on from a stuck task and returning later.
How to use practice questions well
Concept questions complement lab work. After each item, explain why the chosen answer fits and why each alternative does not, then try the matching task in your practice cluster to confirm the behavior.
CertMonk includes explanations for every answer choice, randomized practice tests, timed and untimed modes, flip-card flashcards, study games and progress by exam domain. Use the domain view to choose follow-up lab work, and flashcards for brief review of concepts and terms.
Keep a separate list of correct guesses and revisit them later without the answer choices in front of you. Remember that questions in a practice tool cannot replace the experience of solving tasks in a live environment.
Free practice questions
Use the free CKA samples below to explore the explanations and spot areas to review without a purchase.
A Deployment runs image busybox:1.36 with no command or args. Its Pods show Completed, then CrashLoopBackOff, and kubectl describe pod shows Last State: Terminated, Reason: Completed, Exit Code: 0. What is happening?
- AThe container is exceeding its memory limit and being stopped by the kernel.
- BThe image cannot be pulled, so the kubelet keeps retrying the container start.
- CA failing liveness probe is killing the container just after start.
- DThe default shell has no work and exits at once; Deployments always restart it.
Show the answer and explanation
Answer: D. The default shell has no work and exits at once; Deployments always restart it.
Correct. The container finishes successfully, but Deployment Pods use restartPolicy Always, so repeated exits trigger back-off. Give it a long-running command.
Why not the others
- A. An out-of-memory kill is reported as OOMKilled with exit code 137, not Completed with exit code 0.
- B. A pull failure shows ErrImagePull or ImagePullBackOff and the container never runs. Here it ran and exited cleanly.
- C. Probe-driven kills are logged as liveness failures and the container is terminated with a non-zero code, not Completed.
Takeaway: CrashLoopBackOff with exit code 0 means the process finished normally. Deployments expect long-running processes, so give the container a command that keeps running.
Source: Pod Lifecycle | Kubernetes
Before patching worker02 you run kubectl drain worker02. It refuses to continue and reports two problems: the node runs Pods managed by DaemonSets (kube-proxy and the CNI agent), and one Deployment-managed Pod uses an emptyDir volume whose scratch data can be discarded. There are no unmanaged Pods on the node. Which flags let the drain proceed while still evicting Pods safely? (Choose two.)
Choose 2.
- A--grace-period=0
- B--force
- C--ignore-daemonsets
- D--delete-emptydir-data
- E--disable-eviction
Show the answer and explanation
Answer: C. --ignore-daemonsets and D. --delete-emptydir-data
Correct. DaemonSet Pods would be recreated on the node immediately, so drain cannot evict them; this flag tells drain to leave them in place and continue.
Correct. Drain refuses to evict Pods using emptyDir because that data is lost with the Pod; this flag acknowledges the loss, which is acceptable for scratch data.
Why not the others
- A. This only changes how long evicted Pods get to shut down. It does not resolve either of the conditions that made drain refuse to start.
- B. This flag lets drain delete Pods that have no managing controller. The scenario states there are no unmanaged Pods, so it addresses neither reported problem.
- E. This deletes Pods directly and bypasses PodDisruptionBudgets, which removes a safety check. It also does not tell drain to skip DaemonSet Pods.
Takeaway: Typical drain: kubectl drain <node> --ignore-daemonsets, plus --delete-emptydir-data when Pods use emptyDir. Use --force only for unmanaged Pods, and uncordon the node afterwards.
Source: Safely Drain a Node | Kubernetes
A Gateway named edge in namespace infra has a single HTTP listener with no allowedRoutes field. An HTTPRoute in namespace shop sets parentRefs to name: edge, namespace: infra, but its status reports that it was not accepted by the parent. What change lets the route attach?
- ACreate a ReferenceGrant in infra that allows HTTPRoutes from shop to reference the edge Gateway.
- BSet the listener's allowedRoutes.namespaces.from to All, or to Selector with a label that matches shop.
- CDelete the parentRefs namespace field so the HTTPRoute uses its own namespace and finds the Gateway.
- DAdd spec.hostnames to the HTTPRoute, because a route with no hostname is never accepted by a listener.
Show the answer and explanation
Answer: B. Set the listener's allowedRoutes.namespaces.from to All, or to Selector with a label that matches shop.
Correct. When allowedRoutes is not set, a listener accepts routes only from its own namespace. Allowing the shop namespace lets the HTTPRoute attach.
Why not the others
- A. ReferenceGrant covers cross-namespace references such as a route pointing at a backend Service in another namespace. Route attachment is controlled by the listener's allowedRoutes.
- C. Without the namespace, the parentRef points at a Gateway named edge in shop, which does not exist.
- D. An HTTPRoute without hostnames is valid and matches any hostname the listener allows. The rejection comes from the namespace restriction.
Takeaway: A Gateway listener accepts routes only from its own namespace by default. Cross-namespace attachment is opened on the listener with allowedRoutes, not with a ReferenceGrant.
Source: Gateway API | Kubernetes
You need a Deployment named web in the current namespace that runs three replicas of the image nginx:1.27. Which command creates it in one step?
- Akubectl run web --image=nginx:1.27 --replicas=3 --restart=Always
- Bkubectl scale deployment web --replicas=3 --image=nginx:1.27
- Ckubectl create deployment web --image=nginx:1.27 --count=3
- Dkubectl create deployment web --image=nginx:1.27 --replicas=3
Show the answer and explanation
Answer: D. kubectl create deployment web --image=nginx:1.27 --replicas=3
Correct. kubectl create deployment accepts --image and --replicas, creating the Deployment and its ReplicaSet with three Pods.
Why not the others
- A. kubectl run creates a single Pod and no longer accepts --replicas, so the command fails with an unknown flag error.
- B. kubectl scale changes the replica count of an existing resource. It cannot create a Deployment or set its image.
- C. kubectl create deployment has no --count flag. The flag for the number of Pods is --replicas.
Takeaway: kubectl create deployment NAME --image=IMAGE --replicas=N is the one-step imperative form; kubectl run makes a single Pod.
A dynamically provisioned PV named pvc-7f3a holds data that must survive even if someone deletes its PVC. kubectl get pv shows its RECLAIM POLICY as Delete. Which action protects this existing volume?
- Akubectl patch pv pvc-7f3a -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'
- Bkubectl patch storageclass standard -p '{"reclaimPolicy":"Retain"}'
- Ckubectl patch pvc data -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'
- Dkubectl label pv pvc-7f3a reclaim=retain --overwrite
Show the answer and explanation
Answer: A. kubectl patch pv pvc-7f3a -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'
Correct. The reclaim policy lives on the PV and can be changed on a live volume. With Retain, deleting the claim leaves the volume and its data.
Why not the others
- B. A StorageClass reclaim policy applies only to new volumes and cannot be changed after the class is created. The existing PV keeps Delete.
- C. A PVC has no reclaim policy field. The policy is a property of the PersistentVolume.
- D. Labels are metadata for selection. The persistent volume controller ignores a label like this when the claim is deleted.
Takeaway: To protect an existing dynamically provisioned volume, patch the PV's persistentVolumeReclaimPolicy to Retain; the StorageClass only sets the policy for new volumes.
Source: Change the Reclaim Policy of a PersistentVolume | Kubernetes
FAQ
Is the CKA exam multiple choice?
No. The Linux Foundation describes it as an online, proctored, performance-based exam where you solve tasks from a command line running Kubernetes.
How long is the exam?
The Linux Foundation lists 2 hours. See the CKA page.
Which domain has the most weight?
Troubleshooting, at 30%. Cluster Architecture, Installation and Configuration follows at 25%.
Are there prerequisites?
The Linux Foundation lists none, but command-line skill and basic container knowledge make preparation much easier.
How long is the credential valid, and is a retake included?
The page lists 2 years of validity and one included retake. Confirm current terms before you register.
How long should I study?
Use six weeks as a starting framework if you already work with Linux and containers. Add time where your practice sessions show gaps.
Next step
Try free practice questions → https://app.certmonk.app/samples
