KCNA Container Orchestration Practice Question
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?
⚠ Common exam trap
Watch out — candidates often assume the control-plane is required for all pod operations, confusing the control-plane's role in scheduling and reconciliation with the kubelet's independent ability to maintain running workloads, leading them to choose immediate termination or automatic rescheduling.
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
✓
Pods continue running, but new pods cannot be scheduled
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.
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 pods are immediately terminated
Why it's wrong here
Pods are not terminated when the control-plane is unreachable; kubelet on the worker keeps existing containers running from its cached pod specs, so workloads persist. This option confuses control-plane loss with node failure. It would be correct if the worker node itself went offline, since the pods there would then stop.
- ✓
Pods continue running, but new pods cannot be scheduled
Why this is correct
Pods keep running because kubelet on the worker node maintains their containers independently of the control-plane; the API server's absence only prevents scheduling decisions, so no new pods can be placed. This satisfies the stem's immediate-impact constraint: existing workloads survive, while scheduling halts until the control-plane returns.
- ✗
Pods are rescheduled to the control-plane node
Why it's wrong here
Pods cannot be rescheduled without a functioning control plane: the scheduler, controller manager and API server all run there, so no new bindings occur. It would apply only after the control plane recovers and the node is marked NotReady.
- ✗
The worker node is automatically cordoned
Why it's wrong here
Cordoning requires interaction with the control plane.
Go deeper
Related to this question
About these practice questions
Courseiva writes every KCNA question from scratch — 930 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
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.