Monitoring, Logging, and Runtime Security
Free Certified Kubernetes Security Specialist practice — 6 questions on Monitoring, Logging, and Runtime Security, with explanations. No sign-up. Full 12-question mixed test →
A security engineer wants to detect reverse shell activity in containers using Falco, distinguishing malicious outbound shell connections from legitimate `kubectl exec` debugging sessions that also spawn bash. Which Falco rule condition BEST achieves this?
Combining a network connect syscall (fd.typechar='4' for IPv4 sockets) with process ancestry in shell_binaries matches the actual behavioral pattern of a reverse shell: a shell process initiating an outbound TCP connection. This is the pattern Falco's built-in 'Reverse Shell' style rules use, and it correctly ignores kubectl exec sessions that spawn bash without the process itself opening an outbound socket.
You must deploy Falco for syscall-level runtime detection on GKE nodes running Container-Optimized OS (COS), where kernel headers are unavailable and compiling a kernel module is not possible. Which Falco driver should you configure to retain full behavioral monitoring?
The modern eBPF probe uses CO-RE (Compile Once – Run Everywhere) with BTF, so it does not require kernel headers or on-node compilation, making it the correct driver choice for locked-down COS nodes on GKE.
Your Kubernetes audit policy must log full RequestResponse bodies ONLY for `delete` operations on the `secrets` resource, while logging just `Metadata` for every other request cluster-wide. Which policy correctly achieves this, given that audit rules are evaluated top-down and the first matching rule wins?
Placing the specific, narrowly-scoped rule (secrets + delete verb, RequestResponse) first ensures it is matched before the catch-all wildcard rule. The wildcard Metadata rule with no verb restriction then correctly captures everything else, satisfying both requirements.
A Falco 'Terminal shell in container' alert is firing repeatedly from a legitimate CI pipeline that uses `kubectl exec` with bash to perform automated health checks against application pods. Disabling the rule cluster-wide is not acceptable because it would remove detection of genuinely malicious shell access elsewhere. What is the BEST remediation?
Falco supports rule overrides and exceptions (via `append: true` custom rule files or the `exceptions` field) that add a targeted `and not` condition scoped to the known-good CI identity or image, preserving detection coverage for every other shell-spawn scenario in the cluster.
Which statement about enforcing immutability with `readOnlyRootFilesystem: true` at runtime is CORRECT?
readOnlyRootFilesystem is enforced by the container runtime purely against the container's root filesystem layer; any volume explicitly mounted into the pod (emptyDir, hostPath, PVC, etc.) is independently writable unless that specific volumeMount also sets readOnly: true. This is a classic CKS exam trap — engineers assume root-fs immutability is total, leaving writable attack surfaces that Falco must still monitor.
While reviewing Kubernetes audit logs for a `pods/exec` request, you see multiple entries with different `stage` values: RequestReceived, ResponseStarted, and ResponseComplete. To detect long-running interactive exec sessions potentially used for lateral movement, you need the record containing the final outcome and total session duration. Which audit stage should you filter on?
ResponseComplete is recorded once the response body has finished sending and represents the terminal record of the request lifecycle, containing full metadata and enabling duration calculation from requestReceivedTimestamp to stageTimestamp — this is the correct stage for identifying completed exec session outcomes.
Ready for the real thing?
The full course has two full-length practice tests, video lessons for every exam domain, hands-on labs and detailed answer explanations.
Start my full course on Udemy →