CKAD Application Design and Build Practice Question
Which command attaches an ephemeral container to a running pod for debugging?
⚠ Common exam trap
A common mix-up: candidates confuse `kubectl exec` (which runs in an existing container) with `kubectl debug` (which creates a new ephemeral container), especially when the pod's container is unhealthy or lacks a shell, making `kubectl exec` impossible.
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 mypod --image=busybox --target=mycontainer
`kubectl debug` with `-it` and `--image=busybox` creates an ephemeral container in the target pod for interactive debugging, while `--target=mycontainer` attaches the ephemeral container to the same network and process namespace as the specified container. This is the only command that adds a new, temporary container to a running pod without restarting it, which is essential when the existing container lacks debugging tools or is in a crash loop.
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 mypod
Why it's wrong here
The kubectl attach command connects to the stdin/stdout/stderr of an already running container process, not to an ephemeral container. Ephemeral containers are created on the fly for debugging, whereas attach simply piggybacks onto an existing container's standard streams. This command neither creates a new container nor targets a specific container for debugging, so it fails to satisfy the requirement.
- ✗
kubectl exec -it mypod -- sh
Why it's wrong here
kubectl exec -it mypod -- sh launches a shell inside an existing container in the pod, defaulting to the first container unless a -c flag is given. It runs the command in the process namespace and filesystem of that already-running container, not in a separate ephemeral debug container. Unlike ephemeral containers, exec does not add a new container to the pod's spec; it only runs a one-off process inside a container that is already part of the pod.
- ✗
kubectl logs mypod -c mycontainer
Why it's wrong here
The kubectl logs command retrieves the captured stdout/stderr output from a specific container (here mycontainer) and is purely a read-only diagnostic operation. It does not initiate any interactive session or create an ephemeral container; it simply streams historical or current logs to the terminal. The --target flag is not relevant to logs, and there is no mechanism in this command to attach a debugging container to a running pod.
- ✓
kubectl debug -it mypod --image=busybox --target=mycontainer
Why this is correct
kubectl debug -it mypod --image=busybox --target=mycontainer creates a new ephemeral container in the pod, attaches it interactively, and joins it to the process namespace of the target container mycontainer. The --target flag makes the ephemeral container see the same processes as mycontainer, enabling low-level debugging with tools like strace or tcpdump. The -it flags allocate a TTY and keep stdin open, while --image=busybox provides the debugging environment, all without restarting the pod.
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.