CKAD Application Design and Build Practice Question
You need to debug a pod that has no running container because it crashed. The pod is in CrashLoopBackOff. Which command allows you to start a temporary container in the same pod for debugging?
⚠ Common exam trap
Candidates often assume `kubectl exec` can debug any pod, but it requires a running container, whereas `kubectl debug` is the correct tool for pods in CrashLoopBackOff.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
kubectl debug <pod> -it --image=busybox
`kubectl debug` can create an ephemeral container in an existing pod for debugging purposes, even when the original container is in CrashLoopBackOff. The `-it` flag provides an interactive terminal, and `--image=busybox` supplies a lightweight debugging image. This allows you to inspect the pod's filesystem, network, or environment without restarting the failing container.
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 debug <pod> -it --image=busybox
Why this is correct
kubectl debug with an explicit image creates an ephemeral container that is injected directly into the existing Pod, even when its primary container is not running. This ephemeral container shares the Pod’s network, storage, and optionally its process namespace, letting you inspect crashed processes or mounted volumes from inside the Pod context. The interactive -it session gives you a shell without ever needing the original container to be alive, which is precisely why it succeeds where exec, attach, or a separate run would fail.
- ✗
kubectl attach <pod>
Why it's wrong here
kubectl attach connects to the main process's stdin, stdout, and stderr inside a container that is actively running. If no container in the Pod is running, there is no process or TTY to attach to, so the command immediately fails. It does not spawn any new container or process; it only mirrors the already-running process's I/O streams. Since the target Pod lacks a running container, attaching cannot provide any debugging capability.
- ✗
kubectl run debug --image=busybox
Why it's wrong here
kubectl run debug creates an entirely new and independent Pod object within the cluster, using the busybox image. This new Pod is completely isolated from the original broken Pod, with its own IP, volumes, and lifecycle; it does not inherit the original's environment or crashes. To debug the original, you would have to manually replicate its configuration and state, which is not equivalent to inspecting the actual failing Pod. Thus, while it may give you a shell, it does not debug the Pod named in the command.
- ✗
kubectl exec -it <pod> -- /bin/bash
Why it's wrong here
kubectl exec requires a Pod to have at least one currently running container in which to execute the specified command. It attaches directly to the container's process namespace and filesystem, so with no running container the API server returns an error such as 'cannot exec into a stopped container'. Exec cannot create a new container; it operates only inside an existing, alive container. Since the Pod has no running container, this option is not viable for gaining a debugging shell.
Go deeper
Related to this question
About these practice questions
This CKAD question is part of Courseiva's 826-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CKAD practice question is part of Courseiva's free CNCF certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CKAD exam.