CKAD Application Design and Build Practice Question
You need to debug a running pod that does not have a shell installed. Which kubectl command allows you to start an ephemeral container with a shell?
⚠ Common exam trap
Test-takers frequently confuse `kubectl exec` (which requires a shell in the existing container) with `kubectl debug` (which adds a new container with a shell), or mistakenly think `kubectl run` or `kubectl create pod` can attach to an existing pod's context.
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> --image=busybox --stdin --tty
`kubectl debug` is specifically designed to add an ephemeral container to a running pod for troubleshooting purposes, even when the original container lacks a shell. The `--image=busybox` flag provides a lightweight image with common debugging tools, and `--stdin --tty` allocates an interactive terminal, allowing you to run commands like `/bin/sh` inside the ephemeral container without modifying the original pod's containers.
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 create pod debug --image=busybox --attach
Why it's wrong here
kubectl create pod is not a valid subcommand for launching containers; pods are created from manifests or via kubectl run. It is tempting because it appears to create a debugging pod, and would be correct if the intent were declaring a new pod through a YAML manifest.
- ✗
kubectl exec -it <pod> -- /bin/sh
Why it's wrong here
kubectl exec runs a command inside an existing container, which fails when no shell binary is present in that image. It is tempting because exec is the standard interactive debugging route, and would be correct for pods whose image already includes /bin/sh.
- ✓
kubectl debug <pod> --image=busybox --stdin --tty
Why this is correct
The debug subcommand injects an ephemeral container into the existing pod's namespaces, using the busybox image to supply a shell. This works when the original container lacks a shell, satisfying the debugging requirement without restarting the pod.
- ✗
kubectl run debug --image=busybox --attach
Why it's wrong here
kubectl run creates a new standalone pod rather than attaching an ephemeral container to the existing pod, so it cannot inspect that pod's filesystem or processes. It is tempting because it does launch a shell-bearing container, and would be correct for running an unrelated throwaway diagnostic workload.
Go deeper
Related to this question
About these practice questions
One of 826 original CKAD practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.