Cloud Workload Protection
This domain covers how Falcon protects what runs in the cloud - virtual machines, containers and Kubernetes - and when each protection mode applies. Questions typically ask which control would have prevented, detected or assessed a given event.
Protection modes
- Agent-based runtime. The Falcon sensor on Linux/Windows hosts provides behavioural detection via indicators of attack, machine-learning prevention, exploit blocking, file integrity monitoring and drift prevention. It is the only mode that can stop behaviour in real time.
- Container and Kubernetes coverage. A container sensor gives container-level runtime visibility, while the Kubernetes Admission Controller evaluates workloads at admission time and can block images that violate policy (unscanned, disallowed registry, critical vulnerabilities) before they ever schedule.
- Agentless assessment. Snapshot scanning of volumes and registry scanning of images (ECR, ACR, GAR) find vulnerabilities and misconfigurations on assets that never run a sensor, and are ideal for short-lived or offline instances.
- CI/CD shift-left. Scanning images during build catches issues before deployment and complements, not replaces, runtime protection.
Risk-based prioritisation
Vulnerability counts alone are noise. Prioritise by exploit likelihood, internet exposure, privilege of the workload and whether the vulnerable package is actually loaded. A critical CVE in an unexposed, never-invoked library is lower priority than a medium flaw reachable from the internet on a privileged node.
Worked example
An engineering team deploys an image with a known remote-code-execution CVE to a production cluster. Which control catches it? Reasoning: registry scanning flags the CVE at push time; the admission controller is what prevents the pod from scheduling if a blocking policy exists; the container sensor detects and can block the resulting exploit behaviour at runtime; snapshot scanning is irrelevant here because the workload is a container. The best answer names admission control for prevention and the sensor for runtime - not the vulnerability report alone.
Traps that cost marks
Believing agentless scanning replaces runtime prevention (it cannot block); assuming admission control acts after scheduling (it does not); thinking a host sensor gives container-granular visibility; forgetting that short-lived instances may never receive a sensor; treating every critical CVE as equally urgent regardless of exposure and reachability.