CKS Monitoring, Logging and Runtime Security Practice Question
A security team wants to detect any attempt to spawn an interactive shell inside a container. Which Falco rule condition would be appropriate?
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
✓
container.id != host and evt.type = execve and proc.name = bash
Falco uses syscall events. The condition container.id != host and evt.type = execve and proc.name = bash detects a bash exec in a container, which is a common interactive shell.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
container.id != host and evt.type = read and fd.name = /etc/shadow
Why it's wrong here
This filter targets read syscalls that access /etc/shadow inside a container. It is designed to catch credential file access, not process execution, so an attacker using a shell without reading the shadow file would go undetected. Conversely, any container process doing a legitimate read of that file would trigger a false positive, and the rule says nothing about execve or proc.name, making it a file-access detector rather than a shell-spawn detector.
- ✗
evt.type = connect and container.id != host
Why it's wrong here
Matching connect syscalls with a non-host container.id flags any outbound network connection from a container. This is a network-monitoring rule, not a process-execution rule, because it lacks an execve condition and a process name filter. A shell spawn does not inherently create a connection, and typical containerized workloads doing API calls would generate noise, so this would miss the intended bash invocation entirely and instead alert on unrelated traffic.
- ✗
proc.name = bash and evt.type = execve
Why it's wrong here
This rule fires on every bash execve anywhere on the system because it omits the container.id filter. Host-level bash executions from cron jobs, user logins, or administrative scripts would be indistinguishable from containerized shell activity, flooding the alert stream with false positives. The correct condition must scope events to containers by adding container.id != host, otherwise the rule is overly broad and cannot specifically detect container-based shell spawning.
- ✓
container.id != host and evt.type = execve and proc.name = bash
Why this is correct
This is the exact Falco rule needed: it combines the execve syscall (new process execution), proc.name = bash (the shell binary), and container.id != host (restricting to container events). The combination logically isolates the moment a bash shell is spawned from inside a container while excluding host-level bash runs, giving a high-fidelity signal for interactive shell activity. Because it checks the syscall that actually creates the process, it correctly captures shell starts rather than related but distinct activities like file reads or network connections.
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 →
Same concept, more angles
1 more way this is tested on CKS
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. A security engineer wants to detect any attempt to spawn a shell inside a container. Which Falco rule condition would trigger on a shell being spawned in a container (e.g., /bin/bash or /bin/sh)?
medium- ✓ A.spawned_process and container and proc.name in (bash, sh, zsh)
- B.evt.type=open and fd.name contains /bin/bash
- C.evt.type=execve and container and proc.name in (bash, sh, zsh)
- D.proc.name = bash and container
Why A: Falco's rule language uses the 'spawned_process' macro, which expands to evt.type in (execve, execveat) and evt.dir=<, to detect process execution. Combining it with the 'container' field restricts the match to containerized workloads, and 'proc.name in (bash, sh, zsh)' matches the shell binary names. This is the canonical Falco condition for detecting a shell spawned inside a container.
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.