CKAD Application Observability and Maintenance Practice Question
Which THREE of the following are valid ways to debug a pod that is not responding? (Select three.)
⚠ Common exam trap
The CKAD exam often tests the distinction between `kubectl attach` (which connects to the main process) and `kubectl exec` (which spawns a new process), leading candidates to mistakenly think attach is useful for interactive debugging when the container is unresponsive.
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
✓
Run 'kubectl debug -it pod-name --image=busybox --target=container-name' to start an ephemeral debug container
`kubectl debug` with `--target=container-name` creates an ephemeral container in the same pod, sharing the network and process namespace (if supported) with the target container. This allows you to run debugging tools (e.g., `busybox`) without modifying the original container image, which is essential when the container lacks a shell or necessary utilities.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Run 'kubectl debug -it pod-name --image=busybox --target=container-name' to start an ephemeral debug container
Why this is correct
kubectl debug creates an ephemeral container inside the running pod, injecting a fresh image (busybox) without restarting or altering the original containers; --target ties the new container's process namespace to the specified application container so you can inspect and signal real processes. This is ideal when the app image lacks a shell, a debugger, or curl, and it leaves the pod's original spec untouched, making it a non-invasive yet powerful debugging approach.
- ✓
Run 'kubectl exec -it pod-name -- /bin/bash' to interact with the container
Why this is correct
kubectl exec runs a specific binary, like /bin/bash, directly inside the target container's existing filesystem and network namespace, letting you interactively explore the actual environment and run commands with the app's runtime tools. It is quick and effective when the container already has a shell, but it fails if the image is minimal (scratch) or if bash is not installed, and it does not add any new debugging utilities.
- ✓
Run 'kubectl logs pod-name --tail=50' to view recent log output
Why this is correct
kubectl logs with --tail=50 captures the last 50 lines of the container's stdout/stderr, giving you immediate insight into recent application errors, stack traces, or startup failures without requiring a shell or process interaction. It is read-only, non-invasive, and works even if the container is crash-looping, but it only shows whatever the app explicitly writes to standard output and cannot display in-memory state or environment variables.
- ✗
Run 'kubectl attach pod-name' to attach to the container's main process
Why it's wrong here
kubectl attach connects your terminal to the pid 1 process's stdin/stdout, not a new shell, so unless the main process is an interactive program like a bash script or a REPL, it will hang or do nothing; most production containers run servers like nginx that do not read from stdin, making this command ineffective for debugging. It also carries risk of sending unintended input to the running application, and unlike exec it does not let you run arbitrary troubleshooting commands.
- ✗
Run 'kubectl get pod pod-name -o yaml' to examine the pod's current YAML definition
Why it's wrong here
kubectl get pod -o yaml returns the pod's desired spec and the current status subresource (including conditions, IP, and container states), but it is purely a declarative snapshot; it cannot show log output, running processes, or inside-container activity. While useful to verify whether containers are ready or check restart counts, it does not give you an interactive debugging channel or a way to issue commands, so it is not a valid debugging technique on its own.
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.