CKA Troubleshooting Practice Question

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