CKS Monitoring, Logging and Runtime Security Practice Question
A Falco rule is written to detect when a shell is spawned inside a container. The rule condition is: `spawned_process and container and proc.name = bash`. The rule is not triggering. Which of the following is the most likely reason?
⚠ Common exam trap
The trap here is that candidates often focus on the `proc.name` condition and assume the rule is incomplete (option A), but the real issue is the `spawned_process` macro's definition, which excludes the initial container process, a nuance The CKS exam frequently tests in runtime security scenarios.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The `spawned_process` macro may not match because the process was inherited (not spawned), e.g., from an entrypoint
The `spawned_process` macro in Falco specifically matches processes that are created via `execve` or `fork` system calls. If a shell is inherited from the container's entrypoint (e.g., the container runs `bash` as PID 1 directly), it is not considered a spawned process but rather the initial process of the container. Falco's default `spawned_process` macro filters out such inherited processes, so the rule condition fails to match even though `proc.name = bash` is true.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The rule is missing `proc.name in (bash, sh, zsh)` because only bash is checked
Why it's wrong here
The rule only checks `proc.name = bash`, so it would miss alternatives like `sh`, `zsh`, `dash`, or `ash`. However, if the actual shell is indeed Bash, the rule should still fire unless another condition in the rule fails earlier. Since the rule is not triggering at all even for a Bash shell, the root cause is more likely a macro or process-context mismatch than a simple enumeration gap. While adding more shell names improves coverage, it does not address why the current rule is silent.
- ✗
Falco is not running with the required syscall capabilities
Why it's wrong here
Falco requires privileged capabilities such as `CAP_SYS_ADMIN` and `CAP_SYS_PTRACE` (or a compatible kernel module/eBPF probe) to capture syscalls and read process metadata. If Falco lacked these capabilities, it would be unable to load the driver or receive events, resulting in no rules firing at all, not just this specific one. Assuming other rules in the same environment produce alerts, Falco clearly has the necessary privileges. Therefore, a capability failure would produce a total failure of Falco monitoring, which contradicts the scenario where only this rule is ineffective.
- ✓
The `spawned_process` macro may not match because the process was inherited (not spawned), e.g., from an entrypoint
Why this is correct
The `spawned_process` macro is defined to match processes whose parent is a shell, i.e., processes created via `fork` and `exec` from an interactive or scripted shell. When a container runs an entrypoint that directly exec's a shell as PID 1, the parent of that shell is the container runtime or init process, not another shell. As a result, the `proc.pname` check inside the macro fails, and the rule never matches even though the shell is present. In such cases, the shell is inherited rather than spawned, so a rule relying on `spawned_process` will not fire.
- ✗
The priority is set to `ERROR` but the output is being filtered
Why it's wrong here
In Falco, priority and output are metadata attached to a rule; they have no influence on whether the rule's condition is evaluated. If the condition is satisfied, an event is generated and appended to the alerts stream regardless of the priority value, and output filtering only affects which events are forwarded to external systems. A filter that drops ERROR-level alerts would hide the event from the log collector, but the rule itself would still trigger and produce an internal event. Thus, filtered output cannot explain why the rule is not firing at all; the condition itself is simply not being met.
Go deeper
Related to this question
About these practice questions
This CKS question is part of Courseiva's 114-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CKS practice question is part of Courseiva's free CNCF certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CKS exam.