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

Question 1

You suspect a container has been compromised and want to perform forensics using kubectl exec. Which command safely collects the container's process list without affecting the container?

Accepted Answer

kubectl exec -- ps aux. The command `kubectl exec -- ps aux` runs the `ps` process inside the container's existing namespaces without starting a new container or modifying its state. It simply lists running processes, which is a read-only operation that does not alter the container's filesystem, network, or process tree. This makes it safe for forensic collection because it avoids introducing new processes that could overwrite evidence or trigger defensive mechanisms. The `--` separates kubectl arguments from the command to execute, ensuring `ps aux` runs inside the container.

Answer

kubectl attach <pod>

Answer

kubectl cp /proc <pod>:/tmp

Answer

kubectl exec -it <pod> -- /bin/sh

Question 2

You want to preserve evidence from a compromised pod. Which command should you use to copy the entire container filesystem to a safe location?

Accepted Answer

kubectl cp :/ /tmp/evidence. The command 'kubectl cp :/ /tmp/evidence' copies the entire container filesystem from the pod to a local directory. This is the correct way to preserve evidence from a compromised pod using kubectl. Other commands either do not exist or do not copy the entire filesystem.

Answer

crictl export <container-id> /tmp/evidence.tar

Answer

kubectl exec <pod> -- tar czf - / > /tmp/evidence.tar.gz

Answer

kubectl logs <pod> > /tmp/evidence.log

Question 3

Which TWO crictl commands can be used to inspect a running container?

Accepted Answer

crictl logs <container-id>. crictl logs shows logs, crictl exec runs a command in the container.

Answer

crictl run <image>

Answer

crictl create <pod-config>

Answer

crictl stats <container-id>

Question 4

You are investigating a compromised pod. You need to capture the contents of a file in the container without modifying the container. Which kubectl command should you use?

Accepted Answer

kubectl cp <pod>:/etc/passwd ./passwd. `kubectl cp` copies files from a container to the local filesystem. Although it does execute a process inside the container (typically tar) to perform the copy, it does not alter the file contents and is the standard method for forensic file extraction. In contrast, `kubectl exec` runs an arbitrary command (e.g., cat) that creates a new process, which is more invasive and could interfere with the container's state. Therefore, `kubectl cp` is the preferred choice when minimal modification is required.

Answer

kubectl logs <pod>

Answer

kubectl exec <pod> -- cat /etc/passwd

Answer

kubectl describe pod <pod>

Question 5

A Falco rule triggers on 'Write below etc' and you see an alert about a process writing to /etc/shadow. Which syscall is Falco most likely using to detect this?

Accepted Answer

write. Falco detects file writes by monitoring the write syscall (and its variants like pwrite). When a process writes to /etc/shadow, the write syscall is invoked, and Falco's rule 'Write below etc' triggers on write or similar syscalls. Thus, write is the most likely syscall used.

Answer

open

Answer

chmod

Answer

openat

Question 6

You want to configure an audit policy to log all requests to the 'secrets' resource with the body at the 'RequestResponse' level. Other resources should be logged at 'Metadata' level. Which audit policy YAML snippet is correct?

Accepted Answer

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: RequestResponse
  resources:
  - group: ""
    resources: ["secrets"]
- level: Metadata
  resources:
  - group: ""
    resources: ["*"]. It includes the required apiVersion and kind fields (audit.k8s.io/v1 and Policy) and correctly defines two rules: one for secrets at RequestResponse level with an empty group, and one for all other resources at Metadata level. Option D is incorrect because it omits the apiVersion and kind fields; while the rules structure is valid, a complete audit policy object must include those fields to be applied in Kubernetes. Option A uses 'Body' which is not a valid audit level (must be RequestResponse). Option C uses 'policies' as the top-level key instead of 'rules', which is invalid.

Answer

rules:
- level: Body
  resources: ["secrets"]
- level: Metadata
  resources: ["*"]

Answer

policies:
- level: RequestResponse
  resources: ["secrets"]
- level: Metadata
  resources: ["*"]

Answer

rules:
- level: RequestResponse
  resources:
  - group: ""
    resources: ["secrets"]
- level: Metadata
  resources:
  - group: ""
    resources: ["*"]

Question 7

During a security incident, you need to snapshot the processes running inside a container without using kubectl exec. Which crictl command sequence can you use?

Accepted Answer

crictl ps and then crictl exec ps aux. The command sequence crictl ps and then crictl exec ps aux allows you to list running containers and then execute the ps aux command inside the container to snapshot running processes without using kubectl exec. This uses the container runtime's CLI directly.

Answer

crictl pods and then crictl ps -a

Answer

crictl images and then crictl run <image>

Answer

crictl ps and then crictl inspect <container-id>

Question 8

A Falco rule has the condition: 'evt.type=open and fd.name contains /etc/shadow and container.id != host'. What is being detected?

Accepted Answer

A container process opening /etc/shadow. The rule detects open syscalls on files whose name contains '/etc/shadow', occurring outside the host (i.e., inside containers). This indicates a container process is opening the shadow file.

Answer

Any process opening /etc/shadow on the host

Answer

A container process writing to /etc/shadow

Answer

A process reading /etc/passwd

Question 9

You want to detect any attempt to run a shell inside a container that is not running as root. Which Falco condition would you use?

Accepted Answer

evt.type=execve and proc.name in (bash, sh) and container.id != host and user.name != root. The condition 'evt.type=execve and proc.name in (bash, sh) and container.id != host and user.name != root' detects shell execution inside a container where the effective user is not root. 'proc.name' matches the process name, 'container.id != host' excludes host processes, and 'user.name != root' filters for non-root users.

Answer

evt.type=execve and proc.aname in (bash, sh) and container.id != host and user.name != root

Answer

evt.type=execve and proc.name in (bash, sh) and container.id != host

Answer

evt.type=execve and proc.name in (bash, sh) and container.id != host and user.name = root

Question 10

Which TWO of the following are valid audit stages in Kubernetes?

Accepted Answer

Panic. Kubernetes audit stages include RequestReceived, ResponseStarted, ResponseComplete, and Panic. Among the given options, RequestReceived (D), ResponseStarted (C), and Panic (B) are all valid stages. Options A (ResponseReceived) and E (RequestSent) are not standard stages.

Answer

ResponseReceived

Answer

RequestSent

Question 11

Which THREE of the following are recommended steps when responding to a compromised pod?

Accepted Answer

Scale the deployment replicas to zero to stop the pod. Option B is correct because scaling the deployment replicas to zero halts the running compromised pod (and any replacements) without destroying forensic evidence, allowing the workload to be stopped while the pod object and its logs remain available for investigation. Option D is correct because applying a NetworkPolicy that denies all egress isolates the pod, preventing it from reaching command-and-control servers, exfiltrating data, or pivoting to other workloads while you investigate. Option E is correct because using kubectl cp to capture a snapshot of the container's filesystem preserves volatile evidence such as malware binaries, configuration files, and artifacts that would be lost if the pod were deleted. Option A is not recommended because immediately deleting the pod destroys forensic evidence and may trigger the ReplicaSet to recreate the pod, potentially re-establishing the compromise. Option C is not a recommended primary step because running kubectl exec into a compromised container can alter its state, tip off the attacker, and is unreliable if the container lacks a shell or has been tampered with.

Answer

Immediately delete the pod to stop the attack

Answer

Run kubectl exec to investigate the container's state

Question 12

A security engineer wants to detect any attempt to spawn a shell inside a container. Which Falco rule condition would trigger on a shell being spawned in a container (e.g., /bin/bash or /bin/sh)?

Accepted Answer

spawned_process and container and proc.name in (bash, sh, zsh). Falco's rule language uses the 'spawned_process' macro, which expands to evt.type in (execve, execveat) and evt.dir=<, to detect process execution. Combining it with the 'container' field restricts the match to containerized workloads, and 'proc.name in (bash, sh, zsh)' matches the shell binary names. This is the canonical Falco condition for detecting a shell spawned inside a container.

Answer

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

Answer

evt.type=execve and container and proc.name in (bash, sh, zsh)

Answer

proc.name = bash and container

Question 13

You need to enable Kubernetes audit logging with the following requirements: log all requests at the 'RequestResponse' level, but only for successful responses. Which audit stage should you specify in the policy?

Accepted Answer

ResponseComplete. To capture both request and response for successful requests, you want events after the response is complete. The 'ResponseComplete' stage fires after the response is sent. 'RequestResponse' is not a stage; it's a level.

Answer

Panic

Answer

ResponseStarted

Answer

RequestReceived

Question 14

A security policy requires that all pods in a namespace must run with a read-only root filesystem. Which admission controller can enforce this?

Accepted Answer

ValidatingAdmissionPolicy. ValidatingAdmissionPolicy is a built-in admission controller that uses CEL to validate pod security contexts, such as readOnlyRootFilesystem, without external webhooks. MutatingAdmissionWebhook is also a built-in admission controller but relies on an external webhook service to enforce policies, making it less direct. PodSecurityPolicy is deprecated, and ResourceQuota does not handle security settings. Therefore, ValidatingAdmissionPolicy is the correct answer.

Answer

ResourceQuota

Answer

MutatingAdmissionWebhook

Answer

PodSecurityPolicy

Question 15

Which THREE of the following are valid Falco rule priorities? (Select THREE.)

Accepted Answer

CRITICAL. Falco rule priorities follow the syslog severity scale, and CRITICAL (A) is the highest-severity level Falco supports, used for the most urgent security events. EMERGENCY (B) and ALERT (C) are also valid Falco priorities drawn from that same syslog set, sitting above CRITICAL in the standard severity ordering. The remaining options do not belong: HIGH (D) and MEDIUM (E) are not part of Falco's priority enumeration, which instead uses levels such as EMERGENCY, ALERT, CRITICAL, ERROR, WARNING, NOTICE, INFORMATIONAL, and DEBUG.

Answer

HIGH

Answer

MEDIUM