A cloud security engineer is hardening container runtime environments. Which TWO of the following are effective measures to prevent container escape?
Dropping unneeded Linux capabilities directly shrinks the kernel attack surface available inside a container, satisfying the stem's requirement to prevent escape. Without privileges such as CAP_SYS_ADMIN, a compromised process cannot mount filesystems, load modules or manipulate namespaces, so breakout techniques that depend on elevated capabilities fail.
Why this answer
Option D is correct because dropping all Linux capabilities except those strictly required follows the principle of least privilege and removes the powerful capabilities (such as CAP_SYS_ADMIN, CAP_NET_ADMIN, or CAP_SYS_PTRACE) that container-escape exploits typically abuse to break out of the namespace and interact with the host. Option E is correct because Seccomp profiles restrict the set of system calls a container process can invoke, blocking dangerous syscalls (e.g., ptrace, mount, unshare, keyctl) that are commonly leveraged in kernel-exploit-based escapes. Option A is not a preventive control for container escape: keeping the kernel patched reduces known vulnerabilities but does not by itself constrain a container's privileges or syscall surface.
Option B is not effective as stated because mounting the host filesystem read-only does not prevent escape — an attacker can still gain host access and then remount or exploit writable paths; the real mitigation is not exposing the host filesystem to the container at all. Option C is incorrect because privileged mode disables the very isolation mechanisms (capabilities, seccomp, AppArmor/SELinux, device cgroup) that prevent escape, making it the opposite of a hardening measure.
Exam trap
CCSP often tests whether candidates recognize that 'privileged mode' is a vulnerability, not a mitigation, and that generic practices like 'latest kernel' or 'read-only host mount' are distractors that sound secure but do not address container escape specifically.