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 get pod

  Why it's wrong here

  The `kubectl get pod` command only returns a terse, summary view of the pod's current status field (e.g., `ImagePullBackOff`) and its basic metadata like name, ready state, restarts, and age. It does not surface the underlying Kubernetes events, such as a failed manifest download, an unauthorized registry authentication error, or an invalid image reference, which are required to diagnose the pull failure. Thus, while it confirms the pod is not running, it cannot tell you *why* the image pull failed.

• ✗

  kubectl logs <pod-name>

  Why it's wrong here

  The `kubectl logs` command streams the standard output and standard error of a container that has already started, but in an `ImagePullBackOff` state the container is never created because the container runtime cannot fetch the image. Since there is no running or previously exited container from this pod, there are no application logs to retrieve, and the kubelet's image pull errors are recorded in the pod's status conditions and events, not in container logs. Running logs will therefore return an error or nothing, providing no diagnostic value.

• ✗

  kubectl edit pod <pod-name>

  Why it's wrong here

  The `kubectl edit pod` command opens the pod's live spec in your default editor and lets you modify fields, but the pod's controller (e.g., a Deployment or ReplicaSet) will revert or reschedule the pod because most pod fields are immutable after creation. More importantly, editing does not *show* the hidden reasons for the `ImagePullBackOff`; the error details are stored in the `status.containerStatuses` and associated events. Even if you change the image, the command itself gives you no visibility into the failure history, and any changes typically require a full pod recreation.

• ✓

  kubectl describe pod <pod-name>

  Why this is correct

  The `kubectl describe pod` command is the correct diagnostic because it aggregates the pod's status conditions, container states, and, crucially, the recent Events list from the kubelet and the image puller. For an `ImagePullBackOff`, the events will contain a specific reason such as `ErrImagePull`, `ImagePullBackOff`, `Failed to pull image`, or a registry authentication/not found error with the exact HTTP status. This detailed output is exactly what you need to pinpoint whether the problem is a typo in the image tag, missing credentials, or network connectivity to the registry.

Go deeper

Related to this question