Simulado Certified Kubernetes Security Specialist (CKS)

gVisor's Sentry is a userspace application kernel that re-implements a subset of Linux syscalls and intercepts container syscalls, which is what provides isolation from the host kernel — but it also means unsupported/unusual syscalls can fail and syscall-heavy workloads can incur overhead. Kata Containers runs each pod in a lightweight VM with its OWN real Linux kernel, giving strong isolation while preserving broader syscall compatibility, so it is a valid alternative — making the first option correct. 'privileged: true under runsc restores syscalls' is wrong: privileged does not bypass the Sentry's syscall implementation and would also undermine the sandbox's purpose. 'gVisor and runc are identical / grant SYS_ADMIN' is wrong because runc shares the host kernel (no sandbox) while gVisor does not, and adding SYS_ADMIN is a dangerous privilege grant, not a compatibility fix. The last option inverts reality: Kata uses its own VM kernel (it does NOT share the host kernel), and disabling seccomp would weaken security rather than appropriately address syscall compatibility.

The log backend supports an --audit-log-mode flag; 'blocking' mode makes the API server wait for each audit event to be written before processing/returning the request, providing the synchronous guarantee at a latency cost, while --audit-log-maxage=30 and --audit-log-maxbackups handle retention/rotation. 'batch mode flushes synchronously before each response' is wrong: batch mode intentionally buffers and writes asynchronously in batches for performance and does NOT block the request, so it provides no per-request write guarantee. 'RequestResponse level forces synchronous writes' is wrong: the level controls how much data is captured, not whether the write is blocking; blocking behavior is governed by the mode, not the level. 'The webhook backend is always synchronous' is wrong: the webhook backend also has batch and blocking modes (and defaults toward batching), so it is not inherently synchronous, and offloading retention to the receiver does not satisfy the synchronous local-write guarantee requested.

Falco ships macros that encode best practice: 'spawned_process' resolves to an execve in the exit direction (a real process creation), 'container' restricts to events occurring inside a container (container.id != host), and 'shell_binaries' is a maintained list including bash, sh, zsh, etc. Combining them yields a precise, low-false-positive rule. 'evt.type = execve and proc.name = bash matching anywhere on the node' is wrong because it omits the container scope (it would fire on host shells and on legitimate node administration) and only catches bash, missing sh/ash/zsh. 'k8s.ns.name != "" and evt.dir = < and fd.name contains /bin/sh' is wrong: evt.dir = < is the exit/return direction of a syscall and fd.name is for file-descriptor events, not process spawning; matching a path substring in fd.name does not reliably detect a shell process and would miss execs that don't open /bin/sh as an fd. 'container.id != host and evt.type = open and proc.cmdline contains sh' is wrong because watching open() with a cmdline substring 'sh' is a crude, noisy heuristic that fires on any process whose command line merely contains the characters 'sh' (e.g., 'ssh', 'wsh', 'crash') and does not actually detect process creation.