CKAD Application Design and Build Practice Question
You want to debug a running pod by starting a temporary container that has network access to the pod's containers. Which kubectl command should you use?
⚠ Common exam trap
Many exam-takers confuse `kubectl exec` (which runs inside an existing container) with `kubectl debug` (which creates a new, separate container in the same pod), and fail to recognize that `exec` cannot add a different image or provide network isolation from the target container's process environment.
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=debian --target=<container>
`kubectl debug` creates an ephemeral container in the same pod, sharing the pod's network namespace (including localhost and the same IP address) with the target container. The `--target` flag specifies which existing container's namespaces (network, PID, etc.) the ephemeral container should join, enabling direct network debugging of that container without modifying its process.
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 -it <pod> --image=debian --target=<container>
Why this is correct
kubectl debug -it <pod> --image=debian --target=<container> creates an ephemeral container in the same pod, sharing the pod's network and storage volumes, and uses --target to attach to the process namespace of the specified existing container. This injects a fresh Debian image with debugging tools directly into the running pod's context without restarting the workload or modifying its spec.
- ✗
kubectl attach <pod>
Why it's wrong here
kubectl attach connects your terminal to the stdin/stdout/stderr of an already-running container's main process; it does not spawn any new process or introduce a debug image. If the main process is not interactive or lacks a shell, attach gives you no way to run diagnostic commands, inspect filesystem internals, or install utilities.
- ✗
kubectl run debug --image=debian --restart=Never
Why it's wrong here
kubectl run debug --image=debian --restart=Never starts a completely separate Pod with its own network and process namespaces, isolated from the target pod. It cannot inspect the target pod's network interfaces, processes, environment variables, or mount paths, so debugging the original workload is impossible from this standalone Pod.
- ✗
kubectl exec -it <pod> -- /bin/bash
Why it's wrong here
kubectl exec -it <pod> -- /bin/bash runs a command inside an existing container's filesystem and namespaces, so it relies entirely on tools already present in that image; a minimal or distroless container will simply fail because /bin/bash does not exist. It does not pull a new Debian image or create an ephemeral container, and any state changes are made directly to the running container rather than to an isolated debugging sidecar.
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.