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

Question 1

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 2

To isolate a compromised pod and prevent all incoming and outgoing traffic, which Kubernetes resource should you use?

Accepted Answer

NetworkPolicy with spec.podSelector: {} and spec.policyTypes: [Ingress, Egress]. A NetworkPolicy with `spec.podSelector: {}` selects all pods in the namespace, and `spec.policyTypes: [Ingress, Egress]` with no rules under `ingress` or `egress` defaults to denying all traffic. This effectively isolates the compromised pod by blocking all incoming and outgoing network traffic at the CNI level.

Answer

ResourceQuota

Answer

PodSecurityPolicy

Answer

LimitRange

Question 3

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 4

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 5

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 6

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 7

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 8

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 9

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. Falco can detect a shell spawning by checking if the process name (proc.name) is 'bash' and the container context is true. This directly identifies when a shell process is started inside a container, which is a common indicator of unauthorized access or malicious activity. Option C is correct because Falco's 'spawned_process' macro filters for new process creation events, and combining it with a container filter (e.g., 'container.id != host') allows detection of any shell spawned within a container.

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 10

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. The `--audit-policy-file` flag on the kube-apiserver is required to define which events should be recorded and how they should be processed. Without this flag, no audit policy is loaded, and the apiserver will not perform any audit logging, even if other audit flags are set.

B: other...

Answer

The --audit-dynamic-configuration flag

Answer

An audit webhook backend

Question 11

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

Question 12

A security team wants to detect any attempt to open /etc/shadow in a container. Which Falco rule condition field is MOST appropriate?

Accepted Answer

evt.type in (open, openat) and fd.name=/etc/shadow. Falco rules detect system calls, and opening /etc/shadow requires either the `open` or `openat` syscall. By specifying `evt.type in (open, openat)` combined with `fd.name=/etc/shadow`, the rule precisely matches the syscall event that opens the file, which is the most direct way to detect an attempt to access it. This avoids false positives from other syscalls like `read` that might occur after the file is already opened.

Answer

proc.name contains 'shadow'

Answer

container.id != host and fd.name=/etc/shadow

Answer

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

Question 13

An admin runs 'crictl ps' on a node and sees multiple containers. Which command should they use to view the logs of a specific container?

Accepted Answer

crictl logs <container-id>. `crictl logs` is the dedicated command to retrieve container logs from the container runtime interface (CRI), fetching stdout and stderr output from the specified container, which is essential for debugging and monitoring containerized workloads on a Kubernetes node.

Answer

crictl exec <container-id> logs

Answer

crictl inspect <container-id>

Answer

crictl ps -a <container-id>

Question 14

A pod is running in the 'default' namespace with a container that has an immutable root filesystem (readOnlyRootFilesystem: true). The application writes logs to /var/log/app.log. What will happen?

Accepted Answer

The write to /var/log/app.log fails, and the container may crash or log an error. When a container is configured with `readOnlyRootFilesystem: true`, its entire root filesystem is mounted as read-only. Since `/var/log/app.log` resides within the root filesystem, any attempt to write to it will fail with a permission error. This can cause the application to crash or log an error, depending on how the application handles write failures.

Answer

The container will be automatically restarted by the kubelet

Answer

The write succeeds because logs are written to a temporary filesystem

Answer

Kubernetes will create an emptyDir volume to hold the logs

Question 15

You need to configure audit logging for the Kubernetes API server to log all requests at the Metadata level. Which flag and value should you set in the kube-apiserver configuration?

Accepted Answer

--audit-policy-file=/etc/kubernetes/audit-policy.yaml. The `--audit-policy-file` flag is required to define an audit policy that specifies what level of logging (e.g., Metadata, Request, RequestResponse) should be applied to different stages and resources. Without this flag, the API server will not load any audit policy, and no audit events will be logged, regardless of other audit flags. Setting the policy file to contain a rule with `level: Metadata` enables logging of request metadata (user, resource, verb) for all requests.

Answer

--audit-webhook-config=/etc/kubernetes/audit-webhook.yaml

Answer

--audit-log-path=/var/log/audit.log

Answer

--audit-log-format=json