Monitoring, Logging and Runtime Security →mediumMultiple ChoiceObjective-mapped

CKS Monitoring, Logging and Runtime Security Practice Question

You are responding to a security incident where a pod named `compromised-pod` in namespace `default` is suspected of being used for cryptocurrency mining. You need to immediately isolate the pod from the network while preserving evidence. Which command sequence should you use?

⚠ Common exam trap

In the CKS exam, a common trap is confusing node-level controls (cordon, drain) with pod-level network isolation (NetworkPolicy). Candidates may think cordoning a node isolates the pod, or that deleting the pod is sufficient containment, but deleting destroys forensic evidence.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

kubectl label pod compromised-pod isolated=true && kubectl apply -f networkpolicy.yaml

The correct approach is to label the pod and apply a deny-all NetworkPolicy that selects pods with that label. This immediately isolates the pod from all network traffic while preserving the pod for forensic analysis. The command sequence is: kubectl label pod compromised-pod isolated=true && kubectl apply -f networkpolicy.yaml where the networkpolicy.yaml defines an ingress/egress deny-all policy for pods with label isolated=true.

Answer analysis

Option-by-option breakdown

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

✗
kubectl cordon <node-of-compromised-pod>
Why it's wrong here
Cordoning the node only prevents new pods from scheduling onto it by marking the node unschedulable; it has no effect on pods already running, so the compromised pod continues to run its mining process with full network access. Furthermore, cordon impacts every pod on the node, potentially disrupting unrelated workloads, and does nothing to enforce an egress policy that would block the miner's communication with mining pools.
✓
kubectl label pod compromised-pod isolated=true && kubectl apply -f networkpolicy.yaml
Why this is correct
Ly identifies the need to label the pod and apply a deny-all NetworkPolicy. The command sequence is impractical (busybox lacks kubectl), but the concept is what the exam tests. In a real scenario, you would label the pod directly and then apply the policy.
✗
kubectl delete pod compromised-pod && kubectl describe pod compromised-pod
Why it's wrong here
Deleting the pod immediately terminates the container and removes its writable layer, destroying in-memory evidence, local artifacts, logs, and any binary that may have been dropped by the attacker; the subsequent describe command only reads cached or cluster state, which provides no investigative value and does not affect the pod's network path. Since most workloads are managed by a ReplicaSet or Deployment, Kubernetes will schedule a fresh replacement pod, meaning the malicious behavior can simply resume if the same image or configuration is used.
✗
kubectl exec compromised-pod -- killall miner-process
Why it's wrong here
Running killall inside the pod only sends a SIGTERM to the specified process name; if that process is the container's PID 1, the restart policy may immediately start a new container, and if the miner runs as a background process or with a different name, the killall may miss it entirely. Even if the miner stops briefly, the pod's network namespace remains unchanged, so any subsequent attempt to exfiltrate data, connect to the mining pool, or receive command-and-control traffic is not blocked—only a NetworkPolicy can provide that isolation.

Go deeper

CKS Monitoring, Logging and Runtime Security Practice Question

Why each option matters

Option-by-option breakdown

Related to this question