KCNA Container Orchestration Practice Question
A pod is stuck in the Pending state. Running 'kubectl describe pod <pod-name>' shows the event: '0/3 nodes are available: 1 node had taint {node.kubernetes.io/disk-pressure: }, 2 nodes had taint {node.kubernetes.io/memory-pressure: }'. What is the most likely cause?
⚠ Common exam trap
CNCF often tests the distinction between taints/tolerations and resource constraints, where candidates mistakenly attribute a Pending state to resource exhaustion when the actual cause is missing tolerations for node taints.
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
✓
All nodes have taints that the pod does not have tolerations for
The pod is stuck in Pending because the scheduler cannot find a node that satisfies its scheduling constraints. The events show that all three nodes have taints (disk-pressure and memory-pressure), and the pod does not have corresponding tolerations to allow it to be scheduled on those nodes. Without tolerations, the pod is not permitted to run on any of the available nodes, leaving it in the Pending state.
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 nodes have taints that the pod does not have tolerations for
Why this is correct
The scheduler cannot bind the pod because every candidate node carries a taint — disk-pressure or memory-pressure — for which the pod declares no matching toleration. Taints repel pods lacking tolerations, so no feasible node remains and the pod stays Pending, exactly matching the "0/3 nodes are available" event.
- ✗
The container image is not found in the registry
Why it's wrong here
Image-pull failures surface as ErrImagePull or ImagePullBackOff events, not Pending, so a missing registry image cannot explain the taints shown. It is tempting because image-not-found genuinely blocks pod startup, and would be the answer if describe reported a pull error rather than node taints.
- ✗
The pod has a resource request that exceeds available capacity on all nodes
Why it's wrong here
The taints shown are node conditions, not capacity shortfalls: disk-pressure and memory-pressure are applied by the kubelet when a node's own disk or memory thresholds are breached, so the scheduler refuses placement regardless of the pod's requests. It tempts because insufficient allocatable CPU or memory genuinely leaves pods Pending, but that event reads "Insufficient cpu/memory" instead.
- ✗
The pod's liveness probe is failing
Why it's wrong here
A failing liveness probe restarts a running container; it cannot produce a Pending pod, since scheduling occurs before any probe executes. The event names node taints — disk-pressure and memory-pressure — as the binding constraint. Liveness probes are tempting when diagnosing CrashLoopBackOff, where repeated restarts stem from failed health checks.
Go deeper
Related to this question
About these practice questions
This KCNA question is part of Courseiva's 930-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 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.