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.

• ✗

  Use kubectl exec to kill the outbound processes inside the container

  Why it's wrong here

  Using kubectl exec to manually kill processes is an anti-pattern for incident response: it mutates the live container, may trigger restart loops from supervisors or Kubernetes's restart policy, and does not block the vulnerable pod's ability to initiate new connections. Network connections are established at the kernel/socket layer, so process termination is not guaranteed to close existing TCP sessions or prevent the container from being re-executed. It also consumes valuable time and requires exec privileges, whereas a NetworkPolicy provides deterministic, declarative isolation without altering container state.

• ✓

  Apply a NetworkPolicy that selects the pod and has no egress rules, effectively blocking all outbound traffic

  Why this is correct

  A NetworkPolicy that selects the compromised pod and specifies an empty egress rule list (e.g., `egress: []`) enforces a default-deny model for all outbound traffic. Because NetworkPolicy rules are additive—only traffic explicitly allowed by a matching rule passes—an empty list allows nothing, effectively containing the pod while preserving its state for forensics. For this to work, the cluster must run a CNI that implements NetworkPolicy, such as Calico, Cilium, or Weave Net. Alternatively, setting `policyTypes: [Egress]` with no egress rules achieves the same isolation.

• ✗

  Modify the pod's /etc/hosts to block external IPs

  Why it's wrong here

  Editing `/etc/hosts` is a weak containment measure because it only influences local DNS resolution—processes that connect to IP addresses directly or use their own resolvers will bypass it entirely. The file is stored on the container's writable layer, so any change is ephemeral and can be overwritten by the kubelet, image pulls, or a container restart. Moreover, this approach requires `kubectl exec`, altering the forensic integrity of the pod and relying on non-Kubernetes mechanisms, whereas NetworkPolicy is enforced at the CNI dataplane before packets leave the pod.

• ✗

  Delete the pod and recreate it with a restrictive NetworkPolicy

  Why it's wrong here

  Deleting and recreating the pod is counterproductive during incident response because it destroys the live memory, filesystem, and network connection evidence needed to analyze the compromise. The new pod will typically receive a different IP address, and any restrictive policy must be re-applied to the new pod's labels; meanwhile, the attacker may have already moved laterally. Even if the policy is recreated, the original compromised state is lost forever. In contrast, applying a NetworkPolicy to the existing pod contains the threat without losing evidence and can be reversed after investigation.

Go deeper

Related to this question