CKS Monitoring, Logging and Runtime Security Practice Question
You are writing a Falco rule to detect when a container tries to read /etc/shadow. Which condition should you use?
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
✓
fd.name=/etc/shadow and container.id != host
The correct condition 'fd.name=/etc/shadow and container.id != host' ensures the accessed file is /etc/shadow and the event originates from a container (not the host). Option A correctly includes both conditions. Option B specifies /etc/passwd (wrong file). Option C only checks that it's from a container but does not restrict the file. Option D checks the file but does not exclude host events.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
fd.name=/etc/shadow and container.id != host
Why this is correct
This rule precisely targets a containerized process attempting to read /etc/shadow, the file that stores password hashes on most Linux systems. The condition container.id != host is essential because it restricts the match to events originating from containers, excluding the host itself. This combination avoids false positives from legitimate admin actions while capturing the exact behavior indicative of credential harvesting in a container.
- ✗
fd.name=/etc/passwd
Why it's wrong here
Using fd.name=/etc/passwd instead of /etc/shadow fails to detect the intended security event because /etc/passwd is world-readable and contains only account metadata, not password hashes. This rule would generate a massive number of false positives, as many benign utilities read /etc/passwd for user mapping. Furthermore, it lacks any container scope, so it would also fire on host processes, making it both noisy and off-target for detecting credential access.
- ✗
container.id != host
Why it's wrong here
The condition container.id != host alone performs no file-specific filtering, so every syscall from any container would match the rule, flooding alerts with irrelevant events. It never checks whether the shadow file is being accessed, completely missing the attack pattern the rule is meant to detect. This is both a false-positive generator and a false-negative machine, as it has no discriminating power on the file name.
- ✗
fd.name=/etc/shadow
Why it's wrong here
While fd.name=/etc/shadow correctly selects the sensitive file, this rule omits the container.id != host filter, so it also triggers for host-side processes that legitimately interact with the shadow file, such as password expiry daemons or manual admin commands. The result is an excessive alert volume that can desensitize operators. For container-focused detection, the rule must explicitly exclude host events to avoid these false positives.
Go deeper
Related to this question
About these practice questions
This CKS question is part of Courseiva's 845-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.