CKA Practice Test

CKA practice test: what's covered

• Certified Kubernetes Administrator

Free CKA sample questions

1. A kubeadm cluster loses access to all running workloads after a control plane reboot, yet the worker nodes show pods still serving traffic. Which component, if its data is corrupted, would cause permanent loss of the entire cluster state?

   • A. etcd, the distributed key-value store that persists all cluster objects
   • B. kube-proxy, which programs iptables rules on every worker node
   • C. The container runtime such as containerd running on each node
   • D. CoreDNS, which resolves Service names to their ClusterIP addresses
   Show answer

   Correct: A. etcd is the single source of truth holding every API object, so corrupting it without a snapshot loses the cluster permanently. kube-proxy only programs node networking and is rebuilt from etcd state, the container runtime merely executes containers, and CoreDNS is a workload that does not store cluster state, so none of those losses are unrecoverable.

2. While hardening a self-managed control plane, you must identify which processes run there rather than on worker nodes. Select the control plane components. (Choose THREE)

   • A. kube-apiserver, the front end that all clients and components talk to
   • B. kube-scheduler, which assigns unscheduled pods to suitable nodes
   • C. kube-controller-manager, which runs the built-in reconciliation loops
   • D. kubelet, the per-node agent that starts and supervises pod containers
   • E. kube-proxy, which implements Service virtual IPs on each worker node
   Show answer

   Correct: A and B and C. The API server, scheduler, and controller-manager are control plane processes that manage cluster-wide decisions. kubelet and kube-proxy are node components that run on every worker because kubelet supervises containers locally and kube-proxy programs Service routing, so they are not part of the control plane despite being essential.

3. Before a risky upgrade you want a consistent backup of cluster state. Which command captures an etcd snapshot using the v3 API?

   • A. ETCDCTL_API=3 etcdctl snapshot save /backup/etcd-snap.db --cacert ... --cert ... --key ...
   • B. kubectl get all --all-namespaces -o yaml > /backup/cluster-dump.yaml
   • C. etcdctl backup --data-dir /var/lib/etcd --backup-dir /backup/etcd
   • D. kubeadm reset phase etcd && cp -r /var/lib/etcd /backup/etcd
   Show answer

   Correct: A. snapshot save with ETCDCTL_API=3 and the proper TLS certs produces a point-in-time restorable snapshot. A kubectl YAML dump misses non-exported and binary state and is not a true backup, the legacy etcdctl backup command is for the deprecated v2 datastore, and kubeadm reset destroys etcd rather than backing it up.

4. After restoring an etcd snapshot to a new data directory, the kube-apiserver static pod still points at the old etcd data. Which action correctly makes the API server use the restored data?

   • A. Update the etcd static pod manifest to mount the new restored data directory, so kubelet recreates etcd against it
   • B. Run kubectl apply -f on the snapshot file to load it back into the API server
   • C. Delete the etcd Deployment and let the controller-manager recreate it
   • D. Restart kube-proxy on every node to flush the stale endpoint cache
   Show answer

   Correct: A. etcd runs as a static pod, so editing its manifest hostPath to the restored data-dir makes kubelet relaunch etcd on the new data. kubectl apply cannot ingest a binary snapshot, etcd is a static pod and not a Deployment so no controller manages it, and restarting kube-proxy does nothing because it never stores cluster state.

5. A newly joined node stays NotReady and pods scheduled to it remain in ContainerCreating with a network plugin not ready error. What is the most likely root cause?

   • A. No CNI plugin is installed or running, so the node cannot configure pod networking
   • B. The node has insufficient CPU requests configured in its kubelet flags
   • C. The kube-scheduler is down and cannot bind pods to the new node
   • D. etcd quorum was lost when the node joined the existing cluster
   Show answer

   Correct: A. The network plugin not ready message means no working CNI (Calico, Cilium, Flannel) is present, so the node cannot give pods IPs and stays NotReady. Insufficient CPU would cause scheduling failures not this message, a dead scheduler would leave pods Pending rather than ContainerCreating, and joining a node does not break etcd quorum.

Last updated: 2026-10-19

CKA practice test FAQ