Courseiva
Kubernetes Fundamentals →mediumMultiple Choice

KCNA Kubernetes Fundamentals Practice Question

You run 'kubectl get pods' and see a Pod in the 'Pending' state. Which of the following is a likely cause?

⚠ Common exam trap

Candidates often confuse 'Pending' (scheduling failure) with 'CrashLoopBackOff' (runtime failure) or 'ImagePullBackOff' (image pull failure), leading candidates to pick a wrong answer about application or image issues.

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

✓

No node meets the requested CPU or memory resources

A Pod enters the 'Pending' state when it cannot be scheduled onto a node. The most common reason is that no node in the cluster has sufficient available CPU or memory resources to satisfy the Pod's resource requests. The Kubernetes scheduler continuously evaluates nodes against Pod resource requirements, and if none match, the Pod remains unscheduled in 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.

  • ✓

    No node meets the requested CPU or memory resources

    Why this is correct

    The scheduler leaves a pod Pending when no node satisfies its resource requests, since it cannot bind the pod anywhere. Insufficient allocatable CPU or memory across all nodes is the classic trigger for this state.

  • ✗

    The application crashed due to a bug

    Why it's wrong here

    An application crash produces CrashLoopBackOff or Error, because the container started and then exited; the Pod was already scheduled. Pending occurs before scheduling, when no node satisfies the Pod's resource or affinity requirements. Crash handling is tempting because it is a common Pod failure, but it manifests after placement, not during it.

  • ✗

    The container image is missing

    Why it's wrong here

    A missing image yields ErrImagePull or ImagePullBackOff, since the kubelet attempts to pull after the Pod is scheduled to a node. Pending happens earlier, when the scheduler cannot assign a node. Image-pull failures are tempting because they are frequent, but they surface as waiting-container states, not Pending.

  • ✗

    The Pod has been deleted

    Why it's wrong here

    A deleted Pod disappears from kubectl get pods output rather than appearing Pending; deletion removes the object. Pending means the scheduler cannot place the Pod, typically due to insufficient resources or unsatisfied node selectors. Deletion is tempting because it also removes running Pods, but that state is absent from listings.

About these practice questions

One of 930 original KCNA 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

Same concept, more angles

5 more ways this is tested on KCNA

These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.

Variation 1. A Pod is stuck in Pending state. Which of the following is the MOST likely cause?

medium
  • A.The Pod's container is crashing
  • B.The container image has a typo
  • ✓ C.No node has enough resources to run the Pod
  • D.The Pod's liveness probe is failing

Why C: A Pod stuck in Pending state means the scheduler cannot place it on a node. The most common reason is insufficient resources (CPU, memory, or ephemeral storage) on any available node, causing the scheduler to leave the Pod unscheduled. This is indicated by the Pod's status remaining Pending and typically confirmed via `kubectl describe pod` showing events like '0/1 nodes are available: 1 Insufficient cpu'.

Variation 2. A pod is stuck in 'Pending' state. Which of the following is the MOST likely cause?

medium
  • ✓ A.There are no nodes with enough resources to run the pod
  • B.The pod has been deleted
  • C.The container image is invalid
  • D.The pod's liveness probe is failing

Why A: A pod remains in 'Pending' state when it cannot be scheduled onto a node. The most common reason is insufficient resources (CPU, memory, or ephemeral storage) on any available node to satisfy the pod's resource requests. The Kubernetes scheduler continuously evaluates node conditions and resource availability; if no node meets the pod's requirements, the pod stays unscheduled and pending.

Variation 3. A pod is stuck in 'Pending' state. Which of the following is a likely cause?

medium
  • A.The pod's command returned a non-zero exit code
  • B.The container image is invalid
  • ✓ C.Insufficient CPU or memory resources on any available node
  • D.The pod's liveness probe failed

Why C: A pod remains in 'Pending' state when the scheduler cannot find a suitable node to run it. The most common reason is insufficient CPU or memory resources on any available node, as the scheduler checks resource requests against node allocatable resources before binding the pod. If no node meets the pod's resource requirements, the pod stays pending until resources become available.

Variation 4. You have a Pod that is in 'Pending' state. What is the most likely cause?

medium
  • ✓ A.The node is out of CPU or memory resources.
  • B.The application inside the container crashed.
  • C.The container image is missing.
  • D.The Service does not have any endpoints.

Why A: A Pod in 'Pending' state indicates that the scheduler has not yet assigned it to a node. The most common reason is insufficient resources (CPU or memory) on any available node, causing the scheduler to fail to find a suitable node that meets the Pod's resource requests. This is a core scheduling failure in Kubernetes.

Variation 5. A pod is stuck in 'Pending' state. Which of the following is NOT a common cause for a pod to remain Pending?

hard
  • A.Insufficient CPU or memory resources available in the cluster
  • B.The node selector in the pod spec does not match any node labels
  • ✓ C.The container runtime is not functioning on the node
  • D.The pod's PVC is not yet bound to a PV

Why C: 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.

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.