Test yourself
Runtime & eBPF security
Final exam · 60 questions · answers explained as you pick
eBPF & kernel foundations
12 questions
01eBPF lets you…
Incorrect — The point of eBPF is to avoid modifying or rebuilding the kernel.
Correct — Attach logic at kernel hooks with no reboot and no out-of-tree module.
Incorrect — eBPF runs in kernel context at defined hook points.
Incorrect — It observes and filters at hooks; it is not a scheduler.
02The eBPF verifier exists to…
Correct — It rejects programs that could crash or hang the kernel.
Incorrect — It checks safety, not confidentiality.
Incorrect — That is clang/LLVM; the verifier validates the bytecode.
Incorrect — It gates loading, not execution timing.
03eBPF maps are…
Incorrect — They are general key/value stores, not routes.
Correct — How a probe passes events and config to the userspace agent.
Incorrect — Unrelated to containers.
Incorrect — Unrelated to storage.
04Common eBPF attach points for security tools include…
Correct — These observe syscalls, kernel functions, security decisions, and packets.
Incorrect — eBPF operates in the kernel, not at HTTP.
Incorrect — Cron is userspace scheduling, unrelated.
Incorrect — eBPF is an OS-kernel technology.
05Why is eBPF-based security observability hard to evade from userspace?
Correct — A process cannot hide a syscall it must make from a kernel-level probe.
Incorrect — It observes; it does not encrypt.
Incorrect — It runs in the kernel, not in the container.
Incorrect — Observation does not block by default.
06The BPF LSM (Linux Security Module via eBPF) allows…
Incorrect — That is XDP/tc; BPF LSM is about security hooks.
Correct — Policy logic runs at the same hooks SELinux/AppArmor use.
Incorrect — It complements MAC, not disables it.
Incorrect — Unrelated to encryption.
07Modern eBPF-based Falco replaced the older approach of…
Correct — The eBPF probe avoids shipping an out-of-tree kernel module.
Incorrect — It always needed a kernel-level source of syscalls.
Incorrect — Falco is software.
Incorrect — It reads local kernel events.
08A key operational advantage of eBPF over a kernel module is…
Incorrect — It runs in the kernel, just safely and without a module.
Correct — Portability (CO-RE) and safety reduce operational risk.
Incorrect — It is a kernel technology.
Incorrect — The verifier is what makes it safe.
09CO-RE (Compile Once, Run Everywhere) addresses…
Correct — One binary adapts to differing kernel struct layouts.
Incorrect — Unrelated to portability.
Incorrect — That is supply-chain, not eBPF.
Incorrect — Not what CO-RE solves.
10eBPF programs are constrained (bounded loops, limited size) because…
Correct — The constraints are what let untrusted logic run safely in the kernel.
Incorrect — The limits are for safety, not raw capability.
Incorrect — They compile to eBPF bytecode, not Python.
Incorrect — The constraints are kernel-safety, not container-related.
11Hubble (Cilium) and Pixie are examples of eBPF used for…
Incorrect — They are observability tools.
Correct — eBPF sees flows and calls transparently.
Incorrect — Unrelated to build.
Incorrect — Unrelated to secrets.
12The security value of watching at the syscall boundary is that…
Correct — A chokepoint that malware cannot avoid to interact with the system.
Incorrect — They are not; that is not the value.
Incorrect — It sees process, file, and network activity.
Incorrect — It is a source for detection, complementing logs.
12 questions · explanations appear as you answer
Kernel hardening & isolation
12 questions
01A container is fundamentally…
Correct — Not a VM — kernel isolation is the security boundary to harden.
Incorrect — Containers share the host kernel; that is the key difference.
Incorrect — It is an isolated process.
Incorrect — Images are layers, not the isolation mechanism.
02Linux namespaces provide…
Incorrect — That is cgroups; namespaces provide isolation of views.
Correct — Each namespace type isolates one kind of global resource.
Incorrect — That is seccomp.
Incorrect — That is SELinux/AppArmor.
03A user namespace improves security by…
Correct — Container "root" is not host root, shrinking escape impact.
Incorrect — Unrelated to encryption.
Incorrect — That is cgroups.
Incorrect — That is a network namespace/policy concern.
04Linux capabilities let you…
Incorrect — They partition privilege, not encrypt.
Correct — Drop ALL and add just CAP_NET_BIND_SERVICE, for example.
Incorrect — Unrelated to scheduling.
Incorrect — That is cgroups/io.
05The most dangerous capability to grant a container is usually…
Correct — Often called “the new root”; avoid it.
Incorrect — That only allows binding low ports — low risk.
Incorrect — Far less powerful than SYS_ADMIN.
Incorrect — Several capabilities enable escape.
06seccomp is used to…
Incorrect — That is SELinux; seccomp filters syscalls.
Correct — A seccomp-BPF profile shrinks the kernel attack surface.
Incorrect — That is cgroups.
Incorrect — That is a network namespace.
07The RuntimeDefault seccomp profile…
Correct — A sane baseline that many workloads run under unmodified.
Incorrect — That is Unconfined, the risky default historically.
Incorrect — That would break every process.
Incorrect — It applies to the whole process.
08AppArmor and SELinux are both…
Incorrect — They are Mandatory Access Control, not network filters.
Correct — AppArmor is path-based; SELinux is label/type-based.
Incorrect — They confine runtimes; they are not runtimes.
Incorrect — That is seccomp; MAC operates at LSM hooks.
09SELinux differs from AppArmor primarily in that it…
Correct — Label-based policy (svirt/MCS) isolates containers on RHEL.
Incorrect — That is seccomp.
Incorrect — Namespaces are a separate kernel feature.
Incorrect — MAC is authorization, not encryption.
10A hardened container securityContext typically sets…
Correct — Minimize identity, writability, privilege, and syscall surface together.
Incorrect — Privileged mode removes nearly all isolation.
Incorrect — You want that false to block setuid escalation.
Incorrect — Sharing host namespaces weakens isolation.
11readOnlyRootFilesystem helps because…
Incorrect — It prevents writes, not encrypts.
Correct — Combine with tmpfs for the few writable paths needed.
Incorrect — Not a performance feature.
Incorrect — Unrelated to logging.
12Defense in depth for containers means…
Correct — No single control is perfect; overlapping controls contain a bypass.
Incorrect — Scanning is build-time; runtime needs its own controls.
Incorrect — Privileged undermines the isolation you are monitoring.
Incorrect — Shared-kernel isolation is not absolute; layer controls.
12 questions · explanations appear as you answer
Falco & runtime detection
12 questions
01Falco is…
Incorrect — That is build-time (Trivy/Grype); Falco is runtime.
Correct — It alerts on things like a shell spawned in a container.
Incorrect — That is Cilium/Calico.
Incorrect — Unrelated to secrets.
02A Falco rule is essentially…
Correct — e.g. spawned_process and container and proc.name=bash → Warning.
Incorrect — It evaluates syscall events, not packets primarily.
Incorrect — Unrelated to RBAC.
Incorrect — Rules are event-driven, not scheduled.
03Falco macros and lists exist to…
Correct — DRY rule-writing: define once, reference in many rules.
Incorrect — They are for reuse, not encryption.
Incorrect — Falco is event-driven.
Incorrect — They are rule-authoring constructs.
04A canonical Falco detection is…
Incorrect — That is metrics/monitoring, not Falco’s core.
Correct — Strong signal of hands-on-keyboard intrusion in prod.
Incorrect — That is app-level, not syscall-based.
Incorrect — Performance, not security.
05The main operational challenge with Falco is…
Correct — Untuned rules fire on normal ops; tuning is essential.
Incorrect — Seeing syscalls is exactly what it does.
Incorrect — It is Linux-focused.
Incorrect — Falco detects; it does not block by default.
06The right way to silence a benign Falco alert is to…
Incorrect — That removes all detection.
Correct — Tune precisely rather than turning rules off wholesale.
Incorrect — That breaks event capture.
Incorrect — Unmonitored alerts defeat the tool.
07Falcosidekick is used to…
Correct — It routes events into your response pipeline.
Incorrect — It routes output; it does not author rules.
Incorrect — Unrelated to scanning.
Incorrect — It is an output router.
08Falco Talon (or a sidekick→function flow) enables…
Incorrect — It is about response actions, not encryption.
Correct — Turning detection into containment programmatically.
Incorrect — Unrelated to build.
Incorrect — Unrelated to secrets.
09Falco detects at the syscall layer, which means it catches…
Correct — Runtime and scanning are complementary, not redundant.
Incorrect — That is scanning; Falco is behavioral.
Incorrect — It sees process/file/network syscalls.
Incorrect — It is container-aware by design.
10Running Falco as a DaemonSet ensures…
Correct — Node-level coverage catches activity in any pod scheduled there.
Incorrect — A single pod cannot see other nodes’ kernels.
Incorrect — You want it on worker nodes running workloads.
Incorrect — Different control entirely.
11A well-tuned rule set is judged by…
Incorrect — Volume is not the goal; signal is.
Correct — Precision keeps responders trusting the queue.
Incorrect — More rules without tuning means more noise.
Incorrect — Efficiency matters but is not the detection measure.
12Falco plugins extend it to sources beyond syscalls, such as…
Correct — One detection engine across kernel and cloud/audit events.
Incorrect — Not a plugin source.
Incorrect — That is scanning, not a Falco source.
Incorrect — Irrelevant.
12 questions · explanations appear as you answer
Enforcement: Tetragon & Cilium
12 questions
01Tetragon differs from Falco in that it can…
Correct — Detection plus enforcement, not detection-only.
Incorrect — It is runtime, not a scanner.
Incorrect — It is eBPF/Linux.
Incorrect — That is Cilium; Tetragon is observability/enforcement.
02Tetragon policies are expressed as…
Incorrect — They are Kubernetes CRDs, not iptables.
Correct — Declarative, Kubernetes-native runtime policy.
Incorrect — Unrelated to build.
Incorrect — Different project and schema.
03The advantage of in-kernel enforcement over userspace detection is…
Correct — A userspace agent may react after the damage is done.
Incorrect — Storage is not the point.
Incorrect — It is a kernel technology.
Incorrect — Unrelated to encryption.
04Cilium is primarily…
Incorrect — It is a CNI/networking + security platform.
Correct — L3–L7 policy, Hubble visibility, kube-proxy replacement.
Incorrect — Unrelated to scanning.
Incorrect — Unrelated to CI.
05Cilium network policies are identity-based, meaning they…
Correct — Policy follows the workload as pods churn and reschedule.
Incorrect — They use security identities derived from labels.
Incorrect — The opposite — they avoid IP brittleness.
Incorrect — They span L3–L7.
06Cilium can enforce L7 policy such as…
Incorrect — That is L3/L4; Cilium also does L7.
Correct — Application-aware policy, not just port-level.
Incorrect — Unrelated to networking.
Incorrect — That is seccomp/Tetragon.
07Hubble provides…
Correct — Service maps and flow logs without app instrumentation.
Incorrect — That is supply-chain.
Incorrect — Unrelated.
Incorrect — Unrelated.
08Cilium transparent encryption (WireGuard/IPsec) provides…
Incorrect — It encrypts pod-to-pod traffic in transit.
Correct — East-west confidentiality transparently.
Incorrect — It works below the app layer.
Incorrect — Unrelated to images.
09A default-deny Cilium network policy…
Correct — Zero-trust east-west: open only the flows you declare.
Incorrect — That is the insecure default it replaces.
Incorrect — It governs east-west pod traffic too.
Incorrect — You allow DNS explicitly; it is not disabled.
10Combining Tetragon (process) with Cilium (network) gives you…
Correct — Kill a malicious process and constrain what it can reach.
Incorrect — Both are runtime.
Incorrect — Different control plane.
Incorrect — They add enforcement and network identity Falco lacks.
11The tradeoff of enforcement (kill/deny) vs detection (alert) is…
Incorrect — A bad enforcement rule can break legitimate workloads.
Correct — Start in observe/alert, validate, then enforce in waves.
Incorrect — Detection is passive; enforcement carries the disruption risk.
Incorrect — One acts; one only observes.
12Rolling out enforcement safely mirrors policy rollout elsewhere:
Correct — Avoid an outage from a policy that is too aggressive on day one.
Incorrect — That risks breaking many workloads at once.
Incorrect — That is the outage you are trying to avoid.
Incorrect — Enforcement is valuable when rolled out carefully.
12 questions · explanations appear as you answer
Container escapes & IR
12 questions
01A privileged container is dangerous because it…
Correct — privileged: true is close to running on the host.
Incorrect — Performance is not the concern.
Incorrect — It has more access, not less.
Incorrect — Privilege has nothing to do with encryption.
02Mounting the host Docker socket (/var/run/docker.sock) into a container…
Correct — Control of the daemon is control of the host.
Incorrect — Even read access to the socket enables takeover.
Incorrect — It exposes the full container API.
Incorrect — Unrelated to encryption.
03A hostPath mount of / (or the kubelet dir) enables escape by…
Incorrect — It is an escape vector, not performance.
Correct — Host filesystem access is a direct path off the container.
Incorrect — Unrelated to networking.
Incorrect — Broad hostPath is a classic escape enabler.
04CAP_SYS_ADMIN can enable escape because it allows…
Correct — It re-enables much of what container isolation removed.
Incorrect — That is CAP_NET_BIND_SERVICE.
Incorrect — That is CAP_CHOWN.
Incorrect — It is one of the most abusable capabilities.
05The runc CVE-2024-21626 ("Leaky Vessels") class of bug shows that…
Incorrect — Runtime CVEs prove otherwise.
Correct — Patch runtimes promptly; the boundary is software with bugs.
Incorrect — Runtime bugs can escape from unprivileged ones too.
Incorrect — They exploit runtime/kernel bugs, no rebuild needed.
06Keeping the host kernel patched matters for containers because…
Correct — One kernel bug can undermine every container on the host.
Incorrect — They share the host kernel — that is the point.
Incorrect — Unrelated; patching complements seccomp.
Incorrect — Unrelated to encryption.
07Runtime tools detect an escape attempt by spotting…
Correct — The escape technique produces kernel activity a probe can catch.
Incorrect — That is app-level, not escape behavior.
Incorrect — A weak, indirect signal.
Incorrect — Escapes generate detectable kernel activity.
08gVisor and Kata Containers reduce escape risk by…
Incorrect — That is Trivy/Grype, a different layer.
Correct — They shrink the shared-kernel attack surface for untrusted workloads.
Incorrect — Unrelated to secrets.
Incorrect — Different control plane.
09On detecting a likely container escape, an early response is to…
Correct — Contain the blast radius and preserve evidence before cleanup.
Incorrect — Destroying everything is not measured containment.
Incorrect — An active escape is an incident in progress.
Incorrect — A restart discards evidence and may not evict the attacker.
10Preserving forensic state for a compromised node means…
Incorrect — Reimaging destroys the evidence you need.
Correct — Capture first, then remediate — mirrors cloud IR.
Incorrect — A reboot can wipe volatile evidence.
Incorrect — That worsens exposure.
11Hunting persistence after a container compromise means looking for…
Correct — Attackers persist in the cluster and on the node, not just the pod.
Incorrect — A competent attacker plants a second foothold.
Incorrect — Metrics are not persistence indicators.
Incorrect — Not where container persistence hides.
12The best defense against escapes overall is…
Correct — Remove the enablers, patch the bugs, and watch for the rest.
Incorrect — No one control is sufficient; layer them.
Incorrect — Build-time scanning cannot stop runtime escape.
Incorrect — Shared-kernel isolation is not absolute.
12 questions · explanations appear as you answer