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

Question 1

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 2

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 3

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 4

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

Question 5

You need to configure Kubernetes audit logging to log all requests to the 'secrets' API. Which audit policy level captures the body of the request?

Accepted Answer

Request. The 'Request' audit level logs the request metadata and the request body, which includes the body of the request. This is exactly what the question asks for. 'RequestResponse' adds the response body, which is not required per the question. Therefore, the correct answer is A.

Answer

None

Answer

RequestResponse

Answer

Metadata

Question 6

You run 'crictl ps' and see no output, but the node has running pods. What is the most likely cause?

Accepted Answer

The --runtime-endpoint flag is not set or points to the wrong socket. The `crictl ps` command queries the container runtime via the CRI (Container Runtime Interface) socket. If it returns no output while the node clearly has running pods (visible via `kubectl` or `kubelet`), the most likely cause is that the `--runtime-endpoint` flag is not set or points to the wrong socket. By default, `crictl` uses `/var/run/dockershim.sock` (deprecated) or may fall back to an incorrect path; if the actual runtime socket (e.g., `/run/containerd/containerd.sock` for containerd, or `/var/run/crio/crio.sock` for CRI-O) is not specified, the tool cannot connect to the runtime and returns an empty list.

Answer

The container runtime is not Docker

Answer

The pod uses a different container runtime than CRI-O

Answer

The containers are in a different namespace

Question 7

A Falco rule has the following condition: spawned_process and container and proc.name = bash and proc.pname != sshd. What does this rule detect?

Accepted Answer

A bash shell started in a container from a non-SSH parent process. The Falco rule condition `spawned_process and container and proc.name = bash and proc.pname != sshd` specifically detects a bash shell process that is spawned inside a container, where the parent process is not sshd. This means the bash shell was started from a non-SSH parent process, such as a shell or an application, rather than via an SSH session. The rule excludes SSH-triggered bash shells by checking that the parent process name is not sshd.

Answer

Any process named bash on the host

Answer

A bash shell started in a container via SSH

Answer

An SSH connection to a container

Question 8

You need to preserve evidence (container logs) from a compromised pod before deleting it. Which command should you run first?

Accepted Answer

kubectl logs <pod> --tail=-1 > pod.log. `kubectl logs --tail=-1` retrieves the complete log history (all lines) from the container's stdout/stderr stream, which is the primary source of container logs in Kubernetes. Redirecting this output to a file preserves the evidence before the pod is deleted, ensuring the logs are not lost when the pod is removed.

Answer

kubectl exec <pod> -- cat /var/log/*

Answer

kubectl cp <pod>:/var/log ./pod-logs

Answer

kubectl delete pod <pod>

Question 9

Which audit stage in Kubernetes audit logging captures the stage after a request is processed and before a response is sent?

Accepted Answer

ResponseStarted. The `ResponseStarted` audit stage in Kubernetes audit logging captures the stage after a request has been processed by the API server but before the response is sent to the client. This stage allows logging of the response headers and status code while the response body is still being streamed, providing visibility into the server-side processing outcome before the client receives the full payload.

Answer

ResponseComplete

Answer

Panic

Answer

RequestReceived

Question 10

Which crictl command is used to view logs from a specific container?

Accepted Answer

crictl logs . `crictl logs ` is the command used to retrieve logs from a specific container managed by a CRI-compatible runtime (e.g., containerd, CRI-O). This command fetches the container's stdout and stderr output, similar to `docker logs`, and is essential for debugging and monitoring containerized applications in Kubernetes.

Answer

crictl exec <container-id>

Answer

crictl inspect <container-id>

Answer

crictl ps

Question 11

A pod has securityContext.readOnlyRootFilesystem: true. What happens if a process inside the container tries to write to the root filesystem?

Accepted Answer

The write will fail with an error. When `securityContext.readOnlyRootFilesystem: true` is set in a Pod spec, the container's root filesystem is mounted as read-only. Any attempt by a process inside the container to write to the root filesystem (e.g., creating a file in `/` or modifying `/etc/passwd`) will be denied by the kernel's VFS layer, and the write system call will return an error (typically `EROFS` or `EACCES`). This is enforced at the kernel level, not by Kubernetes itself.

Answer

The write will succeed because tmpfs is used

Answer

The kernel will allow the write but log it

Answer

The pod will be restarted

Question 12

Which of the following is NOT a valid priority level in a Falco rule?

Accepted Answer

HIGH. Falco rules support priority levels as defined in the syslog severity standard. The valid priorities are: EMERGENCY, ALERT, CRITICAL, ERROR, WARNING, NOTICE, INFORMATIONAL, and DEBUG. 'HIGH' is not a valid priority in Falco; the correct equivalent is 'ERROR' or 'CRITICAL' depending on severity. Therefore, option B is not a valid priority level.

Answer

NOTICE

Answer

CRITICAL

Answer

WARNING

Question 13

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

Accepted Answer

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

Use the rule 'Launch Sensitive Mount'

Answer

Check if the process's parent is 'sshd'

Answer

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

Question 14

Which THREE of the following are required components to enable audit logging in Kubernetes? (Select three.)

Accepted Answer

The --audit-policy-file flag on kube-apiserver. Option A is correct because the kube-apiserver must be started with the --audit-policy-file flag pointing to the audit policy file; without this flag the API server has no policy to apply and audit logging cannot be enabled. Option B is correct because --audit-log-path tells the kube-apiserver where to write the audit log; specifying this flag is what actually enables the log backend and causes events to be recorded to a file. Option C is correct because an audit policy YAML file defines the rules (levels such as None, Metadata, Request, RequestResponse) that determine which requests are logged and at what detail, and it is the file referenced by --audit-policy-file. Option D is not required because --audit-dynamic-configuration is an optional feature that allows the audit policy to be changed at runtime without restarting the API server, not a prerequisite for basic audit logging. Option E is not required because an audit webhook backend is only one alternative sink for audit events; file-based logging via --audit-log-path satisfies the requirement without any webhook configuration.

Answer

The --audit-dynamic-configuration flag

Answer

An audit webhook backend

Question 15

Which TWO of the following are valid steps to respond to a runtime security incident where a container is suspected to be compromised? (Select two.)

Accepted Answer

Apply a NetworkPolicy that denies all ingress and egress to the pod. Applying a NetworkPolicy that denies all ingress and egress to the compromised pod immediately isolates it, preventing lateral movement and data exfiltration while preserving the pod for forensic analysis. This aligns with the incident response principle of containment before eradication, and Kubernetes NetworkPolicy uses label selectors and pod selectors to enforce eBPF/iptables-based rules at the CNI layer.

Answer

Immediately delete the pod to stop the attack

Answer

Add a taint to the node to evict the pod

Answer

Restart the kubelet on the node