hardMultiple ChoiceObjective-mapped
CKS Practice Question: A security engineer for a financial services…
You are a security engineer for a financial services company running a Kubernetes cluster with 50 nodes. The cluster uses containerd as the container runtime and Calico for networking. The security team has detected unusual outbound network connections from a pod running in the 'payments' namespace to an external IP address known to be a command-and-control server. The pod is part of a Deployment named 'payment-processor' with 3 replicas. The cluster has a Falco daemonset deployed with default rules, and audit logging is enabled for the API server. You need to quickly identify the compromised container and contain the threat. Which action should you take FIRST?
⚠ Common exam trap
CNCF often tests the misconception that `kubectl delete pod` is sufficient for containment, but the trap here is that a Deployment controller will immediately recreate the pod, so you must either scale the Deployment to 0 (which destroys evidence) or directly stop the container at the runtime level using `crictl stop`.
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
✓
Identify the node hosting the suspicious pod using 'kubectl get pod -o wide', then SSH to that node and use 'crictl ps' to list containers, then 'crictl stop' the container
It follows the proper incident response workflow for a compromised container: first identify the node hosting the suspicious pod using `kubectl get pod -o wide`, then SSH to that node and use `crictl ps` (the containerd CLI) to list running containers and their IDs, then use `crictl stop` to immediately halt the compromised container. This approach directly isolates the threat at the container runtime level without relying on potentially compromised in-pod tools or deleting the pod (which could be recreated by the Deployment controller).
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 -it <pod> -- bash' to inspect the container, then kill the malicious process from within
Why it's wrong here
Executing into a container with kubectl exec is not a reliable containment or investigation method because many production images lack a shell such as bash, and the malicious process may be running as PID 1 where a SIGTERM could simply cause the container runtime to restart it per the pod restart policy. Moreover, interactive access alters the container's filesystem and process state, contaminating memory and disk forensic evidence that the incident response team would need to analyze the C2 traffic and the attacker's tooling.
- ✗
Scale the 'payment-processor' Deployment to 0 replicas to immediately stop all pods
Why it's wrong here
Scaling the Deployment to zero replicas is an indiscriminate action that halts all instances of the payment-processor service, not just the compromised pod, causing an immediate availability outage and disrupting legitimate traffic processing. This abrupt termination also discards the running container's memory snapshot, open network connections, and file descriptors, which are critical for analyzing the attack, and it prevents you from isolating which specific process or artifact was compromised.
- ✗
Check the Falco logs for an alert containing the pod name, then use 'kubectl delete pod' to remove the compromised pod
Why it's wrong here
Depending on Falco alerts is uncertain because the default rule set is focused on syscall anomalies and may not flag outbound C2 traffic, and even if an alert exists it might be too generic to correlate with this particular pod. Deleting the pod is also ineffective as the owning ReplicaSet immediately schedules a replacement, which could land on the same node and inherit the same vulnerable image or configuration, so the attacker's foothold is not removed. Additionally, pod deletion erases the container's writable layer and logs, destroying evidence of the intrusion.
- ✓
Identify the node hosting the suspicious pod using 'kubectl get pod -o wide', then SSH to that node and use 'crictl ps' to list containers, then 'crictl stop' the container
Why this is correct
This is the correct approach because it precisely identifies the node and the exact container instance running the malicious workload, then uses the CRI tool crictl to stop that specific container without impacting other replicas or the Deployment's configuration. Stopping the container preserves the pod object and node state for forensic collection, while the runtime's crictl stop sends a clean stop signal and allows you to capture the container's ID and runtime state for later analysis. It is the least destructive and most targeted method to halt the malicious process while maintaining the ability to investigate.
Go deeper
Related to this question
About these practice questions
Courseiva writes every CKS question from scratch — 114 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CKS practice question is part of Courseiva's free CNCF certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CKS exam.