CKS Monitoring, Logging and Runtime Security Practice Question
Which TWO of the following are valid techniques to detect and respond to runtime incidents in a Kubernetes cluster? (Select TWO.)
⚠ Common exam trap
Candidates may think that deleting the pod is the best immediate response, but the exam expects knowledge of proper incident response steps that preserve evidence and contain the threat.
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
✓
Applying a NetworkPolicy to isolate a compromised pod
Option C is correct because applying a NetworkPolicy to a compromised pod lets you isolate it at the network layer — by selecting the pod with a label selector and defining ingress/egress rules (or an empty egress/ingress set) you cut off lateral movement and C2 traffic while keeping the pod alive for investigation, which is a standard containment step in runtime incident response. Option D is correct because kubectl exec into a running container allows you to collect volatile forensic evidence — running processes, open sockets, environment variables, and in-memory artifacts — that would be lost if the pod were deleted or restarted, making it a valid detection/response technique. Option A is not a valid detection technique: deleting the pod destroys evidence and, if the workload is managed by a ReplicaSet/Deployment, the controller immediately recreates it, so the attack resumes. Option B is not a runtime incident detection/response technique: crictl images only enumerates images cached on the node and provides no runtime behavioral insight. Option E is not correct here because kubectl logs --previous only retrieves logs from a previously terminated container instance and does not itself detect or respond to a live runtime incident.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Deleting the compromised pod immediately to stop the attack
Why it's wrong here
Deleting the compromised pod removes the container filesystem, process state, and network connections—the very evidence needed for forensic analysis. Kubernetes does not preserve pod state after deletion, so in-memory artifacts and runtime data are lost permanently. A proper incident response preserves evidence by snapshotting the container or using ephemeral containers for forensics before any termination, and uses NetworkPolicy for containment.
- ✗
Using crictl images to list container images on the node
Why it's wrong here
crictl images lists only the container images cached on the node's container runtime (e.g., containerd), not the currently running containers or their processes. For live incident response you need crictl ps to enumerate running containers, crictl inspect to examine configuration, or crictl logs to capture output. Image listing might show pull history but gives no indication of which containers are compromised or what processes are executing.
- ✓
Applying a NetworkPolicy to isolate a compromised pod
Why this is correct
A NetworkPolicy that selects the compromised pod and has no ingress or egress rules enforces a default-deny policy for that pod, immediately cutting off command-and-control and lateral movement. This is a nondestructive containment action that preserves the pod's filesystem and live state for subsequent forensic collection. Ensure your CNI plugin (e.g., Calico, Cilium) actually enforces the policy—otherwise the rule will be silently ignored.
- ✓
Using kubectl exec to gather forensic data from a running container
Why this is correct
kubectl exec runs a command directly inside the container's namespaces, allowing you to inspect running processes, open file descriptors, network sockets, and read sensitive files like /proc or /etc/hosts without stopping the workload. Use it to gather volatile evidence such as command-line arguments, environment variables, and active connections, which disappear once the container terminates. Be mindful that exec introduces new process activity, so use static binaries or collect highly volatile data first.
- ✗
Running kubectl logs --previous to view logs of a terminated container
Why it's wrong here
kubectl logs --previous retrieves the logs of the previous, already-terminated instance of a container, which is only useful after a crash or restart. In an active incident, the compromised pod is still running, so waiting for or forcing a restart to use this command destroys forensic evidence. Attackers also frequently clear or alter logs, and container stdout logs are ephemeral due to rotation; prefer live kubectl logs and runtime-level log retrieval for incident response.
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.