KCNA Pod Pending state Practice Question
A pod is stuck in 'Pending' state. Which of the following is NOT a common cause for a pod to remain Pending?
⚠ Common exam trap
Candidates often confuse issues that affect pod scheduling with those that affect pod execution. Container runtime problems cause pods to fail after starting, not to remain in Pending state. The question tests understanding of which conditions prevent scheduling vs. those that impact running pods.
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 container runtime is not functioning on the node
A non-functioning container runtime on a node typically results in pod states like CrashLoopBackOff or Error, not prolonged 'Pending' state. Pending state occurs when a pod cannot be scheduled. Insufficient resources (A), node selector mismatch (B), and unbound PVCs (D) are common causes of scheduling failures that keep a pod in Pending. Container runtime issues affect pod execution after scheduling, not the scheduling process itself. Therefore, C is NOT a common cause for a pod to remain Pending.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Insufficient CPU or memory resources available in the cluster
Why it's wrong here
Insufficient CPU or memory on candidate nodes is a classic scheduling failure, leaving the pod Pending until resources free up or the cluster scales. Since the question asks which cause is NOT common, this is a genuine cause, so it cannot be the answer being sought.
- ✗
The node selector in the pod spec does not match any node labels
Why it's wrong here
A node selector matching no node labels prevents the scheduler from finding a feasible node, so the pod stays Pending indefinitely. As the question asks which cause is NOT common, this is a legitimate cause and therefore not the exception the question requires.
- ✓
The container runtime is not functioning on the node
Why this is correct
A non-functioning container runtime produces container creation or start failures on an already-scheduled node, typically surfacing as 'ContainerCreating' or 'CrashLoopBackOff', not 'Pending'. Pending specifically indicates the scheduler cannot bind the pod, driven by insufficient resources, unsatisfied node selectors or affinity, or unbound PersistentVolumeClaims.
- ✗
The pod's PVC is not yet bound to a PV
Why it's wrong here
An unbound PersistentVolumeClaim is a genuine and frequent cause of Pending pods: the scheduler cannot place a pod whose volume claim has no matching PersistentVolume. Because the question asks which cause is NOT common, this option is therefore a real cause, not the exception being sought.
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.