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.

• ✗

  Deploy Falco with a rule to detect outbound connections

  Why it's wrong here

  Deploying Falco with a rule to detect outbound connections is a monitoring and detection mechanism, not an immediate forensic investigation step. Falco runs as a DaemonSet outside the pod and relies on kernel events, so it can only alert you to suspicious behavior after the fact, without providing the raw packet-level details needed to see exactly what data is being exfiltrated or which C2 endpoints are contacted. Setting it up takes time and does not capture the current traffic from the compromised pod, making it a poor first response for an active incident.

• ✗

  Create a NetworkPolicy to deny all egress traffic

  Why it's wrong here

  Creating a NetworkPolicy to deny all egress traffic is a remediation or containment action, not an investigation technique. While it can stop the compromised pod from communicating with external hosts, it destroys the evidence of any ongoing connections and may alert the attacker that they've been discovered. It also provides no visibility into what traffic was already sent, and its effectiveness depends on the CNI plugin supporting NetworkPolicy, which is not guaranteed in every cluster.

• ✓

  Run 'kubectl exec <pod> -- tcpdump -i eth0' to capture packets

  Why this is correct

  Running 'kubectl exec <pod> -- tcpdump -i eth0' is the correct immediate investigation step because it captures raw network packets directly from the pod's network interface, revealing destination IPs, ports, protocols, and payloads of ongoing communication. This live capture provides the forensic evidence needed to understand the attacker's command-and-control traffic or data exfiltration in real time. However, tcpdump must be installed in the container image and the container must have the necessary privileges, such as CAP_NET_RAW or root access, which may require using an ephemeral container if the tools are missing.

• ✗

  Check the pod's logs using 'kubectl logs <pod>'

  Why it's wrong here

  Checking the pod's logs with 'kubectl logs <pod>' is insufficient for investigating a suspected network compromise because application logs typically do not record low-level network connections unless the application explicitly writes them. Even if the application is legitimate, a compromised process can alter or suppress logs to hide its activities, leaving you without packet-level details like exact source to destination flows, packet payloads, or timing. Logs are useful for application-level anomalies, but they are not a substitute for capturing the actual network traffic.

Go deeper

Related to this question