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

Question 1

You are investigating a pod that is suspected of being compromised. You need to preserve the container's filesystem for forensic analysis. Which `crictl` command should you use to export the container's filesystem as a tar archive?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

crictl export <container-id>. `crictl export` is the dedicated command to export a container's filesystem as a tar archive, preserving its state for forensic analysis. This command creates a snapshot of the container's root filesystem, which is essential for offline investigation without altering the running container.

Answer

crictl logs <container-id>

Answer

crictl inspect <container-id>

Answer

crictl exec <container-id> tar cvf /tmp/fs.tar /

Question 2

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 3

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 4

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 5

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 6

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 7

A Falco rule has priority `WARNING` and output: `Sensitive file opened (user=%user.name command=%proc.cmdline file=%fd.name)`. The rule is triggering correctly. You want to reduce noise from legitimate administrative activity. What is the best approach?

Accepted Answer

Add an exception to the rule to exclude known admin commands. Falco's exception mechanism allows you to define specific conditions (e.g., admin commands like `vi` or `kubectl exec`) that suppress the rule's alert without altering the core rule logic. This preserves the rule's detection capability for non-exempted activity while reducing noise from legitimate administrative actions. Exceptions are the recommended approach in Falco for fine-grained noise reduction without disabling or broadly weakening the rule.

Answer

Modify the rule condition to add `and not user.name in (admin, root)`

Answer

Change the rule priority to `INFO`

Answer

Disable the rule

Question 8

You need to ensure that all containers in a pod cannot write to their root filesystem except for a specific directory `/data`. You set `securityContext.readOnlyRootFilesystem: true` and mount an emptyDir volume at `/data`. However, the container still cannot write to `/data`. What is the most likely cause?

Accepted Answer

The container user does not have write permission on the emptyDir volume. Even with `readOnlyRootFilesystem: true` and an emptyDir volume mounted at `/data`, the container process must have write permission on the mount point. By default, emptyDir volumes are owned by root (UID 0) with permissions 755, so a non-root container user cannot write to it. The security context only makes the root filesystem read-only; it does not grant write access to volumes.

Answer

The emptyDir volume is not mounted correctly in the pod spec

Answer

The emptyDir volume is using a read-only storage class

Answer

readOnlyRootFilesystem also applies to mounted volumes

Question 9

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 10

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 11

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

Question 12

Which TWO are valid stages in a Kubernetes audit event? (Select 2)

Accepted Answer

RequestReceived. 'RequestReceived' is one of the defined stages in the Kubernetes audit event lifecycle. When an audit policy is configured, the kube-apiserver records an audit event at the 'RequestReceived' stage after it has received the request but before it has been processed by the admission controllers or the resource handler. This stage captures the raw request as it arrives.

Answer

PreProcessing

Answer

None

Answer

PostProcessing

Question 13

Which kubectl command can be used to exec into a running container for forensic analysis during an incident response?

Accepted Answer

kubectl exec -it -- /bin/sh. `kubectl exec -it -- /bin/sh` allows you to start an interactive shell session inside a running container, which is essential for live forensic analysis during incident response. This command uses the Kubernetes API to execute a process (e.g., /bin/sh) in the container's namespaces, enabling you to inspect running processes, file systems, network connections, and memory artifacts without stopping the container.

Answer

kubectl run --stdin --tty --image=busybox

Answer

kubectl logs <pod>

Answer

kubectl attach <pod>

Question 14

An administrator runs 'falco --list' and sees many default rules. What is the correct way to load a custom Falco rules file?

Accepted Answer

falco -r /path/to/rules.yaml. The `-r` flag (short for `--rules`) is the standard Falco command-line option to specify a custom rules file. When you run `falco -r /path/to/rules.yaml`, Falco loads the rules from that YAML file instead of or in addition to the default rules. The `--list` flag shows all loaded rules, so using `-r` ensures your custom rules are included in that list.

Answer

falco --load /path/to/rules.yaml

Answer

falco --rules /path/to/rules.yaml

Answer

falco --config /path/to/rules.yaml

Question 15

A security team wants to detect any attempt to read /etc/shadow from within a container using Falco. Which condition in a Falco rule would match this behavior?

Accepted Answer

evt.type=open and fd.name=/etc/shadow. Reading /etc/shadow from a container requires opening the file first, so the Falco rule must match the `open` system call (evt.type=open) and the exact file path (fd.name=/etc/shadow). The `open` syscall is the entry point for file access, and Falco captures it before any read or write occurs, making it the appropriate event type to detect an attempt to read the shadow file.

Answer

proc.name contains "shadow" and evt.type=read

Answer

evt.type=read and fd.name contains "shadow"

Answer

container and fd.name=/etc/shadow