CKS Practice Question: A security team wants to detect anomalous process…

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Configure CRI-O to log all container process starts to syslog.

  Why it's wrong here

  CRI-O is an OCI-compliant container runtime that manages container and image lifecycle, but it does not expose per-process events like execve to syslog; its logging is limited to runtime events such as create, start, and stop. Capturing process starts would require kernel tracing facilities (eBPF, tracepoints) or ptrace, not a syslog configuration change. Even with syslog, CRI-O lacks the instrumentation to deliver granular process-level data, so this approach cannot meet the detection requirement.

• ✓

  Deploy Falco as a DaemonSet using eBPF probe to monitor system calls.

  Why this is correct

  Falco deployed as a DaemonSet runs on every node and consumes kernel events via an eBPF probe (or a kernel module) to observe system calls such as execve, open, and connect across all containers. It applies a rules engine to flag anomalous process executions in real-time, without requiring modifications to container images or pod specs. The eBPF approach is preferred over the kernel module on modern distributions because it avoids out-of-tree module compilation and is safer in hardened environments.

• ✗

  Enable Kubernetes audit logging and parse the logs for process events.

  Why it's wrong here

  Kubernetes audit logging records API server operations—get, list, create, update, delete, and exec subresource requests—but it never sees syscalls or process spawns occurring inside pods. Even if a pod is compromised and runs an unexpected binary, the audit log contains only the API traffic that created or attached to the pod, not the runtime process tree. Therefore parsing audit logs would miss most process anomalies and cannot serve as a runtime detection mechanism.

• ✗

  Use OPA Gatekeeper to enforce allowed process lists in pod specs.

  Why it's wrong here

  OPA Gatekeeper is an admission-webhook controller that evaluates policy against Kubernetes resource manifests before they are persisted, so it can reject pod specs that explicitly list disallowed commands or arguments. However, it cannot observe processes executed later at runtime, such as child processes spawned by the container’s main entrypoint, nor can it react to a live compromise. Using it to enforce an allowed process list in pod specs is a preventive control, not a detection control, and fails when containers have arbitrary images or start processes not declared in the spec.

Go deeper

Related to this question