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.

• ✗

  Delete the pod immediately

  Why it's wrong here

  Deleting the pod immediately triggers the kubelet to forcibly terminate the container and remove its writable layer, which may contain the attacker's binaries, modified configurations, and transient files. This is equivalent to destroying the crime scene before evidence is collected; even if logs are aggregated elsewhere, the container's filesystem is lost forever. Forensic best practice demands preserving the running container, not deleting it.

• ✓

  Take a snapshot of the container's filesystem

  Why this is correct

  Taking a snapshot of the container's filesystem captures the exact writable layer and all runtime changes, including planted malware, persistence mechanisms, and attacker-modified system files. Use `docker commit` or `crictl` to export the live container state into an immutable image that can be analyzed offline without altering the original evidence. This is forensically sound and should be the first priority before any containment or cleanup action.

• ✗

  Apply a NetworkPolicy to allow all traffic

  Why it's wrong here

  Applying a NetworkPolicy that allows all traffic is effectively the default open policy, giving the attacker continued ability to communicate with command-and-control or exfiltrate sensitive data. For containment, you should instead apply a deny-all NetworkPolicy to isolate the pod, which also preserves volatile evidence by preventing the attacker from performing further destructive actions. Allowing traffic actively undermines incident response and may let the attacker wipe or overwrite evidence.

• ✓

  Capture the container logs using kubectl logs

  Why this is correct

  Capturing container logs with `kubectl logs` retrieves the stdout/stderr stream, which can reveal attacker commands, reverse shells, and application-level errors indicating compromise. This is a non-invasive, read-only operation that does not modify the container state, but be mindful that logs are ephemeral and may have been rotated; also grab the previous container's logs if the pod has restarted. It is a critical piece of forensic evidence and should be collected immediately.

• ✗

  Restart the container

  Why it's wrong here

  Restarting the container resets the process PID, clears in-memory state, and reinitializes the writable layer, destroying deleted files, file modification timestamps, and transient artifacts in `/tmp` or `/dev/shm`. It also terminates any active attacker connections, which may alert the adversary and cause them to quickly clean up or escalate. A container restart is a destructive action that contaminates the forensic timeline and should never be performed before evidence is captured.

Go deeper

Related to this question