CKA Troubleshooting Practice Question
A pod is in 'Pending' state. Which TWO of the following are possible causes? (Select 2)
⚠ Common exam trap
CKA often tests the distinction between Pending (scheduling phase) and other failure states like CrashLoopBackOff or ImagePullBackOff, causing candidates to select runtime errors as causes of Pending.
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
✓
Node has insufficient CPU or memory resources
Option A is correct because when a node lacks sufficient allocatable CPU or memory, the kube-scheduler cannot find a feasible node and leaves the pod in Pending with a FailedScheduling event. Option C is correct because a pod that references a PersistentVolumeClaim that is not yet Bound (for example, waiting on a dynamic provisioner or a matching PersistentVolume) will remain Pending until the PVC binds. Option B is incorrect because a non-zero container exit code indicates a runtime failure after the container started, producing CrashLoopBackOff or Error, not Pending. Option D is incorrect because OOMKilled occurs when a running container exceeds its memory limit, resulting in a terminated container rather than a Pending pod. Option E is incorrect because a misspelled image name causes an ImagePullBackOff/ErrImagePull status once the kubelet attempts to pull the image, not a 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.
- ✓
Node has insufficient CPU or memory resources
Why this is correct
A Pod can only stay Pending when the scheduler is unable to place it on a node. If every node lacks sufficient allocatable CPU and/or memory to satisfy the Pod's `resources.requests`, kube-scheduler marks the Pod unschedulable and leaves it in Pending while continuously retrying scheduling. This is purely a pre-scheduling condition, so it remains until a node is scaled up or the requests are reduced.
- ✗
Container exited with non-zero exit code
Why it's wrong here
A non-zero container exit code is an event that only happens after the Pod has been successfully scheduled and the kubelet has started the container. The exit code is recorded in the container's `lastState` or `exitCode`, and the restart policy causes a restart, eventually leading to CrashLoopBackOff if the code repeats. This is a runtime lifecycle issue, not a reason for the Pod to stay in the initial scheduling-level Pending state.
- ✓
PersistentVolumeClaim is not bound
Why this is correct
When a Pod references a PersistentVolumeClaim, that claim must be `Bound` to a PersistentVolume before the Pod can start. The scheduler also considers that volume availability can depend on `WaitForFirstConsumer`; if the PVC is unbound or in `Pending`, the Pod itself will remain Pending even if nodes otherwise have capacity. Kubernetes holds the Pod to allow the volume-controller to bind and can delay node assignment until storage is provisioned.
- ✗
Container was killed due to OOM
Why it's wrong here
OOMKilled is a container status that occurs when the Linux OOM killer terminates a process in an already-running container because it exceeded its memory limit. After that, the kubelet restarts the container according to the restart policy, which produces CrashLoopBackOff if it immediately exhausts memory again. It differs from Pending because the container was actually run and terminated, whereas Pending means the container was never started.
- ✗
Image name is misspelled
Why it's wrong here
If the container image name is misspelled, kube-scheduler still sees a valid Pod specification that can be placed on a node; image validity is not checked during scheduling. Once the kubelet on that node attempts to pull the image, the registry returns ErrImagePull/ImagePullBackOff because no matching repository/tag exists. Thus the symptom appears in the container waiting phase, not as a node-placement failure keeping the Pod Pending.
Go deeper
Related to this question
Learn chapter
Troubleshooting Cluster and Node Issues
Key term
Pod Failure Troubleshooting
Pod failure troubleshooting is the process of identifying and resolving issues that cause Kubernetes pods to crash, restart, or become unavailable.
Key term
Persistent Volumes
A Persistent Volume is a piece of storage in a Kubernetes cluster that has been provisioned by an administrator and exists independently of any single pod that uses it.
About these practice questions
This CKA question is part of Courseiva's 726-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 CKA 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 CKA exam.