Images passed vulnerability scanning, yet an attacker exploited an unknown flaw in a running container, spawned an interactive shell and began downloading tools. Which control is designed to catch this activity as it happens?
Select an answer to reveal the explanation.
Short Explanation
Scanning checks the luggage at the airport; runtime protection is the air marshal on the plane. Once the attacker's in a running container, only something watching live process and network behavior will notice a shell popping up. The trap for you is any pre-deployment check — they all already happened and passed.
Full Explanation
Runtime workload protection monitors containers and hosts while they run, observing process launches, file activity, system calls and network connections, often through kernel-level instrumentation such as eBPF. It compares that behavior with expected profiles or rules, such as a web container that should never spawn an interactive shell or reach unfamiliar external hosts, and it can alert, kill the process or block the connection when a deviation occurs. Because the attacker used an unknown flaw, only behavior-based detection at runtime can catch this activity as it unfolds. Static application security testing analyzes source code before build; it may find some classes of bug, but it does not observe a running container and would not detect an exploit of an unknown flaw in production. Image vulnerability scanning matches known CVEs, and the images already passed, so it has no signal about a zero-day. Infrastructure as Code scanning checks deployment definitions for risky settings before resources are created, which reduces blast radius but does not detect live attacker activity. Exam caveat: the blueprint expects you to place each control in the lifecycle; pre-deployment controls reduce risk, runtime controls detect and respond. Operational check: confirm the runtime sensor is active on every node, then trigger a benign shell in a test container and verify an alert is raised.