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.

• ✗

  A PersistentVolumeClaim is not bound

  Why it's wrong here

  A scheduler cannot place a pod that references a PersistentVolumeClaim that is unbound or pending because the volume must be attached before the pod can start. The events from `kubectl describe pod` would explicitly mention `persistentvolumeclaim` and show messages like "persistentvolumeclaim not found" or "unbound volume", not a node selector mismatch. This failure mode is fundamentally different: it originates from volume binding rather than from node label selection, so it would not explain a pending pod caused by an absent label match.

• ✗

  All nodes have insufficient memory or CPU

  Why it's wrong here

  If every node lacks enough allocatable memory or CPU to satisfy the pod's requests, the scheduler will report per-node failure events containing entries such as `Insufficient memory` and `Insufficient cpu`. These resource-fit checks are separate predicates from label matching; a nodeSelector mismatch would generate an event like `didn't match node selector` instead. Because the question's diagnostic would cite resource insufficiency rather than label selection, this option is incorrect for a pure nodeSelector problem.

• ✗

  The nodes have taints that the pod does not tolerate

  Why it's wrong here

  A taint on a node repels pods unless the pod has a matching toleration, and the scheduler logs events such as `node(s) had untolerated taint` for every tainted node. This is an exclusionary mechanism based on taint keys, not a requirement for positive label matching like nodeSelector. If taints were the cause, `kubectl describe pod` would show taint-related messages, not a `node selector` failure, making this option wrong for the stated symptom.

• ✓

  The pod's nodeSelector does not match any node labels

  Why this is correct

  A nodeSelector in the pod spec requires the selected node to have all the specified label key-value pairs. If no node in the cluster carries those labels, the scheduler marks those nodes as failing the `node selector` predicate and the pod remains Pending with an event like `0/N nodes are available: N node(s) didn't match node selector`. This is the canonical cause of a pending pod when there are no volume, resource, or taint issues, and it is confirmed by checking node labels with `kubectl get nodes --show-labels`.

Go deeper

Related to this question