CKAD Application Observability and Maintenance Practice Question
You want to debug a pod that is failing to start. The pod does not have a shell installed. Which command can you use to attach an ephemeral debug container to the running (or failed) pod?
⚠ Common exam trap
Many candidates choose `kubectl exec` or `kubectl attach` out of habit, not realizing those commands require a running container with a shell, whereas `kubectl debug` is the only option that can inject a new container into a pod that lacks debugging tools or is in a failed state.
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 -it <pod> --image=busybox --target=<container>
`kubectl debug` allows you to attach an ephemeral debug container to a running or failed pod, even if the pod lacks a shell. The `--target` parameter specifies the container in the pod to which the debug container attaches, enabling network namespace sharing and process inspection without modifying the original 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 attach <pod>
Why it's wrong here
kubectl attach <pod> streams stdin/stdout/stderr to the container's main process, but it does not launch a shell or any new process. If the pod is in CrashLoopBackOff or the main process already exited, attach cannot work because there is no running process to attach to. This command is for interacting with a live, running application, not for diagnosing why a container is failing to start.
- ✗
kubectl exec -it <pod> -- /bin/sh
Why it's wrong here
kubectl exec -it <pod> -- /bin/sh attempts to run a shell inside an existing container, but this requires the container to be running and to have /bin/sh available in its filesystem. When the pod is failing to start, the container is often not in a ready/running state, and exec will then fail with an error like 'cannot exec into a container that is not running'. Even if the container were running, many minimal or distroless images do not include /bin/sh, making this approach unreliable.
- ✗
kubectl run debug --image=busybox -it --restart=Never
Why it's wrong here
kubectl run debug --image=busybox -it --restart=Never creates a completely separate, standalone pod rather than adding a container to the failing pod. This debug pod has its own IP, filesystem, and process namespace, so it cannot inspect the target pod's filesystem, environment variables, or processes. It is not attached to the failing pod's network namespace or volumes, so it provides no direct visibility into why the original container is failing.
- ✓
kubectl debug -it <pod> --image=busybox --target=<container>
Why this is correct
kubectl debug -it <pod> --image=busybox --target=<container> creates an ephemeral container inside the existing pod, sharing its network, volumes, and (if enabled) process namespace. The --target flag names the container whose namespaces the debug container will share, letting you inspect the failing container's filesystem and processes even while it is crashing. Because ephemeral containers do not restart or affect the original container's lifecycle, this is the correct way to inject a debugging tool into the pod without modifying the pod spec.
Go deeper
Related to this question
About these practice questions
Courseiva writes every CKAD question from scratch — 160 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or 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.