CKAD Application Observability and Maintenance 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 run debug --image=busybox -it --restart=Never

  Why it's wrong here

  kubectl run debug --image=busybox -it --restart=Never launches a completely separate Pod named debug rather than injecting a debug container into the existing problematic Pod. Because it is a different Pod, it does not inherit the original Pod's network namespace, volumes, environment variables, or labels, so it cannot inspect the original container's filesystem, processes, or network behavior. You would have to manually reproduce all of the original Pod's configuration, which is inefficient and does not diagnose the actual runtime state. This command is therefore not a replacement for kubectl debug when you need to troubleshoot an existing stuck Pod.

• ✗

  kubectl attach pod-name

  Why it's wrong here

  kubectl attach pod-name attaches your terminal's standard input/output/error streams to the main process (PID 1) of a running container in the Pod. If the Pod has no running containers — for example, it is CrashLoopBackOff, ImagePullBackOff, or Pending — there is no live process to connect to, and the command will hang waiting for a container to start or fail immediately. Even when a container is running, attach only forwards streams; it does not execute an arbitrary troubleshooting shell or add debugging tools to the Pod. Hence it cannot help when the container is absent or dead.

• ✓

  kubectl debug -it pod-name --image=busybox --target=container-name

  Why this is correct

  kubectl debug -it pod-name --image=busybox --target=container-name creates an ephemeral container inside the existing Pod's sandbox, so it shares the same network namespace, IPC namespace, and (when --target is specified) the target container's process namespace. The ephemeral container includes the provided busybox image, giving you a shell (via -it) and common debugging tools even though the original container lacks a shell or has crashed. Because ephemeral containers are managed by the kubelet, the original Pod's spec and lifecycle are unaffected, and if the Pod is not running, kubectl debug will create a copy, so this is the right tool when no containers are running. The --target flag is what lets you see the crashed container's processes, but for ordinary filesystem inspection the ephemeral container also mounts the Pod's volumes.

• ✗

  kubectl exec -it pod-name -- /bin/sh

  Why it's wrong here

  kubectl exec -it pod-name -- /bin/sh attempts to run a shell inside an existing container within the Pod, which requires that container to be running and healthy enough to accept a command. In a CrashLoopBackOff state the container exits before exec can connect, and in a Pending or ImagePullBackOff state no container has started, so kubectl exec returns an error such as 'cannot exec into a container in a completed/failed pod' or simply times out. Moreover, even if a container is running, it may not contain /bin/sh or the debugging utilities you need, and you cannot add tools without modifying the image. kubectl debug is specifically designed to overcome these limitations by adding a separate debug container.

Go deeper

Related to this question