CKS Monitoring, Logging and Runtime Security Practice Question
Which THREE of the following are effective methods to preserve evidence during a container security incident?
⚠ Common exam trap
A common trap is confusing incident response containment (which may require isolating the pod via network policies or cordoning the node) with evidence preservation (which requires capturing data before deletion). Immediate pod deletion destroys evidence and should be avoided until forensic data is collected.
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
✓
Take a memory dump of the container
Taking a memory dump of the container captures volatile data (processes, network connections, encryption keys) that is lost when the container stops. This preserves runtime evidence critical for forensic analysis, as memory artifacts are not persisted to disk and must be collected before the container is terminated.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Delete the pod immediately
Why it's wrong here
Deleting the pod immediately via `kubectl delete pod` terminates the container and removes its writable layer, along with the container ID and cgroup configuration. This wipes out the container's filesystem, process state, and any forensic artifacts such as attacker-modified binaries, temporary files, or deleted-file remnants that might still be open by processes. In incident response, destroying the evidence before capturing it is irreversible; you lose the only chance to inspect the compromised state.
- ✓
Take a memory dump of the container
Why this is correct
Taking a memory dump preserves the ephemeral volatile data that exists only inside the running container's user-space processes and its shared host kernel view. Tools like `gcore` on the container PID, or CRIU-based dump, capture open file descriptors, decrypted secrets, injected shellcode, and active network socket states that vanish when the container stops. This is critical for detecting in-memory-only attacks (e.g., process hollowing) that leave no disk footprint, and it should be performed before the container is terminated or filesystem is altered.
- ✗
Run kubectl exec to explore and modify files
Why it's wrong here
Running `kubectl exec` to explore or modify files is dangerous because the exec process itself write-accesses the container's namespaces and filesystem. Even simple commands like `ls` change access times, and any `touch`, `cat > file`, or installation of a debugging tool updates ctime/mtime or overwrites potential evidence. Moreover, spawning additional processes could trigger malicious triggers already planted in the container, altering the kernel memory state. The correct approach is to use forensically sound methods like reading `/proc` or a memory dump, without causing side effects.
- ✓
Create a forensic snapshot of the container filesystem
Why this is correct
Creating a forensic snapshot of the container filesystem, for example by copying the container's overlayfs upper layer and relevant lower layers, captures the persistent disk state including attacker-created scripts, modified configs, and deleted-but-open files that are still linked. This is equivalent to a hard drive image for the container, providing a source of truth to analyze offline without further contaminating the live environment. It allows incident responders to perform static analysis, virus scanning, and timeline reconstruction on an immutable copy.
- ✓
Capture container logs
Why this is correct
Capturing container logs—via `kubectl logs` or by reading the JSON-file log under `/var/log/containers/`—preserves the chronological stdout/stderr records that document application and network activity. Logs reveal attacker commands echoed, reverse-shell payloads, privilege escalation attempts, and unauthorized data transfers, and they are collected non-invasively without touching the container's process memory or filesystem. However, logs may be truncated if the container is killed or rotated, so this capture must happen early, but after memory and filesystem images if those need live state.
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.