Google ACE Practice Question: You run `kubectl get pods` and see a pod in…

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Incorrect image name/tag, or missing pull credentials for a private registry.

  Why this is correct

  ImagePullBackOff means the kubelet could not successfully fetch the container image from the registry. An incorrect image name or tag causes a 404 Not Found response from the registry, while missing or invalid pull credentials for a private registry result in a 403 Forbidden response. Both failure modes prevent the image from being downloaded, so the kubelet enters ImagePullBackOff and retries with an exponential backoff. To resolve this, correct the image reference or create an imagePullSecret and attach it to the Pod.

• ✗

  Insufficient CPU/memory on the node, or the pod's resource requests are too high.

  Why it's wrong here

  Insufficient CPU or memory on the node, or resource requests that exceed available capacity, are scheduling problems that keep the Pod in the Pending phase. The scheduler cannot place the Pod onto any node, and the kubelet never attempts to pull the image because the container is never created. In contrast, ImagePullBackOff occurs after the Pod has been scheduled and the kubelet starts pulling the image but fails to do so. Thus, resource insufficiency produces Pending status with scheduling events, not ImagePullBackOff.

• ✗

  The pod's liveness probe is failing, causing the container to restart.

  Why it's wrong here

  A failing liveness probe also occurs post-start, after the image is already present and the container is running. When the liveness probe fails, kubelet kills the container and restarts it according to the restartPolicy, eventually producing CrashLoopBackOff if failures persist. ImagePullBackOff is triggered during image acquisition, not during container health checks, and the probe could not even run if the image were not pulled. Thus, liveness probe failure is a separate issue from ImagePullBackOff and requires checking the application's health status, not the image reference or credentials.

• ✗

  The container's entrypoint command is failing, causing the image pull to abort.

  Why it's wrong here

  The container entrypoint command failing is a runtime issue that occurs only after the image has been successfully pulled and the container has started. When the entrypoint exits with an error, Kubernetes restarts the container, leading to CrashLoopBackOff. ImagePullBackOff is specifically a pre-start failure during the image fetch phase, before any container process executes. Therefore, an entrypoint failure cannot abort an image pull, because the pull has already completed successfully.

Go deeper

Related to this question