CKS Monitoring, Logging and Runtime Security Practice Question
A security team wants to detect attempts to read /etc/shadow inside containers. Which Falco rule condition would trigger on a container reading that file?
⚠ Common exam trap
The trap here is that candidates often focus on the process name (like `cat`) instead of the file descriptor being accessed, leading them to choose option B, but Falco's strength is in monitoring system calls and file paths, not just process names.
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
Falco uses system call events to monitor file access. The condition `evt.type=open` captures file open operations, and `fd.name=/etc/shadow` filters for the specific file path. This triggers when any process inside a container opens /etc/shadow for reading, which is a classic indicator of an attempt to access sensitive host data.
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=connect and fd.name=/etc/shadow
Why it's wrong here
The connect syscall is used to establish network socket connections, and in that context fd.name holds the remote IP/port tuple, not a filesystem path. Therefore, a filter requiring fd.name=/etc/shadow alongside evt.type=connect is logically unsatisfiable and will never fire, because /etc/shadow is a regular file, not a network endpoint. This option confuses file I/O with network activity.
- ✗
evt.type=execve and proc.name=cat
Why it's wrong here
This rule monitors process execution rather than file access, and even if cat is executed, the actual read of /etc/shadow still occurs through open() and read() syscalls, not execve. Additionally, hardcoding proc.name=cat is far too restrictive because attackers can use head, tail, less, strings, shell built-ins, or a custom binary to read the file, so this detection is easily bypassed and yields many false negatives.
- ✗
evt.type=open and container.id exists
Why it's wrong here
This filter would trigger on every open() syscall made by any container because container.id exists merely asserts that a container ID is present, not that the event is tied to a specific file. Since no file path is specified, it produces a high volume of irrelevant alerts for normal file operations inside containers, completely failing to isolate access to /etc/shadow.
- ✓
evt.type=open and fd.name=/etc/shadow
Why this is correct
This rule is accurate because Falco's open event exposes the target path in the fd.name field, so the condition matches only when a process attempts to open the /etc/shadow file, regardless of how it eventually reads it. The open() syscall is the necessary first step for reading a file's contents, making this a reliable, low-noise detector for attempts to access sensitive files like the shadow password database.
Go deeper
Related to this question
About these practice questions
Courseiva writes every CKS question from scratch — 845 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or 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.