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.

• ✗

  Deny all ingress and egress traffic to/from the pod's namespace

  Why it's wrong here

  This approach targets the entire namespace by effectively selecting all pods, not just the compromised one. Because NetworkPolicy applies to all pods matching its podSelector, a namespace-wide deny-all would cut off traffic for every workload in that namespace, including legitimate services and the forensic tools you may need. It also fails to preserve the isolation boundary at the pod level, so the compromised pod remains reachable from pods in other namespaces unless cluster-wide policies exist. Thus it is over-broad and ignores the requirement to isolate a single pod.

• ✓

  Create a NetworkPolicy with podSelector matching the compromised pod and empty ingress/egress rules (deny all)

  Why this is correct

  This is correct because a NetworkPolicy with a podSelector that matches only the compromised pod and contains no ingress or egress rules creates a default-deny policy for that pod alone. Under Kubernetes NetworkPolicy semantics, any selected pod with no matching rules is isolated: all inbound and outbound traffic is dropped, including DNS and cluster traffic. The policy does not alter the pod itself, so it preserves the running state and evidence. This is the standard, least-privilege method for isolating a single pod without disturbing the rest of the namespace.

• ✗

  Add a label to the pod and create a NetworkPolicy allowing only traffic from a forensic pod

  Why it's wrong here

  This approach fails because it explicitly allows traffic to and from a forensic pod, meaning the compromised pod is not fully isolated—it can still communicate, which could let an attacker continue to exfiltrate data or pivot through that allowed path. Additionally, labeling a running pod requires manually modifying its metadata, and any NetworkPolicy that permits traffic must define specific rules, leaving the rest of the pod's connections denied, but the allowed connection itself creates a gap. Full isolation requires denying all traffic, not merely restricting to a trusted counterpart.

• ✗

  Delete the pod

  Why it's wrong here

  Deleting the pod destroys the very evidence you need to investigate the compromise—filesystem artifacts, process memory, network connections, and logs—which is essential for forensic analysis. Moreover, if the pod is managed by a controller like a Deployment or ReplicaSet, the controller may immediately recreate a new pod with the same image and labels, and without a NetworkPolicy that new pod will have the same exposure. Thus deletion neither isolates nor remediates; it loses data and potentially lets the attacker redeploy a fresh instance.

Go deeper

Related to this question