CKS Monitoring, Logging and Runtime Security Practice Question
You are investigating a pod that may have been compromised. Which kubectl command allows you to run a shell inside the running container without overwriting the container's filesystem?
⚠ Common exam trap
The CKS exam often tests the distinction between `exec` (which runs inside the existing container) and `debug` (which creates a separate container), so the trap here is that candidates may choose `kubectl debug` thinking it provides a shell in the same container, but it actually creates a new container with its own filesystem, potentially overwriting evidence.
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 exec -it pod-name -- /bin/bash
`kubectl exec -it pod-name -- /bin/bash` attaches an interactive shell to the running container without modifying its filesystem. This command uses the container runtime's exec facility to spawn a new process inside the existing container, leaving the container's root filesystem unchanged. It is the standard method for runtime investigation without altering the container's state.
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 exec -it pod-name -- /bin/bash
Why this is correct
kubectl exec -it pod-name -- /bin/bash starts a new process inside the already-running container, sharing its mount namespace, PID namespace, and network stack. This gives you direct access to the live filesystem, running processes, and environment variables exactly as they exist in the compromised pod, enabling immediate forensic evidence collection. This is the standard method for interactive shell access to an existing container and is the correct approach for investigating a compromise.
- ✗
kubectl debug pod-name --image=busybox
Why it's wrong here
kubectl debug pod-name --image=busybox creates a temporary ephemeral container in the same pod, but this new container has its own isolated filesystem and does not share the process mount namespace of the original container. By default, you cannot directly inspect the original container's filesystem or running processes without additional steps like nsenter or copying files, and the busybox environment differs from the original runtime. Thus, while it is useful for network debugging or running recovery tools, it is not a direct way to investigate the specific state of the compromised container.
- ✗
kubectl run -it --image=busybox sh
Why it's wrong here
kubectl run -it --image=busybox sh launches an entirely new and independent pod, completely separate from the compromised pod's namespaces, network, filesystem, and process tree. This command is designed to run a one-off workload, not to enter an existing container, so it provides no visibility into the compromised pod's runtime state. You would be investigating a fresh container, which is irrelevant to the pod you are examining.
- ✗
kubectl attach pod-name
Why it's wrong here
kubectl attach pod-name connects your terminal to the container's primary process, typically the application's stdin, stdout, and stderr streams, but it does not spawn a new shell or allow you to execute arbitrary commands. If the primary process is a long-running service, attaching may only show its logs or allow you to send signals, and you cannot inspect the filesystem or run diagnostic binaries. This makes it unsuitable for forensic analysis of a compromised container where you need to run interactive commands.
Go deeper
Related to this question
About these practice questions
This CKS question is part of Courseiva's 845-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 CKS 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 CKS exam.