Certified Kubernetes Administrator (CKA) Practice Test
Frequently asked questions
How many Certified Kubernetes Administrator (CKA) practice questions are here?+
A full bank of original Certified Kubernetes Administrator (CKA) practice questions across the official content areas, weighted like the real exam, with explanations. Free, no signup.
What is the Certified Kubernetes Administrator (CKA) exam like?+
A multiple-choice exam, 120 minutes, and you need 66%% to pass. Practice by topic here, then take the full timed mock exam to gauge readiness.
Are these the real exam questions?+
No. Every question is 100% original, written from public primary sources with explanations. We never copy real exam questions or paid prep material.
Can I study in Chinese or Spanish?+
PrepPass practice is in English, 中文 and Español. The official exam is in English — switch the question language to English any time to rehearse the exact terminology you'll see on test day.
Sample practice questions
A few real questions from this free bank, with full explanations. Use the practice tool above for the whole set.
- 1. Cluster Architecture, Installation & Configuration
In a standard Kubernetes control plane, which component is the only one that clients and other components talk to directly to read or change cluster state?
- a.kube-scheduler
- b.kube-apiserver
- c.kube-controller-manager
- d.kubelet
Answer: b
Explanation: The kube-apiserver is the front end of the control plane and the single entry point for all REST operations against cluster state. All other components, including the scheduler and controller manager, communicate through the API server rather than with etcd directly. Only the API server reads and writes etcd.
- 2. Cluster Architecture, Installation & Configuration
You are performing a maintenance backup of a cluster's state. Which tool and data source should you use to capture the authoritative cluster state?
- a.etcdctl snapshot save against the etcd datastore
- b.kubectl cp of the /var/lib/kubelet directory
- c.docker commit of the API server container
- d.tar of each node's /etc/kubernetes/manifests directory
Answer: a
Explanation: The authoritative record of cluster state lives in etcd, so a proper backup is taken with etcdctl snapshot save (supplying the endpoints and TLS certificates). Copying kubelet directories or static manifests does not capture object state such as Deployments, Secrets, or RBAC bindings stored in etcd.
- 3. Cluster Architecture, Installation & Configuration
A control-plane component is deployed as a static Pod. Which statement about static Pods is correct?
- a.They are scheduled by kube-scheduler like normal Pods
- b.They are managed directly by the kubelet from a manifest directory on the node
- c.They can only be created through the Kubernetes Dashboard
- d.They are stored exclusively in etcd and have no local definition
Answer: b
Explanation: Static Pods are managed directly by the kubelet, which watches a configured manifest directory (commonly /etc/kubernetes/manifests) and runs any Pod defined there. The API server shows a read-only mirror Pod for visibility, but the scheduler is not involved. This is how kubeadm runs core control-plane components.
- 4. Workloads & Scheduling
A node has a taint of key=value:NoSchedule. What must a Pod have to be scheduled onto that node?
- a.A matching toleration for that taint
- b.A nodeSelector that names the node
- c.A higher priorityClassName
- d.An init container that removes the taint
Answer: a
Explanation: Taints repel Pods unless the Pod carries a matching toleration. NodeSelectors and affinity express a Pod's preference for nodes but do not overcome a NoSchedule taint. Priority affects preemption ordering, not taint tolerance, and containers cannot remove node taints.
- 5. Workloads & Scheduling
A container specifies a CPU request of 250m and a CPU limit of 500m. What does the request value primarily influence?
- a.The maximum CPU the container can ever burst to
- b.How the scheduler decides which node has enough capacity for the Pod
- c.The container's restart policy on CPU pressure
- d.Whether the container image is pulled with high priority
Answer: b
Explanation: The request is what the scheduler uses to find a node with enough allocatable CPU, and it guarantees that minimum share under contention. The limit (500m) caps how much CPU the container may use. Requests do not affect image pulls or restart policy directly.
- 6. Services & Networking
By default, how do Pods in a Kubernetes cluster communicate with each other across nodes before any NetworkPolicy is applied?
- a.All cross-node Pod traffic is blocked until a Service is created
- b.Every Pod can reach every other Pod directly, because the network model is flat and non-isolated by default
- c.Pods can only talk to Pods on the same node
- d.Traffic must be routed through the API server
Answer: b
Explanation: Kubernetes assumes a flat network where every Pod can reach every other Pod across nodes without NAT, and all Pods are non-isolated until a NetworkPolicy selects them. NetworkPolicies (enforced by a supporting CNI plugin) are what restrict traffic. The API server is not in the data path for Pod-to-Pod traffic.
- 7. Services & Networking
A NetworkPolicy is applied that selects a set of Pods and defines only an ingress rule allowing traffic from one label-selected source. What is the effect on other incoming traffic to those Pods?
- a.All other ingress traffic to the selected Pods is denied
- b.All ingress traffic is still allowed because policies are additive only
- c.Egress traffic from the Pods is also blocked
- d.The policy has no effect until a matching egress policy exists
Answer: a
Explanation: Once a NetworkPolicy with an ingress section selects a Pod, that Pod becomes isolated for ingress and only the explicitly allowed sources can reach it; everything else is denied. Defining ingress rules does not restrict egress. This default-deny-once-selected behavior is a common exam point.
- 8. Storage
What does a StorageClass primarily enable in a Kubernetes cluster?
- a.Encryption of etcd at rest
- b.Automatic garbage collection of unused images
- c.Dynamic provisioning of PersistentVolumes on demand
- d.Scheduling Pods based on disk speed labels
Answer: c
Explanation: A StorageClass defines a provisioner and parameters that allow PersistentVolumes to be created automatically when a PersistentVolumeClaim requests that class, rather than an admin pre-creating each PV. This dynamic provisioning is the standard way to supply storage in most clusters.
- 9. Troubleshooting
A Pod is stuck in the Pending state and never starts. Which command gives the most direct clue about why the scheduler cannot place it?
- a.kubectl logs <pod>
- b.kubectl exec -it <pod> -- sh
- c.kubectl top pod <pod>
- d.kubectl describe pod <pod>
Answer: d
Explanation: kubectl describe pod shows the Events section, which typically reports scheduling failures such as insufficient CPU or memory, unsatisfied node selectors, or untolerated taints. Logs and exec require a running container, and top requires metrics and a scheduled Pod, so they cannot explain a Pending state.
- 10. Troubleshooting
kubectl commands begin failing with connection-refused errors to the API server on a kubeadm cluster. Which node-level check is most relevant first?
- a.Check the kubelet status and the API server static Pod and its container logs on the control-plane node
- b.Delete all worker nodes and re-add them
- c.Rotate every Secret in the cluster
- d.Increase the replica count of every Deployment
Answer: a
Explanation: On a kubeadm control-plane node, the API server runs as a static Pod managed by the kubelet, so checking kubelet status (systemctl status kubelet) and the API server container logs (via crictl) is the correct first step. The other actions are disruptive and unrelated to why the API server is unreachable.