CKA Practice Question: Cluster Architecture, Installation and Configuration
A node has been cordoned. Which statement about the node is true?
⚠ Common exam trap
A common mix-up: candidates confuse `cordon` with `drain` — candidates often think cordoning also evicts pods, but it only prevents new scheduling, leaving existing pods untouched.
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
✓
The node is marked as unschedulable, but existing pods continue to run
When a node is cordoned using `kubectl cordon <node>`, it is marked as unschedulable by setting the `spec.unschedulable` field to `true`. This prevents new pods from being scheduled onto the node, but existing pods continue to run normally. The kubelet remains active, and the node stays in the cluster.
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 on the node are immediately terminated
Why it's wrong here
When a node is cordoned, the `spec.unschedulable` field is set to `true` in its Node object, which makes the kube-scheduler exclude it from future placement decisions. This action does not interact with the kubelet or the pod lifecycle, so already-running pods are left untouched. Immediate termination only occurs when a node is drained or when pods are manually deleted; cordoning alone has no effect on currently running containers.
- ✗
The kubelet on the node is stopped
Why it's wrong here
Cordoning is a control-plane operation that modifies the Node's scheduling metadata; it does not issue any instruction to the kubelet. The kubelet process on the node continues to run, ensuring that all assigned containers are healthy, reporting status to the API server, and performing liveness/readiness probes. Stopping a kubelet would require an explicit action like `systemctl stop kubelet` or node shutdown, which is unrelated to this scheduling abstraction.
- ✗
The node is removed from the cluster
Why it's wrong here
Neither the Node resource nor its actual machine is removed or unregistered when you run `kubectl cordon`. The node is still a full member of the cluster and the API server continues to receive its heartbeat and status updates from the kubelet. Removal from the cluster happens only when the Node object is explicitly deleted via `kubectl delete node`, or when the node's machine is permanently terminated and its controller cleans it up after a prolonged NotReady state.
- ✓
The node is marked as unschedulable, but existing pods continue to run
Why this is correct
The correct effect of cordoning is to mark the node as unschedulable by setting `spec.unschedulable: true`, which tells the scheduler to avoid placing any new pods on it. However, the pods that are already scheduled and running are unaffected and continue their lifecycle normally until they finish, are evicted, or are explicitly deleted. This is why cordon is the preferred first step before a node drain: it prevents new workloads while letting existing ones remain available during maintenance preparation.
Go deeper
Related to this question
About these practice questions
This CKA question is part of Courseiva's 726-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 →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CKA 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 CKA exam.