Courseiva
mediumMultiple Choice

CKS Practice Question: An administrator runs 'kubectl describe nodes'…

An administrator runs 'kubectl describe nodes' and notices that the node status shows 'Ready,SchedulingDisabled'. What is the most likely cause?

⚠ Common exam trap

CNCF often tests the distinction between taints (which affect scheduling based on tolerations) and cordoning (which makes the node completely unschedulable), leading candidates to confuse taint-based scheduling restrictions with the explicit unschedulable flag.

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 was cordoned using 'kubectl cordon <node>'

The 'Ready,SchedulingDisabled' status indicates that the node is marked as unschedulable for new pods while remaining fully operational. This is exactly what happens when an administrator runs 'kubectl cordon <node>', which sets the node's 'spec.unschedulable' field to true. The kubelet continues to run and report readiness, but the scheduler will skip the node when placing new pods.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • ✗

    The kubelet is not running

    Why it's wrong here

    A non-running kubelet prevents the node from reporting heartbeat updates, so the Kubernetes control plane marks the node as NotReady after the node-monitor-grace-period (default 40s) elapses. A NotReady node remains schedulable by default; new pods can still be scheduled onto it unless it also has a NoExecute taint, and the status field shows 'NotReady' rather than 'SchedulingDisabled'. SchedulingDisabled is specifically a scheduler-level flag, not a health-derived condition, so kubelet failure cannot produce it.

  • ✓

    The node was cordoned using 'kubectl cordon <node>'

    Why this is correct

    Cordoning a node with 'kubectl cordon <node>' sets its unschedulable field to true, which instructs the scheduler to avoid placing new or pending pods on that node while existing pods keep running. This is exactly what surfaces as 'SchedulingDisabled' in kubectl describe node output (and often as 'Ready,SchedulingDisabled' in get nodes). The node's readiness remains True because the kubelet is healthy; only the scheduler's admission decision is changed, making cordoning the correct explanation for the observed status.

  • ✗

    The node has insufficient resources

    Why it's wrong here

    When a node experiences resource exhaustion, the kubelet reports pressure conditions such as MemoryPressure, DiskPressure, or PIDPressure in the node's Conditions list, and the scheduler may temporarily avoid scheduling new pods to that node. However, these conditions do not change the node's unschedulable boolean or produce a 'SchedulingDisabled' status; the node remains schedulable in principle, and the pressure is addressed by evicting pods or freeing resources. The absence of any pressure conditions in describe output rules this out as the cause of the displayed status.

  • ✗

    The node is tainted with NoSchedule

    Why it's wrong here

    A node with a NoSchedule taint rejects only those pods that do not tolerate it, but the node itself is still considered schedulable by the scheduler, and its status in describe remains Ready without any 'SchedulingDisabled' label. Taints are evaluated per pod during the scheduling cycle, meaning the node's unschedulable flag is not flipped; in fact, the node may accept many other pods that tolerate the taint. Thus a taint alone cannot make the node appear as SchedulingDisabled in kubectl output.

About these practice questions

One of 845 original CKS practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

This CKS 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 CKS exam.