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.

• ✓

  The pod requests more memory than available on any node and does not tolerate a node taint

  Why this is correct

  The events described are exactly what kubectl describe pod would show when the kube-scheduler cannot find a feasible node: a combination of 'Insufficient memory' (the pod's resource requests exceed allocatable memory on every node) and 'node(s) had untolerated taint' (the pod lacks a matching toleration for a taint applied to candidate nodes). Since the scheduler must satisfy both the resource request/limit check and the taint/toleration rule before binding, the pod is never assigned and remains Pending. This is a scheduling failure, not a runtime issue.

• ✗

  The kubelet on all nodes is not running

  Why it's wrong here

  If the kubelet were down on all nodes, the Kubernetes API would mark those nodes NotReady because node lease updates and health reports would stop arriving. The scheduler also generally avoids scheduling pods to nodes that report NotReady, but the events you'd see in kubectl describe would be about node availability/health (e.g., 'node not ready' or 'node is down'), not a precise combination of insufficient memory and an untolerated taint. A dead kubelet cannot even run static or existing pods, but it does not itself cause the scheduler to emit those two distinct scheduling-filter messages.

• ✗

  The pod's container image is not pullable

  Why it's wrong here

  An image that cannot be pulled triggers a different, later phase: the pod has to be scheduled and bound to a node before the kubelet attempts to pull the container image. Failures during that attempt produce ImagePullBackOff or ErrImagePull conditions in the pod status, not a Pending state with scheduler events about memory and taints. If the image were truly not pullable, the pod would sit in ContainerCreating or be retried with image pull errors, so the described events rule out this cause.

• ✗

  The pod is using a hostPort that conflicts with an existing pod

  Why it's wrong here

  A conflicting hostPort would be rejected by the scheduler's predicate specifically for port conflicts, generating events like '0/2 nodes are available: 2 node(s) had existing hostPort' or 'port 8080 is already allocated'. That kind of failure is about a specific port number, and it is mutually distinct from the memory and taint messages in the question. The pod would remain Pending, but the entire event set would point to the port, not to a lack of capacity or an untolerated taint, so this option does not match the observed output.

Go deeper

Related to this question