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.

• ✗

  Exec into the container and delete suspicious files

  Why it's wrong here

  Executing into the container to delete suspicious files is a forensic anti-pattern: it modifies the very filesystem you are trying to investigate, destroying timestamps, metadata, and potentially overwriting unallocated space with new inode writes. It also alerts the attacker that you know they are present, giving them a chance to cover their tracks or escalate before you can complete a proper evidence capture. Acquiring data must always precede any corrective action.

• ✗

  Restart the kubelet on the node

  Why it's wrong here

  Restarting the kubelet is not a containment measure for a single compromised container; kubelet is the node agent that reconciles pod state, and restarting it can actually recreate the compromised pod if it is managed by a Deployment, or at minimum leave the container running while the node agent churns. It also does nothing to preserve the container's filesystem or memory state, and may trigger other side effects such as kubelet cache resets or pod recreations that destroy logs and runtime artifacts. Proper response is to isolate the workload and image the container data, not to bounce a node-level service.

• ✓

  Use kubectl cp to copy files from the container to a safe location

  Why this is correct

  Using kubectl cp is correct because it reads the container's filesystem through the container runtime and produces a tar archive in a safe location without modifying the source files; the command uses tar and writes to stdout, so the container's storage layer is left untouched for subsequent analysis. This preserves evidence such as dropped payloads, shell history, modified binaries, and configuration files, and it can be performed quickly even while the container remains running. Be aware that kubectl cp does not capture memory or /proc, but for filesystem artifacts it is the advisable first step before any destructive containment.

• ✗

  Immediately delete the pod to stop the attack

  Why it's wrong here

  Immediately deleting the pod to stop the attack destroys the container's writable layer, which contains the primary evidence — attacker-created files, reverse-shell binaries, logs, and command history — while also terminating network connections that could be monitored or traced. Even if the pod is recreated by a ReplicaSet or Deployment, the original container's runtime state (including its overlay filesystem changes and memory) is gone forever, making post-incident root-cause analysis impossible. The correct sequence is to preserve evidence first, and only then delete or isolate the pod after the filesystem has been captured.

Go deeper

Related to this question