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.

• ✗

  kubectl logs <pod-name>

  Why it's wrong here

  kubectl logs is not effective for an ImagePullBackOff pod because the container image was never successfully pulled, so the container was never created or started and there is no application stdout/stderr to read. Image pull failures are emitted by the kubelet and container runtime, not captured in container logs; the logs command would simply report that the container is waiting to start or return an error instead of diagnosing why the image could not be fetched.

• ✗

  kubectl exec <pod-name> -- ls

  Why it's wrong here

  kubectl exec requires a running container in which to execute a command. In the ImagePullBackOff state, the pod is stuck in a pending/container-creating phase because the kubelet cannot pull the image, so there is no container process available for exec; the command would fail with an error such as 'cannot exec into a container: container not running'. Executing 'ls' inside the container would not expose kubelet-side image registry authentication or manifest resolution issues.

• ✗

  kubectl get events --field-selector type=Warning

  Why it's wrong here

  kubectl get events --field-selector type=Warning can show ImagePullBackOff-related warning events, but it is not the most useful command for this scenario because it indiscriminately lists warning events from the entire namespace, not just the target pod, and it omits the consolidated pod status, container states, and conditions that are necessary for a complete diagnosis. The describe command, by contrast, scopes events to the specific pod and pairs them with the exact image name, container port, restart policy, and the full status block in one view.

• ✓

  kubectl describe pod <pod-name>

  Why this is correct

  kubectl describe pod is the correct and most useful command because it displays the pod's complete status, conditions, container states, and recent events in one place, including the exact kubelet-generated error from the failed image pull. This output reveals crucial details such as the image name/tag, whether the registry returned a 'manifest unknown' error, an authentication failure, or a network issue, and shows the exponential backoff timing, enabling a precise root-cause diagnosis.

Go deeper

Related to this question