CKS Monitoring, Logging and Runtime Security Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Ignore the incident and monitor for further activity

  Why it's wrong here

  Ignoring the incident and merely monitoring for further activity is a passive stance that fails to contain the compromise. It allows the attacker to continue operating, potentially moving laterally, exfiltrating data, or escalating privileges, thereby increasing the damage. Incident response best practices require immediate containment, not observation, and without isolation the malicious workload stays active in your cluster. Even with monitoring, the risk of further harm remains unmitigated, so this is not a recommended response.

• ✓

  Copy the container's filesystem using kubectl cp for offline analysis

  Why this is correct

  Using `kubectl cp` to copy the container’s filesystem is a forensically sound step because it preserves the writable layer, arbitrary files, and binaries without altering the running state. This offline copy lets you analyze the image, look for persistence mechanisms (e.g., cron jobs, backdoors), and inspect configuration files while the container remains responsive. Because `kubectl cp` reads the live filesystem, it is non-destructive and is a best practice before any termination decision. It also gives you a baseline for detecting changes if you later compare with the original image.

• ✓

  Capture the container logs using kubectl logs

  Why this is correct

  Capturing logs with `kubectl logs` is a critical early step because container logs contain stdout/stderr that often reveal the attack vector, such as unexpected reverse shells, credential access, or suspicious commands. Use flags like `--previous` to retrieve logs from a crashed instance and `--timestamps` to preserve temporal context, redirecting output to a file for analysis. Logs may be lost if the pod is deleted or restarted, so this action should be taken immediately after discovery. These logs complement filesystem evidence and help reconstruct the timeline of the compromise.

• ✓

  Apply a NetworkPolicy to isolate the pod

  Why this is correct

  Applying a NetworkPolicy to isolate the pod is a smart containment measure because it restricts both ingress and egress traffic to/from the compromised pod, cutting off command-and-control channels or lateral movement without stopping the process. This preserves all volatile memory, file descriptors, and running artifacts for later forensic collection while reducing the blast radius. Choose a policy that denies all traffic to/from the pod, optionally allowing a trusted admin namespace for investigation. Even if your CNI does not support NetworkPolicy enforcement, other mechanisms like port-forward restrictions or firewall rules can achieve a similar isolation.

• ✗

  Immediately terminate the pod to contain the threat

  Why it's wrong here

  Immediately terminating the pod is wrong because it destroys the very evidence you need to analyze the compromise. The container’s writable layer is deleted, in-memory processes are killed, and any open file handles or network connections vanish, making incident analysis impossible. Moreover, if the pod is managed by a controller such as a Deployment or StatefulSet, termination may trigger automatic recreation, potentially spawning a new instance of the compromised workload or hiding the attack entirely. The proper sequence is to first collect logs and a filesystem snapshot, then isolate via NetworkPolicy, and only later decide if deletion is necessary.

Go deeper

Related to this question