Skip to main content

Practice exam · CNCF

Certified Kubernetes Administrator (CKA) practice exam

50
questions
120
minutes
66%
to pass the practice exam
60
questions in the bank

Short answer

The Certified Kubernetes Administrator (CKA) practice exam has 50 questions in 120 minutes, with a 66% passing mark, as configured here. The fastest way to know whether you are ready is to sit a full exam on the clock and read your score by domain, not only the total.

Domains covered

  • Cluster Architecture, Installation and Configuration
  • Services and Networking
  • Storage
  • Troubleshooting
  • Workloads and Scheduling

Sample questions, with explanations

Three questions from the bank, open to read.

Question 1 · Storage

A team deploys a Deployment with a PVC that requests a volume from a StorageClass configured with `volumeBindingMode: WaitForFirstConsumer`. The PVC stays in `Pending` indefinitely, and `kubectl describe pvc` shows no provisioning events at all. Meanwhile the corresponding Pod is also `Pending` because no node can be scheduled to it (a nodeSelector references a label that exists on no node). What is the most accurate explanation for why the PVC remains Pending?

  1. The StorageClass is missing a `provisioner` field, so the PVC can never be dynamically provisioned regardless of the Pod state.
  2. The PVC needs an explicit `volumeName` set to bind under WaitForFirstConsumer mode; without it the provisioner ignores the claim.
  3. A PVC using WaitForFirstConsumer must be created in the same namespace as the StorageClass, and StorageClasses are cluster-scoped, so the binding fails.
  4. With WaitForFirstConsumer, volume provisioning is deferred until the Pod is scheduled to a node; because the Pod is unschedulable, the scheduler never triggers binding/provisioning of the PVC. ✓ (correct)
Why this is correct

WaitForFirstConsumer intentionally delays binding and dynamic provisioning until a consuming Pod is scheduled, so the provisioner can place the volume in a topology compatible with the chosen node. Since the Pod is unschedulable (its nodeSelector matches no node), the scheduler never reaches the point of triggering provisioning, leaving the PVC Pending with no provisioning events — exactly the observed symptom. 'Missing provisioner field' is wrong because that would still produce a Pending PVC but the symptom and binding mode described point to the scheduling dependency, not a malformed class; a missing provisioner also is not implied by the scenario. 'Same namespace as the StorageClass' is a misconception — StorageClasses are cluster-scoped and have no namespace, so namespace matching is irrelevant. 'Explicit volumeName required' confuses dynamic provisioning with static pre-binding; setting volumeName forces static binding to an existing PV and is not how WaitForFirstConsumer dynamic provisioning works.

Question 2 · Services and Networking

A Service named 'payments' in namespace 'prod' has a correct selector and 3 ready backend pods, yet 'kubectl get endpoints payments -n prod' shows an empty ENDPOINTS column and clients receive connection refused. The pods are Running and their readiness probes pass. The Service spec defines 'port: 80' and 'targetPort: web'. Which root cause best explains the empty endpoints?

  1. EndpointSlices are disabled by default in current Kubernetes, so the legacy Endpoints object will always appear empty and clients must use EndpointSlices directly
  2. The Service selector must include the label 'kubernetes.io/service-name=payments' on the pods, and without it the endpoint controller refuses to register any pod
  3. A Service with a named targetPort requires a headless configuration (clusterIP: None); a normal ClusterIP cannot use named ports and silently drops all endpoints
  4. The pods' containers do not declare a named container port called 'web', so the named targetPort cannot be resolved to a numeric port and no endpoint addresses are populated ✓ (correct)
Why this is correct

When targetPort is a name rather than a number, each backend pod must expose a containerPort with that exact name; if no container declares a port named 'web', the name cannot be resolved and the endpoint controller produces no addresses, which is the correct root cause. The claim that EndpointSlices are disabled and Endpoints is always empty is false: EndpointSlices are enabled and the endpoint controller still mirrors data into the legacy Endpoints object, which would be populated if endpoints existed. Named targetPorts do not require a headless Service: normal ClusterIP Services fully support named ports, so that option states a non-existent restriction. The label kubernetes.io/service-name is an internal label that the controller writes onto EndpointSlices, not a selector label you must place on pods, so requiring it on pods is fabricated.

Question 3 · Cluster Architecture, Installation and Configuration

A node `worker-2` shows `Ready,SchedulingDisabled`. You ran `kubectl drain worker-2 --ignore-daemonsets` an hour ago to do maintenance, which is now complete. New pods are not being placed there. A colleague suggests `kubectl delete node worker-2 && kubeadm reset` to 'reset its state.' What is the correct, least-disruptive action to return the node to service?

  1. Restart the kubelet on worker-2; the `SchedulingDisabled` taint is set by the kubelet and only clears on kubelet restart
  2. Delete the node object and rejoin it with `kubeadm join`, since `SchedulingDisabled` means the node has been evicted from the cluster
  3. Run `kubectl uncordon worker-2`, which clears the unschedulable mark so the scheduler can place new pods on it again ✓ (correct)
  4. Run `kubectl drain worker-2 --undo` to reverse the drain operation and re-enable scheduling
Why this is correct

`drain` cordons the node (sets `spec.unschedulable: true`, shown as `SchedulingDisabled`) and evicts pods. After maintenance, `kubectl uncordon worker-2` simply clears that flag and the scheduler resumes placing pods — the correct minimal action. There is no `kubectl drain --undo` subcommand; uncordon is the actual inverse of the cordon portion of drain. Deleting and rejoining the node is needlessly destructive: `SchedulingDisabled` does not mean the node left the cluster — it's `Ready`, just marked unschedulable. The unschedulable state is a node `spec` field set by the cordon/drain action, not a kubelet-managed taint that clears on kubelet restart, so restarting the kubelet would not uncordon it.

Take the full practice exam

  • 50 questions drawn from the bank, with a 120-minute timer
  • Score by domain and a review of every question
  • An AI tutor to talk through each question you miss
  • What you miss feeds your study plan
Start the practice examStudy the path first

Independent, unofficial practice exam. CNCF and the exam name are trademarks of their owners; UpSkillScore is not affiliated with them. Format and passing mark are the exam's configuration in UpSkillScore, not an official statement.

Frequently asked questions

How many questions does the Certified Kubernetes Administrator (CKA) practice exam have?

It has 50 questions and a 120-minute limit. The passing mark of the practice exam is 66%.

Is this the official Certified Kubernetes Administrator (CKA) exam?

No. It is an independent practice exam built to match the structure of the real one. It does not replace the official exam.

Do I need an account to take it?

You can read the structure and sample questions without an account. Taking the full timed exam, scoring by domain and the AI tutor need one.