Courseiva

CKS proc.name Practice Question

Which TWO of the following are valid methods to detect a container spawning a shell (e.g., /bin/bash) using Falco? (Select two.)

⚠ Common exam trap

Falco often tests the distinction between process name fields (proc.name) and file descriptor fields (fd.name), leading candidates to incorrectly select option E, which uses fd.name instead of proc.name for process detection.

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

✓

Check if proc.name is 'bash' and container is true

Option B is correct because Falco rules can directly match the process name field proc.name against 'bash' (or other shell binaries) while also requiring container=true, which scopes the detection to containerized workloads and reliably flags a shell being launched inside a container. Option C is correct because Falco ships a 'spawned_process' macro that encapsulates the execve/execveat event conditions for process creation, and combining it with a container filter (e.g., container.id != host or container=true) is the idiomatic way to detect any process, including a shell, spawned inside a container. Option A is not a shell-spawning detection method; 'Launch Sensitive Mount' targets mount-related activity such as sensitive host paths being mounted, not process execution. Option D is wrong because checking for a parent of 'sshd' detects remote login sessions, not a container spawning a shell, and misses container-internal shell launches. Option E is incorrect because fd.name refers to file descriptor names (files, sockets), not the executable being run, so it would not properly identify a shell being executed via execve.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • ✗

    Use the rule 'Launch Sensitive Mount'

    Why it's wrong here

    'Launch Sensitive Mount' fires when a container starts with a sensitive host path mounted, such as /proc or /dev; it detects mount configuration, not process execution, so a spawned /bin/bash never triggers it. It is tempting because it covers container startup behaviour, and it would be correct when detecting privileged hostPath mounts.

  • ✓

    Check if proc.name is 'bash' and container is true

    Why this is correct

    Falco rules match process attributes from the kernel; checking proc.name equals bash while container is true detects an interactive shell spawned inside a container. This distinguishes container shell execution from host-level bash processes, which is the behaviour being hunted.

  • ✓

    Use the macro 'spawned_process' combined with a container filter

    Why this is correct

    Falco's predefined `spawned_process` macro expands to the `execve` syscall with `evt.type=execve`, capturing every process launch. Pairing it with a container filter such as `container.id != host` restricts detection to containerised workloads, satisfying the stem's requirement to flag a shell like /bin/bash spawning inside a container.

  • ✗

    Check if the process's parent is 'sshd'

    Why it's wrong here

    Parent-process matching on sshd only catches shells launched from remote SSH sessions, missing kubectl exec, docker exec and application-spawned shells. It is tempting because sshd parentage is a classic host intrusion indicator, and would suit detecting interactive SSH logins on a bastion rather than container shell spawns.

  • ✗

    Check if evt.type is 'execve' and fd.name contains 'bash'

    Why it's wrong here

    Filtering on evt.type=execve with fd.name containing bash inspects the file descriptor of the executed binary, not the process command line, so shells invoked via paths or renamed binaries evade it. It is tempting because execve is the correct syscall to watch, and would work when monitoring executions of a known binary path.

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 →

How Courseiva writes practice questions · Editorial policy

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.