KCNA Container Orchestration Practice Question
A Kubernetes cluster has a single control plane node and two worker nodes. The control plane node fails. What is the immediate impact on the workloads running on the worker nodes?
⚠ Common exam trap
CNCF often tests the misconception that the control plane is required for all pod operations, leading candidates to assume workloads stop immediately, when in fact the kubelet provides resilience for existing pods.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Existing workloads continue running, but no new pods can be scheduled
In Kubernetes, the control plane is responsible for scheduling new pods and maintaining desired state via the API server, controller manager, and scheduler. When the control plane fails, the kubelets on worker nodes continue to run existing pods based on their local state, but the scheduler cannot assign new pods to nodes, and the API server is unavailable for updates or scaling operations.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
All workloads will stop immediately
Why it's wrong here
Existing pods on the worker nodes keep running because kubelets and container runtimes operate independently of the control plane; only scheduling, reconciliation and API operations halt. It is tempting because losing the control plane sounds fatal, and it would be correct if the worker nodes themselves powered off or their kubelets stopped.
- ✓
Existing workloads continue running, but no new pods can be scheduled
Why this is correct
Worker nodes run kubelet and their containers independently, so existing pods keep serving traffic. However, the scheduler and controller manager reside on the failed control plane, so no new pods can be placed and failed pods are not replaced, satisfying the immediate-impact constraint.
- ✗
The kubelet on worker nodes will restart all pods
Why it's wrong here
Kubelets do not restart pods when the control plane is unreachable; they continue running existing containers and simply report status failures. It is tempting because kubelet restarts containers after crashes, and it would be correct if a pod's container process itself exited and the restart policy triggered a local restart.
- ✗
Workloads will be automatically migrated to another cluster
Why it's wrong here
Kubernetes has no mechanism to migrate workloads to another cluster; clusters are independent, and multi-cluster failover requires external tooling. It is tempting because disaster recovery designs do shift workloads between clusters, and it would be correct if a federation or GitOps controller were configured to redeploy them elsewhere.
Go deeper
Related to this question
About these practice questions
This KCNA question is part of Courseiva's 930-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way this is tested on KCNA
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. A Kubernetes cluster has two nodes: control-plane and worker. The worker node runs several pods. The control-plane node becomes unreachable. What is the immediate impact on the pods running on the worker node?
hard- A.All pods are immediately terminated
- ✓ B.Pods continue running, but new pods cannot be scheduled
- C.Pods are rescheduled to the control-plane node
- D.The worker node is automatically cordoned
Why B: When the control-plane node becomes unreachable, the kube-controller-manager cannot communicate with the kubelet on the worker node, so it stops performing scheduling and reconciliation. However, the kubelet on the worker node continues to run existing pods based on the last known desired state stored locally, and the pods themselves are managed by the container runtime (e.g., containerd) independently of the control-plane. Therefore, pods continue running normally, but no new pods can be scheduled because the scheduler, which runs on the control-plane, is unavailable.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This KCNA practice question is part of Courseiva's free CNCF certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the KCNA exam.