CKS Monitoring, Logging and Runtime Security Practice Question
A security team wants to detect any attempt to read /etc/shadow from within a container using Falco. Which condition in a Falco rule would match this behavior?
⚠ Common exam trap
A common misconception in CKS is that reading a file is detected via the `read` syscall, but the correct approach is to detect the `open` syscall because that is when the file access is initiated and Falco's rule engine is designed to catch the opening event.
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
✓
evt.type=open and fd.name=/etc/shadow
Reading /etc/shadow from a container requires opening the file first, so the Falco rule must match the `open` system call (evt.type=open) and the exact file path (fd.name=/etc/shadow). The `open` syscall is the entry point for file access, and Falco captures it before any read or write occurs, making it the appropriate event type to detect an attempt to read the shadow file.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
proc.name contains "shadow" and evt.type=read
Why it's wrong here
This filter checks for a process whose name contains "shadow" combined with any read syscall event. Process names like "shadow" or "shadowd" are unrelated to file access; /etc/shadow can be opened by any process such as "cat" or "python". It fails to inspect the target file, so a direct read of /etc/shadow by a normal process would not match this rule.
- ✗
evt.type=read and fd.name contains "shadow"
Why it's wrong here
Filtering on read syscalls with fd.name containing "shadow" detects only post-open reads and can be bypassed if the file is read through a hardlink or an inherited file descriptor; "contains" also matches files such as /etc/shadow.backup. More importantly, failed open attempts (e.g. permission denied) never reach the read stage, so the opening attempt is the better event to trace.
- ✓
evt.type=open and fd.name=/etc/shadow
Why this is correct
The open syscall is the actual attempt to access a file; checking evt.type=open with an exact fd.name=/etc/shadow ensures the rule fires when any process tries to open the shadow password file, whether or not the subsequent read occurs. This catches both successful reads and denied attempts, making it the precise detection predicate.
- ✗
container and fd.name=/etc/shadow
Why it's wrong here
The token "container" is a boolean-ish field indicating the event occurred in a container, not an event selector; it neither restricts the syscall type nor the file path. Without evt.type=open and fd.name=/etc/shadow, such a filter would match every container event, producing noise and failing to identify reads of the shadow file.
Go deeper
Related to this question
About these practice questions
One of 845 original CKS practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.