CKS Supply Chain Security Practice Question
A pod is stuck in Pending state. 'kubectl describe pod' shows '0/1 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/control-plane: }, that the pod didn't tolerate.' The pod does not specify any tolerations. What is the most likely cause?
⚠ Common exam trap
The CKAD/CKS exams often test the distinction between different pod failure states (Pending vs. ImagePullBackOff vs. CrashLoopBackOff) and expect candidates to recognize that taint-related scheduling issues produce a specific message in 'kubectl describe pod', not resource or image errors.
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 cluster only has control-plane nodes and the pod does not tolerate the control-plane taint
The error message '0/1 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/control-plane: }, that the pod didn't tolerate' indicates that the only node in the cluster is a control-plane node, which by default has the node-role.kubernetes.io/control-plane taint. Since the pod does not specify any tolerations, it cannot be scheduled on that node, leaving it stuck in Pending state. This is the most likely cause because the cluster lacks worker nodes, and the pod is not designed to run on the control-plane.
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 pod's image pull secret is missing
Why it's wrong here
A missing image pull secret surfaces as ImagePullBackOff or ErrImagePull after scheduling, not as a Pending pod with a taint message. It is tempting because private-registry authentication genuinely blocks pod startup, and creating the secret would be correct when the pod reports image pull failures.
- ✗
The pod uses an untrusted image that was rejected by an admission webhook
Why it's wrong here
Admission webhook rejection occurs at the API server before scheduling, so the pod would be denied outright rather than left Pending with a taint event. It is tempting because image policy enforcement does stop untrusted workloads, and would be correct when creation is refused by a validating webhook.
- ✗
The pod's resource requests exceed the available node capacity
Why it's wrong here
The scheduler message names a taint the pod does not tolerate, not insufficient CPU or memory; resource exhaustion would report 'Insufficient cpu' or 'Insufficient memory' instead. It is tempting because pending pods commonly stem from over-large requests, and raising requests would be the fix in that scenario.
- ✓
The cluster only has control-plane nodes and the pod does not tolerate the control-plane taint
Why this is correct
The scheduler reports only one node, tainted node-role.kubernetes.io/control-plane, and the pod declares no tolerations, so no node satisfies its scheduling requirements. With no worker nodes present, the pod remains Pending indefinitely until the taint is tolerated or capacity is added.
Go deeper
Related to this question
About these practice questions
Courseiva writes every CKS question from scratch — 845 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 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.