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.

• ✓

  PersistentVolumeClaim not bound

  Why this is correct

  A pod that references a PersistentVolumeClaim (PVC) remains in Pending when that claim is unbound because the scheduler cannot determine which node has the required storage volume unless the PVC is already in the Bound phase. The kubelet will not start containers until all referenced volumes are successfully attached and mounted, and if the PVC is lost or awaiting dynamic provisioning, the pod cannot progress. For example, a manually pre-created PV with a mismatched access mode or storage class can leave the PVC unbound, indefinitely keeping the pod in Pending.

• ✗

  Liveness probe failing

  Why it's wrong here

  A failing liveness probe does not cause a pod to be Pending because liveness probes are executed only after the container has started and is running. When a liveness probe fails, the kubelet kills and restarts the container according to the restartPolicy, leading to states like CrashLoopBackOff or a high restart count, but the pod has already been scheduled onto a node and has passed the Pending phase. Thus, while a liveness failure implies a runtime issue, it is fundamentally different from the scheduler-level constraints that produce Pending.

• ✗

  Container image does not exist

  Why it's wrong here

  If the container image does not exist in the registry or cannot be pulled, the pod will not be Pending; instead, kubelet attempts to pull the image after the pod is successfully scheduled onto a node. The resulting failure manifests as ImagePullBackOff or ErrImagePull, with the pod in a ContainerCreating or Running-but-restarting state. Since scheduling has already occurred and the node was selected, the container image issue is a runtime pull problem, not a scheduling or pre-scheduling condition that keeps the pod in Pending.

• ✓

  Insufficient CPU or memory resources on any node

  Why this is correct

  A pod remains Pending when the scheduler cannot find any node with enough allocatable CPU and memory to satisfy the sum of resource requests from all containers in the pod. The scheduler's feasibility check filters out nodes that do not meet these minimum requests, and if no candidate node remains, the pod is left unschedulable. Resource limits are not directly used for node selection; the scheduler focuses on requests, and in a cluster with heavily utilized or overcommitted nodes, this shortage is a frequent cause of indefinite Pending.

• ✓

  Node taints that the pod does not tolerate

  Why this is correct

  Node taints cause a pod to remain Pending when the pod does not have a matching toleration for at least one of the taints present on every candidate node. The scheduler excludes tainted nodes unless the pod's toleration matches the taint's key, effect, and, if applicable, value, so a node with a taint such as node.kubernetes.io/not-ready or key=value:NoSchedule is skipped by default. Pending persists until the taint is removed or the pod is created with proper tolerations, making this a deliberate admission-control mechanism to keep pods off certain nodes.

Go deeper

Related to this question