Container Orchestration →easyMultiple Choice

KCNA Container Orchestration Practice Question

Exhibit

Refer to the exhibit.

```
$ kubectl describe pod web-pod
...
Events:
  Type     Reason     Age   From               Message
  ----     ------     ----  ----               -------
  Normal   Scheduled  10m   default-scheduler  Successfully assigned default/web-pod to node-1
  Normal   Pulling    10m   kubelet            Pulling image "nginx:latest"
  Warning  Failed     9m58s kubelet            Failed to pull image "nginx:latest": rpc error: code = NotFound desc = image not found
  Warning  BackOff    9m57s kubelet            Back-off pulling image
```

Based on the exhibit, why is the pod web-pod not running?

⚠ Common exam trap

The KCNA exam often tests the distinction between pod scheduling failures (e.g., resource constraints, taints/tolerations) and container runtime failures (e.g., image pull errors), so candidates may confuse a 'Pending' pod with an 'ImagePullBackOff' pod, both of which are not running but have different root causes.

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

✓

The container image is not available in the registry.

The pod's status indicates an ImagePullBackOff error, which occurs when the kubelet fails to pull the specified container image from the registry. This typically means the image name or tag is incorrect, the registry is unreachable, or the image does not exist in the registry. The exhibit shows the pod is stuck in a waiting state with the reason 'ErrImagePull' or 'ImagePullBackOff', directly pointing to a missing or inaccessible image.

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 network policy is blocking the image pull.
Why it's wrong here
Network policies control pod-to-pod traffic after scheduling; they do not govern registry authentication or image retrieval. A pull failure stems from image reference or credential errors, while network policies are the right control when restricting which pods may communicate.
✓
The container image is not available in the registry.
Why this is correct
Kubernetes reports ImagePullBackOff or ErrImagePull when the kubelet cannot fetch the specified image, meaning the tag is absent or the registry credentials are wrong. That condition, not scheduling or resource pressure, explains why web-pod is not running.
✗
The node does not have enough memory.
Why it's wrong here
Node memory pressure would surface as an OOMKilled or Pending-with-Insufficient-memory status, not the exhibit's shown condition. It tempts because resource exhaustion genuinely blocks scheduling, and would be correct if kubectl describe showed a FailedScheduling event citing insufficient memory on every candidate node.
✗
The pod was not scheduled onto a node.
Why it's wrong here
The exhibit already shows the pod bound to a node, so scheduling succeeded; the failure lies at container runtime or image pull. It tempts because unscheduled pods do stay Pending, and this would be correct if kubectl get pods showed no node assignment and describe listed FailedScheduling.

Go deeper

KCNA Container Orchestration Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question