CKS Monitoring, Logging and Runtime Security Practice Question
Which TWO of the following Falco fields can be used in a rule condition to detect a shell spawned inside a container? (Choose two.)
⚠ Common exam trap
CKS often tests whether candidates know which Falco fields are process-identity fields versus metadata/enrichment fields — the trap is selecting container.id or k8s.ns.name thinking they 'detect' the shell, when they only scope or locate the 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
✓
proc.pname
Option C (proc.pname) is correct because it identifies the parent process name, so a rule can match when the parent is a shell or entrypoint such as bash, sh, or a container runtime, indicating a shell was spawned by another process. Option E (proc.name) is correct because it identifies the name of the process that was executed, allowing detection of the spawned shell itself, e.g., proc.name=bash or proc.name=sh. Together, proc.pname and proc.name let Falco express conditions like proc.name in (bash, sh) and proc.pname in (bash, sh, docker, containerd) to catch shells spawned inside containers. Option A (evt.type) only describes the syscall event type (e.g., execve, clone) and does not by itself identify a shell process. Option B (k8s.ns.name) only scopes the event to a Kubernetes namespace and provides no process-level information. Option D (container.id) merely identifies the container in which the event occurred, not that a shell was spawned.
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
Why it's wrong here
In Falco, evt.type stores the syscall event type such as 'open', 'execve', or 'clone'. It identifies which kernel system call was invoked, not the actor (process) performing it. For instance, a rule intended to detect a spawned shell might look at evt.type=execve, but that field alone cannot distinguish a shell from any other executed binary; you would still need proc.name or proc.pname. Therefore evt.type is not a field that carries process identity information and cannot directly be used to match a shell process name.
- ✗
k8s.ns.name
Why it's wrong here
Falco's k8s.ns.name field is populated from the Kubernetes API and reports the namespace of the pod in which the event occurs. This field is an environment attribute, not an execution attribute: it tells you where the activity happened (e.g., 'prod' or 'default') but gives zero information about which binary was executed or who its parent process was. Because shell detection depends on process ancestry, a field describing only the pod's namespace cannot satisfy that condition. Consequently, k8s.ns.name is useful for rule scoping (e.g., only alert in 'default') but never for matching the shell binary itself.
- ✓
proc.pname
Why this is correct
In Falco, proc.pname contains the name of the parent process of the event's process. This field is particularly valuable for detecting suspicious subprocess spawning: a shell like 'bash' is frequently launched by an application (e.g., a web server or a Kubernetes controller) rather than directly by a user. If a rule checks proc.pname for a known parent binary (such as 'nginx' or 'java') and proc.name for 'bash', it can flag a shell being spawned by an unexpected parent. Since proc.pname gives the immediate ancestor, it is a valid Falco field for writing shell-detection rules.
- ✗
container.id
Why it's wrong here
Falco's container.id is the unique identifier of the container in which the event occurred, typically the Docker or CRI container ID (a 64-character hex string). This field is used to scope alerts to a specific container or to correlate events with container metadata, but it does not carry any information about the process binary, executable name, or parent process. A rule checking for a spawned shell must evaluate process attributes such as proc.name or proc.pname; container.id only tells you which container the event came from. Therefore container.id cannot by itself be used to detect a shell being spawned.
- ✓
proc.name
Why this is correct
Falco's proc.name field holds the executable name of the process that triggered the event. For shell detection, a rule can directly compare proc.name against shell values like 'bash', 'sh', 'dash', 'zsh', or 'fish' to identify interactive shells. Unlike evt.type or container.id, proc.name describes the actual binary being executed, so it is the primary field used in Falco rules for process-name matching. This makes proc.name a direct and reliable condition for shell-spawn rules.
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 and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official CNCF exam blueprint
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.