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 image name or tag is incorrect

  Why this is correct

  ImagePullBackOff is the kubelet's status when it fails to fetch a container image, and the most frequent cause is a typo in the image name or an invalid/unavailable tag (for example, `nginx:lateest` or `myapp:v2` that does not exist in the registry). The kubelet retries the pull with an exponential backoff, and the underlying error — such as `manifest unknown` or `not found` — is visible in the pod's Events via `kubectl describe pod`. Because the image reference itself is unresolvable, the container never starts and the pod remains in this state until the image reference is corrected.

• ✗

  The node is out of disk space

  Why it's wrong here

  A node that is out of disk space triggers the `NodeDiskPressure` condition and pod eviction, not `ImagePullBackOff`. The kubelet's eviction manager reclaims disk by deleting dead pods and unused images, and if it cannot, it marks the node as `DiskPressure` and may evict pods to free space — such pods show `Evicted` status instead. While image pulling does require writing layers to disk, a full disk either blocks new pod admission or causes eviction before the pull phase, so disk pressure is not a direct cause of ImagePullBackOff.

• ✗

  The container's memory limit is too low

  Why it's wrong here

  A container's memory limit is enforced by the runtime after the image has been successfully pulled and the container is started; it never affects the image pull phase. If the container exceeds the limit, it gets OOM-killed with exit code 137 and `OOMKilled` reason, not `ImagePullBackOff`. Resource limits are written to cgroups only once the container is created from the image, so a low memory limit cannot prevent the kubelet from downloading the image layers.

• ✗

  The pod's service account lacks permissions

  Why it's wrong here

  A service account defines RBAC permissions for talking to the Kubernetes API server; it does not control how the kubelet pulls images. For private registries, the kubelet uses imagePullSecrets attached to the pod's service account (or configured in the kubelet) to authenticate — a missing or invalid secret can cause `ImagePullBackOff` with `unauthorized`, but that is an authentication issue, not a lack of permissions. A service account with no RBAC permissions can still run pods whose images are pulled successfully, because image pull authentication is entirely separate from API authorization.

Go deeper

Related to this question