CKA Practice Question: Cluster Architecture, Installation and Configuration
To make a node unschedulable without evicting existing pods, which command should be used?
⚠ Common exam trap
Many candidates confuse taints (which control pod placement based on tolerations) with cordoning (which globally blocks all scheduling), or they mistakenly choose `drain` which evicts pods, missing the explicit 'without evicting existing pods' constraint.
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
✓
kubectl cordon node01
`kubectl cordon` marks a node as unschedulable, preventing new pods from being scheduled onto it while leaving existing pods running. This is the precise command for the task described, as it modifies the node's `spec.unschedulable` field to `true` without affecting running workloads.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
kubectl cordon node01
Why this is correct
kubectl cordon node01 sets the node's `spec.unschedulable` field to `true`, which tells the Kubernetes scheduler to skip this node for all future pod placements. Existing pods on the node are completely unaffected and continue to run normally, because cordon only flips a scheduling flag and does not interact with the kubelet or the pod lifecycle. This is the exact, and only, standard command for making a node unschedulable without evicting anything.
- ✗
kubectl taint node01 key=value:NoSchedule
Why it's wrong here
kubectl taint node01 key=value:NoSchedule adds a taint to the node, causing the scheduler to reject any new pod that does not already have a matching toleration. Existing pods, however, are not evicted, and pods with tolerations—including DaemonSet pods or admin-created pods—can still be scheduled onto the node. This does not satisfy the requirement because it creates a per-pod gating rule rather than a global unschedulable state, and it is not the standard mechanism used for cordoning.
- ✗
kubectl drain node01
Why it's wrong here
kubectl drain node01 marks the node unschedulable (by cordoning it first) and then actively evicts or deletes all running pods, respecting PodDisruptionBudgets and eviction API semantics. It is intended for maintenance or node removal, not for the stated goal of keeping existing pods running. If you only want to stop new scheduling without disrupting workloads, drain is the wrong tool because its entire purpose is to empty the node.
- ✗
kubectl uncordon node01
Why it's wrong here
kubectl uncordon node01 does the exact opposite of what the question asks: it sets `spec.unschedulable` to `false` (or removes the cordon), making the node schedulable again. Running this command on an already schedulable node is a no-op, but it will certainly not prevent new pods from landing on node01. This option is wrong because it is the corrective action used after maintenance, not the one that marks a node as unschedulable.
Go deeper
Related to this question
About these practice questions
Courseiva writes every CKA question from scratch — 302 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 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.