DOP-C02 Incident and Event Response 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 entire namespace to ensure all resources are removed.

  Why it's wrong here

  Deleting the entire namespace is an extreme containment measure that removes all objects (Deployments, Services, ConfigMaps, Secrets) in that namespace, likely causing a widespread outage for every application sharing the same environment. This approach has a blast radius far beyond the compromised pod, and any unmanaged resources are deleted permanently, making it inappropriate when you need to minimize business disruption. Instead, target only the affected workload to limit collateral damage.

• ✗

  Scale down the deployment to 0 replicas.

  Why it's wrong here

  Scaling the Deployment to zero replicas terminates all pods managed by that Deployment, not just the compromised one, which can degrade service capacity for healthy replicas. Additionally, this action relies on the ReplicaSet controller to trigger graceful termination, so it may be delayed by termination grace periods or pod disruption budgets, giving the attacker more time to execute malicious activity. Deleting the specific pod directly is faster and isolates the compromise without affecting other replicas.

• ✓

  Delete the pod using kubectl delete pod.

  Why this is correct

  Deleting the pod with `kubectl delete pod <name>` immediately sends a termination signal (SIGTERM) to the container, and after the grace period, a SIGKILL, removing the pod from the cluster and stopping the malicious process. This is the primary containment step to halt active compromise; however, if the pod is managed by a ReplicaSet or Deployment, the controller will replace it, so you must also update the workload definition or scale down to prevent recreation. It is a precise operation that affects only the compromised instance.

• ✓

  Use kubectl exec to gather forensic data from the pod before termination.

  Why this is correct

  Before terminating the pod, use `kubectl exec` to run diagnostic commands inside the container to capture volatile evidence like process lists, connected endpoints, environment variables, and files in memory, which are lost forever once the pod is deleted. You can also copy important artifacts to a secure location using `kubectl cp` or redirect command output to a persistent store. This forensic data is critical for root-cause analysis and for understanding the attack vector, so it must be collected before the pod is destroyed.

• ✓

  Apply a Kubernetes NetworkPolicy to deny all ingress/egress traffic to the compromised pod.

  Why this is correct

  Applying a NetworkPolicy that selects the compromised pod's labels and specifies an empty ingress and egress rule set effectively blackholes all traffic to and from the pod, severing command-and-control channels and preventing lateral movement. This can be done before or after pod deletion; if after deletion, it may be unnecessary unless new pods with the same labels appear. NetworkPolicy requires a CNI plugin that enforces it (e.g., Calico), but when supported, it provides a non-destructive containment measure that allows you to keep the pod alive for further investigation.

Go deeper

Related to this question