CKAD Application Design and Build Practice Question
You need to debug a pod that is running but not serving traffic. You want to add a temporary container with networking tools to the pod. Which command should you use?
⚠ Common exam trap
Candidates often confuse `kubectl exec` (which runs a command in an existing container) with `kubectl debug` (which adds a new container), and they forget that `kubectl exec` requires the target container to have the necessary tools installed, which is often not the case in production images.
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 mypod --image=busybox -it
`kubectl debug` allows you to add an ephemeral container (a temporary container with networking tools) to an existing running pod without restarting it. This is the only command that directly injects a new container into the pod's network namespace, enabling debugging of network issues while the original container continues running.
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 -- /bin/sh
Why it's wrong here
kubectl run debug --image=busybox -it --restart=Never -- /bin/sh launches a completely separate, standalone pod in its own network namespace. Because it does not share the original pod's network stack or IP, it cannot access the pod's localhost, loopback, or service endpoints; it would have to target the pod's cluster IP, which may not be routable from within its own namespace. This makes it useless for diagnosing connectivity issues specific to the failing pod's internal networking and is not an ephemeral container.
- ✗
kubectl attach mypod
Why it's wrong here
kubectl attach mypod attaches your terminal to the main process's stdin/stdout in the existing container. It does not create a new container or a debugging shell; it simply forwards I/O to the running entrypoint. If that process isn't an interactive shell or lacks network diagnostics, you gain no troubleshooting capability, and any Ctrl-C you send might terminate the application.
- ✗
kubectl exec -it mypod -- /bin/sh
Why it's wrong here
kubectl exec -it mypod -- /bin/sh runs a shell inside the existing application container, which can be risky and limited. The container image may be minimal or distroless with no shell or networking utilities (e.g., curl, ip) installed, so the command often fails or leaves you with little to work with. Moreover, any inspection happens inside the same container whose environment you are trying to debug, potentially altering its state or using resources meant for the app.
- ✓
kubectl debug mypod --image=busybox -it
Why this is correct
kubectl debug mypod --image=busybox -it adds an ephemeral container to the same pod, sharing the pod's network namespace, filesystem mounts, and IPC. This gives you a fresh multitool environment (busybox) without disturbing the original container, ideal for inspecting network endpoints, DNS, or routing from the pod's point of view. It is the standard, non-invasive way to debug a running pod that is not serving traffic as expected.
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.