Courseiva
Kubernetes Fundamentals →hardMultiple Choice

KCNA Kubernetes Fundamentals Practice Question

You notice that a newly created Pod remains in 'Pending' state. Which of the following is the MOST likely cause?

⚠ Common exam trap

The KCNA exam often tests the distinction between scheduling failures (Pending) and runtime failures (ImagePullBackOff, CrashLoopBackOff), leading candidates to confuse image issues or syntax errors with resource constraints.

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

✓

There are insufficient resources available on any node to meet the Pod's requests

A Pod enters 'Pending' state when it cannot be scheduled onto a node. The most common reason is insufficient CPU, memory, or other resources on any available node to satisfy the Pod's resource requests. The Kubernetes scheduler continuously evaluates node capacity against Pod requests, and if no node can accommodate the Pod, it 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.

  • ✗

    The Pod manifest has a syntax error

    Why it's wrong here

    A manifest syntax error is rejected by the API server at submission, so no Pod object is created and nothing appears in Pending. Manifest validation is what you check when kubectl apply returns a parse or schema error, not when a Pod object exists but cannot be placed.

  • ✗

    The container image does not exist

    Why it's wrong here

    A nonexistent image produces ImagePullBackOff or ErrImagePull after the Pod is scheduled to a node, so its status is Running-pending-container, not Pending. Image availability is the cause to investigate when a Pod is assigned to a node but its container never starts.

  • ✓

    There are insufficient resources available on any node to meet the Pod's requests

    Why this is correct

    The scheduler cannot bind a Pod to any node when no node has enough allocatable CPU or memory to satisfy its resource requests, leaving it Pending. Image pull failures or crashes occur after scheduling, producing different states such as ImagePullBackOff or CrashLoopBackOff.

  • ✗

    The Service does not exist

    Why it's wrong here

    A missing Service affects only network reachability and DNS resolution; the kubelet still schedules and starts the container, so the Pod would run. Services become the answer when a running Pod cannot be reached by name or stable virtual IP, indicating selector or endpoint mismatch rather than scheduling failure.

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

1 more way 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 developer creates a Deployment with 3 replicas. The developer runs 'kubectl get pods' immediately after creation and sees that only 1 pod is in Running state, and the other 2 are Pending. What is the most likely reason for this?

medium
  • ✓ A.The cluster does not have enough resources (CPU/memory) to schedule the additional pods
  • B.The Deployment's YAML has a syntax error
  • C.The container image is not available on the worker nodes
  • D.The kubelet on the node is not running

Why A: When a Pod remains in Pending state, it indicates that the scheduler cannot find a suitable node to place it. The most common cause is insufficient cluster resources (CPU or memory) to accommodate the additional Pods, as the scheduler checks node allocatable resources against Pod resource requests. With 2 out of 3 Pods pending, the cluster likely has enough resources for only one replica, leaving the others unscheduled.

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.