KCNA Kubernetes Fundamentals Practice Question
A developer inspects a Pod and sees that it is stuck in the Pending phase. Which two conditions can legitimately cause a Pod to remain Pending? (Choose two.)
⚠ Common exam trap
The trap here is blaming image pull failures for a Pending Pod, when those failures happen after scheduling and surface as ImagePullBackOff.
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 Pod requests a PersistentVolumeClaim that is not yet bound and uses a storage class with WaitForFirstConsumer.
A Pod stays Pending whenever the scheduler cannot place it or its volumes are not ready. Unsatisfiable resource requests, affinity rules, or taints block scheduling, and a WaitForFirstConsumer PersistentVolumeClaim deliberately delays binding until a node is chosen. Image pull errors, failed liveness probes, and token expiry all occur after scheduling and therefore do not cause the Pending phase.
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 container image cannot be pulled from the registry.
Why it's wrong here
An image pull failure occurs after the Pod has been scheduled to a node, so the Pod moves to the Running phase with a container in Waiting state, often showing ImagePullBackOff. It does not keep the Pod in Pending. This option confuses a container-level failure with a scheduling-level one.
- ✓
The Pod requests a PersistentVolumeClaim that is not yet bound and uses a storage class with WaitForFirstConsumer.
Why this is correct
With WaitForFirstConsumer binding mode, the volume is provisioned only after a node is chosen, and the scheduler holds the Pod until the claim is satisfiable. Until then the Pod remains Pending, which is expected behavior rather than a failure. This is a legitimate scheduling-related cause of the Pending phase.
- ✓
No node in the cluster satisfies the Pod's resource requests or node affinity rules.
Why this is correct
When the scheduler cannot find a node that meets resource requests, node affinity, or taints and tolerations, it leaves the Pod unscheduled and it stays Pending. Events such as FailedScheduling record the reason. This is one of the most common causes of a Pending Pod and is directly tied to scheduling constraints.
- ✗
The Pod's liveness probe is failing repeatedly.
Why it's wrong here
A failing liveness probe causes the kubelet to restart the container, producing CrashLoopBackOff on a scheduled Pod. The Pod has already been placed on a node, so its phase is not Pending. This option describes a runtime health problem, not a scheduling problem.
- ✗
The Pod's ServiceAccount token has expired.
Why it's wrong here
Projected ServiceAccount tokens are rotated automatically by the kubelet, and an expired token would affect API access inside a running container, not scheduling. It does not prevent the Pod from being assigned to a node. This option misattributes an authentication concern to the Pending phase.
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 and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official CNCF exam blueprint
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.