CKS Monitoring, Logging and Runtime Security Practice Question
Which TWO of the following are valid steps to respond to a runtime security incident where a container is suspected to be compromised? (Select two.)
⚠ Common exam trap
The exam often tests the misconception that immediate deletion or node-level actions (like tainting or restarting kubelet) are appropriate first-response steps, when in fact the priority is containment and evidence preservation using network isolation and logging.
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
✓
Apply a NetworkPolicy that denies all ingress and egress to the pod
Applying a NetworkPolicy that denies all ingress and egress to the compromised pod immediately isolates it, preventing lateral movement and data exfiltration while preserving the pod for forensic analysis. This aligns with the incident response principle of containment before eradication, and Kubernetes NetworkPolicy uses label selectors and pod selectors to enforce eBPF/iptables-based rules at the CNI layer.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Apply a NetworkPolicy that denies all ingress and egress to the pod
Why this is correct
Applying a NetworkPolicy that denies all ingress and egress to the pod is a correct first step because it achieves network-level containment without destroying the running container or its filesystem. This isolation prevents the attacker from communicating with the pod or using it as a pivot, while preserving the pod's memory, disk, and process state for forensic analysis. Unlike deletion or eviction, this action is reversible and does not trigger rescheduling, keeping the compromised pod in a known, quarantined state for further investigation.
- ✗
Immediately delete the pod to stop the attack
Why it's wrong here
Immediately deleting the pod is an incorrect response because it destroys the container's writable layer, including any malware binaries, attacker-modified files, and ephemeral process data, which may be the only evidence of the compromise. In addition, if the pod is managed by a controller like a Deployment, Kubernetes will immediately create a replacement pod, potentially allowing the attacker to reinfect or continue their activity. Proper incident response prioritizes evidence preservation and containing the blast radius before any destructive action is taken.
- ✗
Add a taint to the node to evict the pod
Why it's wrong here
Adding a taint to the node to evict the pod is an incorrect response because taints are designed for scheduling control and node maintenance, not for targeted incident isolation. Applying a taint such as 'CriticalAddonsOnly' or a custom taint evicts all pods on that node that lack the corresponding toleration, causing widespread application disruption unrelated to the compromised workload. Worse, eviction does not guarantee that the attacker's process is stopped—the pod may restart on another node, allowing the compromise to spread while also losing any forensic evidence that would have been preserved by running the container's logs or memory dump first.
- ✓
Use kubectl logs to capture container logs before taking action
Why this is correct
Using kubectl logs to capture container logs before taking any action is a correct first step because it preserves the standard output and error streams from the running container, which are often vital for understanding the attack vector and attacker commands. This command is non-destructive and can be executed quickly, even while the pod remains running, allowing you to save evidence to a local file for later analysis. However, it is important to note that kubectl logs only captures stdout/stderr, so it should be complemented with other forensic steps like collecting filesystem snapshots or memory dumps before any containment action.
- ✗
Restart the kubelet on the node
Why it's wrong here
Restarting the kubelet on the node is an incorrect response because the kubelet is the node-level agent that manages all pods, and restarting it will disrupt every workload on that node, not just the compromised pod. Furthermore, a kubelet restart typically does not terminate the container processes themselves—it may just cause the kubelet to reconnect to existing containers, meaning the attacker's process could remain alive and uncontained. This action also provides no forensic value, destroys transient evidence in the kubelet's own logs, and unnecessarily wastes time and resources that should instead be spent on isolating the specific pod and collecting logs.
Go deeper
Related to this question
About these practice questions
Courseiva writes every CKS question from scratch — 845 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or 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 THREE of the following are recommended incident response steps when a container is compromised?
hard- A.Ignore the incident and monitor for further activity
- ✓ B.Copy the container's filesystem using kubectl cp for offline analysis
- ✓ C.Capture the container logs using kubectl logs
- ✓ D.Apply a NetworkPolicy to isolate the pod
- E.Immediately terminate the pod to contain the threat
Why B: Option B is correct because copying the container's filesystem with kubectl cp preserves volatile evidence for offline forensic analysis before the container is destroyed or restarted. Option C is correct because kubectl logs captures the container's stdout/stderr output, which may contain indicators of compromise, attacker commands, or error traces useful for scoping the incident. Option D is correct because applying a NetworkPolicy to the pod isolates it from other workloads, limiting lateral movement and exfiltration while still keeping the container alive for investigation. Option A is wrong because ignoring a compromise allows the attacker to persist and expand access. Option E is wrong because immediately terminating the pod destroys volatile evidence such as memory, running processes, and network connections, and may trigger automated redeployment that erases the compromised instance before it can be examined.
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.