CKS Monitoring, Logging and Runtime Security Practice Question
Which kubectl command can be used to exec into a running container for forensic analysis during an incident response?
⚠ Common exam trap
Watch out — candidates often confuse `kubectl exec` with `kubectl attach` or `kubectl run`, mistakenly thinking attach provides a shell or that run can target an existing container, when in fact only exec gives interactive command execution inside a running container for forensic purposes.
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> -- /bin/sh
`kubectl exec -it <pod> -- /bin/sh` allows you to start an interactive shell session inside a running container, which is essential for live forensic analysis during incident response. This command uses the Kubernetes API to execute a process (e.g., /bin/sh) in the container's namespaces, enabling you to inspect running processes, file systems, network connections, and memory artifacts without stopping the container.
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> -- /bin/sh
Why this is correct
kubectl exec -it <pod> -- /bin/sh launches a new /bin/sh process inside the container's namespaces via the kubelet and container runtime. The -i flag keeps STDIN open, -t allocates a pseudo-TTY, and the command after -- is executed directly as a new process in the container. This is the canonical way to get an interactive shell in a running pod's primary container for debugging.
- ✗
kubectl run --stdin --tty --image=busybox
Why it's wrong here
kubectl run --stdin --tty --image=busybox creates a new pod from the busybox image rather than interacting with an existing pod. It lacks a name argument (e.g., kubectl run shell --image=busybox), and even when complete, it only schedules a fresh pod with no relation to the running container you want to access. This command is for launching workloads, not for entering an existing container's process namespace.
- ✗
kubectl logs <pod>
Why it's wrong here
kubectl logs <pod> streams the captured stdout/stderr from the container's logging pipeline; it is a one-way, read-only operation. It provides no stdin channel and cannot execute any command inside the container. Even with -f (follow), you only observe ongoing log lines, which never gives you a shell or an interactive terminal session for debugging.
- ✗
kubectl attach <pod>
Why it's wrong here
kubectl attach <pod> connects the local terminal to the already-running primary container process (PID 1) and its standard streams, but it does not create a new process such as /bin/sh. If the main process (e.g., a web server) does not read from stdin or respond to TTY input, the session appears hung and useless. Attach can only interact with whatever the existing process does with its stdio; it cannot run arbitrary 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 →
Same concept, more angles
1 more way this is tested on CKS
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. Which kubectl command can be used to execute a shell inside a running container for forensic analysis?
easy- A.kubectl delete pod <pod>
- B.kubectl logs <pod>
- C.kubectl describe pod <pod>
- ✓ D.kubectl exec -it <pod> -- /bin/sh
Why D: The `kubectl exec -it <pod> -- /bin/sh` command opens an interactive TTY (`-it`) into a running container and launches a shell (`/bin/sh`), which is exactly what's needed for live forensic analysis inside a compromised or suspect container. It does not restart or alter the pod, preserving volatile evidence like running processes, open file descriptors, and in-memory artifacts. This is the standard CKS-recommended approach for container-level incident response.
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.