CKS Monitoring, Logging and Runtime Security Practice Question
Which THREE of the following are recommended steps during incident response for a compromised pod? (Choose three.)
⚠ Common exam trap
CKS often tests the tension between containment and evidence preservation — candidates are tempted by 'restart the pod' or 'delete the namespace' as quick fixes, but these destroy forensic evidence and violate incident response best practices.
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 for analysis
Option A is correct because capturing a memory dump of the container preserves volatile evidence such as running processes, injected code, and in-memory credentials before the pod is terminated or restarted. Option C is correct because kubectl logs retrieves container stdout/stderr history and kubectl exec allows live inspection of the filesystem, processes, and network state for forensic collection. Option D is correct because applying a NetworkPolicy that denies egress traffic contains the compromised pod, preventing data exfiltration or command-and-control communication while investigation continues. Option B is not recommended because deleting the entire namespace destroys evidence and may disrupt unrelated workloads. Option E is not recommended because restarting the pod immediately destroys volatile memory and runtime artifacts needed for root-cause analysis.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Take a memory dump of the container for analysis
Why this is correct
Taking a memory dump preserves volatile artifacts—such as running processes, network socket states, environment variables, and injected attack code—that disappear permanently when the container stops. Capturing this snapshot before any other forensic or remediation action allows investigators to run offline analysis against the exact memory image, potentially revealing the initial exploit and any in-memory resident payloads. Using tooling like `docker exec` with `/proc` access or dedicated memory capture utilities ensures the live state is frozen without altering the container.
- ✗
Delete the entire namespace containing the pod
Why it's wrong here
Deleting an entire namespace cascade-deletes every Pod, Service, ConfigMap, Secret, and NetworkPolicy in it, which destroys the compromised container's filesystem, its logs, and any running process state along with all evidence. This action also disrupts unrelated applications that share the namespace, creating unnecessary availability incidents and potentially taking down monitoring or service mesh components that are co-tenanted. The correct isolation step is to target only the suspicious pod with a NetworkPolicy or cordon the node, preserving evidence and sibling workloads.
- ✓
Use kubectl logs and kubectl exec to collect forensic data
Why this is correct
Retrieving container logs via `kubectl logs` (including `--previous` for terminated containers) and inspecting live runtime state through `kubectl exec` captures the attacker's command history, configuration mutations, and running processes without stopping the pod. These commands let you read files like `/etc/passwd`, process environment variables, and `/proc/<pid>/fd` to understand how the container was exploited. While invoking commands inside the container can modify evidence, when performed after a memory dump it is an accepted and essential step for gathering host-level and cluster-level forensic indicators.
- ✓
Apply a NetworkPolicy to deny egress traffic from the pod
Why this is correct
Applying a Kubernetes NetworkPolicy with a pod selector and an empty `egress` list creates a deny-all rule that blocks the compromised container from initiating any outbound connections, cutting off command-and-control traffic and impeding lateral movement. This containment measure is reversible, configuration-only, and does not terminate the container or delete its data, so the running processes and filesystem remain pristine for later analysis. It is the standard Kubernetes-native approach to isolating a hostile workload, provided the cluster's CNI enforces NetworkPolicy.
- ✗
Immediately restart the pod to stop the attack
Why it's wrong here
Restarting the pod (e.g., via `kubectl delete` or rolling restart) destroys all volatile evidence—the container's memory, open file descriptors, temporary files, and unique process identifiers—so incident responders lose the exact running state and any active malicious payloads. A restart also clears the container's writable layer and may replace it with a pristine image, meaning the attack artifact that existed only in the live container can never be recovered. The proper first response is to capture a memory dump and log snapshot before considering any form of restart or remediation.
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 and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official CNCF exam blueprint
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.