CKS Monitoring, Logging and Runtime Security Practice Question
You are investigating a pod suspected of being compromised. Which set of commands would provide the most useful forensic evidence without altering the container's state?
⚠ Common exam trap
A common trap is assuming `kubectl cp` is non-invasive because it copies files. In reality, `kubectl cp` uses `kubectl exec` to run `tar` inside the container, which changes the container's state. Any command executed via `kubectl exec`—including those under the hood of `kubectl cp`—is disallowed when the requirement is to preserve the container's state. Non-invasive options are limited to read-only API calls like `kubectl logs` and `kubectl describe`.
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 logs <pod> && kubectl describe pod <pod>
Option A is the only set of commands that does not execute anything inside the container. `kubectl logs` and `kubectl describe pod` read information from the API server and kubelet without interfering with the container's runtime state. Options B, C, and D all involve `kubectl exec` (or `kubectl cp`, which uses `kubectl exec` to run tar inside the container), creating new processes and potentially modifying atime or other state, violating the forensic principle of non-interference.
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 logs <pod> && kubectl describe pod <pod>
Why this is correct
Running `kubectl logs <pod>` and `kubectl describe pod <pod>` only retrieves the current container's stdout/stderr logs and pod metadata from the API server. These commands do not access the container's filesystem, process state, or previous terminated container instances, so critical forensic artifacts like binary payloads, configuration changes, or crash evidence remain hidden. Furthermore, they capture live data that can change during investigation, making them unsuitable for preserving a reliable evidentiary snapshot.
- ✗
kubectl cp <pod>:/ -c <container> /tmp/forensic && kubectl logs <pod> --previous
Why it's wrong here
The correct approach is to use `kubectl cp` to copy the entire container filesystem to a local directory, which creates a static, bit-for-bit snapshot without injecting processes or altering the container's runtime state. Specifying `-c <container>` is mandatory for multi-container pods to target the exact compromised container. Adding `kubectl logs <pod> --previous` retrieves logs from the previously terminated container instance, which may hold the attacker's commands or crash output that the current instance no longer contains. This combination preserves both disk state and historical log evidence for offline analysis.
- ✗
kubectl exec <pod> -- cat /proc/1/cmdline && kubectl exec <pod> -- ls -la /
Why it's wrong here
Executing `cat /proc/1/cmdline` and `ls -la /` via `kubectl exec` spawns new processes inside the running container, which changes its process table, updates access times, and may trigger the attacker's monitoring or anti-forensic defenses. This live interaction contaminates the scene and violates forensic best practices, as even read-only commands can alter the system state at the OS level. The output also depends on the container's available binaries and does not capture deleted files, open file descriptors, or memory contents, making it a shallow and unreliable source of evidence.
- ✗
kubectl exec -it <pod> -- bash && kubectl exec <pod> -- cat /var/log/syslog
Why it's wrong here
Launching an interactive shell with `kubectl exec -it <pod> -- bash` is especially intrusive because it creates a persistent process, writes shell history, allocates a pseudo-TTY, and modifies the container's runtime environment in ways that can destroy volatile evidence. Following this with another `kubectl exec` to read `/var/log/syslog` adds yet another process and may overwrite important log entries due to normal system activity. In a compromised container, executing a shell could also trigger malicious behaviors or give the attacker interactive access, so this approach is both forensically unsound and operationally dangerous.
Go deeper
Related to this question
About these practice questions
One of 845 original CKS 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 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.