CKS Monitoring, Logging and Runtime Security Practice Test 4 — 15 Questions

Question 1

Which THREE of the following are capabilities required for a Falco rule to detect privilege escalation via setuid binary execution? (Choose three.)

Accepted Answer

proc.name in (su, sudo). Option B (proc.name in (su, sudo)) is correct because Falco rules for privilege escalation commonly match the process names of privilege-changing utilities like su and sudo, which are the binaries that elevate a user's privileges. Option C (proc.uid=0) is correct because detecting privilege escalation requires checking that the resulting process runs with root UID 0, which is the definitive indicator that elevation succeeded. Option D (evt.type=execve) is correct because setuid binary execution is captured as an execve system call event, so the rule must filter on evt.type=execve to detect the execution. Option A (fd.name contains /dev/tcp) is not required because /dev/tcp is a Bash-specific pseudo-device for network redirection and is unrelated to setuid privilege escalation detection. Option E (evt.type=open) is not required because open events track file access, not the execution of a setuid binary, so they do not detect privilege escalation via execution.

Answer

fd.name contains /dev/tcp

Answer

evt.type=open

Question 2

A security engineer needs to verify that the containerd runtime on a worker node is applying the correct seccomp profile to a running pod named web-7f9c8d. Which command should the engineer run on the node to inspect the effective seccomp profile of the container process?

Accepted Answer

crictl inspect --output go-template --template '{{.info.config.linux.seccomp}}' $(crictl ps --name web -q). The container runtime, not the kubelet API, holds the effective seccomp configuration for a running container. Resolving the container ID with crictl ps and then extracting linux.seccomp via crictl inspect reveals the profile type and any localhost profile reference that containerd actually applied, which is what a security engineer must confirm when validating pod security context enforcement.

Answer

crictl inspectp web-7f9c8d

Answer

crictl inspect web-7f9c8d

Answer

kubectl exec web-7f9c8d -- cat /proc/1/status

Question 3

A security team is implementing runtime security for their Kubernetes cluster using Falco. They want to detect container escapes that involve the following behaviors: (1) a process inside a container accessing the host's process namespace, and (2) a container process mounting the host's root filesystem. Which TWO Falco rule conditions would detect these activities? (Choose two.)

Accepted Answer

evt.type=mount and container.id != host and evt.arg.source = /. Detecting container escapes requires monitoring syscalls that manipulate namespaces and mounts. The setns syscall is used to join namespaces; a container process calling setns to join the host PID namespace indicates an escape attempt. The mount syscall with a source of '/' from a container indicates an attempt to mount the host root filesystem. Both conditions are specific and target the described behaviors.

Answer

evt.type=ptrace and proc.pname in (runc, docker-runc, containerd-shim)

Answer

evt.type=mount and container.id != host and mount.source contains /

Answer

evt.type=mount and fd.name contains /host and evt.is_open_write=true

Question 4

A Kubernetes administrator needs to ensure that all container runtime activity is monitored for suspicious behavior, and alerts are generated when a container starts a shell. They have deployed Falco as a DaemonSet. Which Falco rule condition would correctly detect a shell being spawned inside a container?

Accepted Answer

evt.type=execve and proc.name in (bash, sh, zsh) and container.id != host. To detect a shell being spawned inside a container, Falco must monitor the execve syscall, which is used to execute programs. The process name should be checked against common shell binaries, and the event should be scoped to containers by verifying the container ID is not the host. This combination reliably detects shell execution within containers while avoiding host-level noise.

Answer

evt.type=open and fd.name contains /bin/sh

Answer

evt.type=clone and proc.name contains shell

Answer

evt.type=execve and proc.cmdline contains /bin/bash

Question 5

A Falco rule is written to detect when a shell is spawned inside a container. The rule condition is: `spawned_process and container and proc.name = bash`. The rule is not triggering. Which of the following is the most likely reason?

Accepted Answer

The `spawned_process` macro may not match because the process was inherited (not spawned), e.g., from an entrypoint. The `spawned_process` macro in Falco specifically matches processes that are created via `execve` or `fork` system calls. If a shell is inherited from the container's entrypoint (e.g., the container runs `bash` as PID 1 directly), it is not considered a spawned process but rather the initial process of the container. Falco's default `spawned_process` macro filters out such inherited processes, so the rule condition fails to match even though `proc.name = bash` is true.

Answer

The rule is missing `proc.name in (bash, sh, zsh)` because only bash is checked

Answer

Falco is not running with the required syscall capabilities

Answer

The priority is set to `ERROR` but the output is being filtered

Question 6

You are configuring Kubernetes audit logging. You want to log all requests to the `secrets` resource in the `kube-system` namespace at the `RequestResponse` level, while logging all other requests at the `Metadata` level. Which audit policy configuration achieves this?

Accepted Answer

rules: [- level: RequestResponse, resources: [group: '', resources: [secrets]], namespaces: [kube-system], - level: Metadata]. It defines an audit policy rule that matches requests to the `secrets` resource (core API group, empty string) in the `kube-system` namespace and sets the audit level to `RequestResponse`, which logs both the request metadata and the response body. The subsequent `- level: Metadata` rule acts as a catch-all for all other requests, logging only metadata. Audit policy rules are evaluated in order, and the first matching rule applies, so the specific rule for secrets must come before the general rule.

Answer

rules: [- level: RequestResponse, resources: [group: '', resources: [*]], - level: Metadata]

Answer

rules: [- level: Metadata, resources: [group: '', resources: [secrets]], namespaces: [kube-system], - level: RequestResponse]

Answer

rules: [- level: Metadata, resources: [group: '', resources: [secrets]], namespaces: [kube-system], omitStages: [RequestReceived], - level: RequestResponse]

Question 7

You have deployed a pod and set `securityContext.readOnlyRootFilesystem: true`. The pod is failing to start with an error about writing to `/tmp`. What is the most likely cause?

Accepted Answer

The pod is missing an emptyDir volume mounted at `/tmp`. When `securityContext.readOnlyRootFilesystem: true` is set, the container's root filesystem becomes read-only. Many applications, including those that write temporary files, expect to write to `/tmp`. Without a writable volume mounted at `/tmp`, the container fails to start because it cannot write to that directory. Mounting an `emptyDir` volume at `/tmp` provides a writable location that is ephemeral and tied to the pod's lifecycle, resolving the issue.

Answer

The `securityContext` is misspelled

Answer

The container image does not have `/tmp` directory

Answer

The container is running as a non-root user

Question 8

An administrator runs `kubectl exec -it nginx-pod -- sh` and inside the container runs `curl http://example.com`. This succeeds. However, the administrator wants to detect such outbound connections using Falco. Which syscall should Falco monitor to detect this network connection?

Accepted Answer

connect. The `connect` syscall is invoked when a client initiates an outbound TCP connection, such as when `curl http://example.com` is run inside the container. Falco monitors syscalls at the kernel level, and detecting `connect` allows it to capture the destination IP and port of the outbound request. This is the correct syscall to monitor for outbound network connections.

Answer

open

Answer

execve

Answer

bind

Question 9

You are writing a Falco rule to detect when a container tries to read the file `/etc/shadow`. Which condition in the Falco rule correctly matches this event?

Accepted Answer

evt.type=open and fd.name=/etc/shadow. Falco rules use conditions that match system calls (evt.type) and file descriptors (fd.name). The event type 'open' is the syscall used to open a file for reading, and fd.name='/etc/shadow' specifies the target file. This combination correctly detects when a container attempts to open /etc/shadow, which is the typical first step before reading it.

Answer

container.name=shadow and evt.type=open

Answer

evt.type=read and fd.name=/etc/shadow

Answer

proc.name=cat and fd.name=/etc/shadow

Question 10

You are responding to a security incident where a pod named `compromised-pod` in namespace `default` is suspected of being used for cryptocurrency mining. You need to immediately isolate the pod from the network while preserving evidence. Which command sequence should you use?

Accepted Answer

kubectl label pod compromised-pod isolated=true && kubectl apply -f networkpolicy.yaml. The correct approach is to label the pod and apply a deny-all NetworkPolicy that selects pods with that label. This immediately isolates the pod from all network traffic while preserving the pod for forensic analysis. The command sequence is: kubectl label pod compromised-pod isolated=true && kubectl apply -f networkpolicy.yaml where the networkpolicy.yaml defines an ingress/egress deny-all policy for pods with label isolated=true.

Answer

kubectl cordon <node-of-compromised-pod>

Answer

kubectl delete pod compromised-pod && kubectl describe pod compromised-pod

Answer

kubectl exec compromised-pod -- killall miner-process

Question 11

Which Kubernetes resource is used to define audit logging configuration?

Accepted Answer

A YAML file specified via `--audit-policy-file`. Kubernetes audit logging configuration is defined in a YAML file that specifies the audit policy rules, and this file is passed to the kube-apiserver via the `--audit-policy-file` command-line flag. This YAML file defines which events (e.g., requests to the API server) should be logged and at what level (e.g., Metadata, Request, RequestResponse). No other Kubernetes resource or CRD is used for this purpose.

Answer

PodSecurityPolicy

Answer

ConfigMap in kube-system

Answer

AuditPolicy CRD

Question 12

You are using `crictl` to debug a container that is not responding. Which command should you use to get the list of running containers?

Accepted Answer

crictl ps. `crictl ps` is the correct command because it lists running containers managed by the CRI-compatible runtime (e.g., containerd, CRI-O). This is analogous to `docker ps` but for the Kubernetes container runtime interface, allowing you to see container IDs, names, and statuses for debugging.

Answer

crictl pods

Answer

crictl images

Answer

crictl stats

Question 13

Which audit policy level logs the request metadata and the request body?

Accepted Answer

Request. In Kubernetes audit logging, the 'Request' level logs both the request metadata (e.g., user, timestamp, resource) and the request body (the full object sent in the API request). This level provides detailed information about the operation without including the response body, which is reserved for the 'RequestResponse' level.

Answer

None

Answer

Metadata

Answer

RequestResponse

Question 14

Which TWO of the following are valid audit stages in Kubernetes? (Select 2)

Accepted Answer

ResponseStarted. `ResponseStarted` is a valid Kubernetes audit stage that occurs when the audit handler starts sending the response to the client. This stage is part of the audit event lifecycle defined in the Kubernetes API server, capturing the moment the response headers are sent but before the body is fully transmitted.

Answer

RequestEvaluated

Answer

All of the above

Answer

ResponseSent

Question 15

Which THREE of the following are common indicators of a container compromise that Falco can detect? (Select 3)

Accepted Answer

Unexpected outbound network connections. Falco is a runtime security tool that monitors system calls and container behavior. Unexpected outbound network connections are a classic indicator of compromise, such as a reverse shell or data exfiltration, and Falco can detect these by monitoring syscalls like `connect()` and `sendto()` against a rule set that flags connections to suspicious destinations or on unusual ports.

Answer

High CPU usage

Answer

Pod restarting in a loop