CKS Monitoring, Logging and Runtime Security Practice Question
Which Falco rule condition would detect an attempt to read the /etc/shadow file in a container?
⚠ Common exam trap
The exam often tests the misconception that `evt.type=read` directly detects file reads, but in Falco, the `read` syscall event is less reliable for initial detection because it occurs after the file is opened, and the `fd.name` field may not be populated in all cases; the correct approach is to use `evt.type=open` with the target file name.
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
The Falco rule condition `evt.type=open and fd.name=/etc/shadow` specifically detects the `open` system call targeting the `/etc/shadow` file. Reading a file in Linux typically involves the `open` syscall (with flags like O_RDONLY) followed by `read`, but Falco's `open` event captures the initial access attempt, making it the standard way to detect file reads. This matches the requirement to detect an attempt to read `/etc/shadow` in a container.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
evt.type=open and fd.name=/etc/shadow
Why this is correct
The open (or openat) syscall is the first system call issued when a process requests access to a file; Falco's evt.type=open matches both. fd.name=/etc/shadow filters for the exact pathname, so this condition triggers as soon as the file is opened, regardless of whether any read operation actually follows. This is the canonical Falco pattern (e.g., the 'Read sensitive file' rule) because it captures the clear intent to access the file at the syscall boundary.
- ✗
evt.type=write and fd.name=/etc/shadow
Why it's wrong here
This condition is for detecting writes to /etc/shadow, not reads. A read attempt never causes a write syscall; write is triggered by operations such as editing or overwriting the file. While an unexpected write to /etc/shadow is a serious tampering indicator, this rule would remain silent for a read-only exfiltration attempt, making it the wrong predicate for the stated question.
- ✗
evt.type=read and fd.name=/etc/shadow
Why it's wrong here
Although read syscalls do read file contents, they only occur after the file has already been opened successfully. If the open fails (permission denied), no read event is generated, so this predicate would miss a failed attempt. Additionally, in Falco, the conventional way to track a file's path is to match at open time when the file descriptor is created, rather than relying on read events that operate on an existing fd.
- ✗
evt.type=execve and proc.name=shadow
Why it's wrong here
execve is the syscall used to execute a program, and proc.name=shadow refers to a process whose executable name is 'shadow', not the file /etc/shadow. This condition would only fire if someone runs a binary literally named shadow, and it has nothing to do with reading the shadow password file. It looks at the process ancestry, not at file access, so it is entirely unrelated to the attempted read in the question.
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.