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

Question 1

Which THREE of the following are recommended incident response steps when a container is compromised?

Accepted Answer

Copy the container's filesystem using kubectl cp for offline analysis. Option B is correct because copying the container's filesystem with kubectl cp preserves volatile evidence for offline forensic analysis before the container is destroyed or restarted. Option C is correct because kubectl logs captures the container's stdout/stderr output, which may contain indicators of compromise, attacker commands, or error traces useful for scoping the incident. Option D is correct because applying a NetworkPolicy to the pod isolates it from other workloads, limiting lateral movement and exfiltration while still keeping the container alive for investigation. Option A is wrong because ignoring a compromise allows the attacker to persist and expand access. Option E is wrong because immediately terminating the pod destroys volatile evidence such as memory, running processes, and network connections, and may trigger automated redeployment that erases the compromised instance before it can be examined.

Answer

Ignore the incident and monitor for further activity

Answer

Immediately terminate the pod to contain the threat

Question 2

Which TWO tools can be used to directly interact with the container runtime (without going through the Kubernetes API) for troubleshooting?

Accepted Answer

ctr. Options C and D are correct because both ctr and crictl are command-line tools that talk directly to the container runtime rather than to the Kubernetes API server. ctr is the CLI shipped with containerd and interacts with the containerd daemon (via its socket, e.g. /run/containerd/containerd.sock) to list, inspect, and manage containers and images. crictl is a CRI-compatible CLI that connects to any CRI-compliant runtime endpoint (containerd or CRI-O) using the --runtime-endpoint flag, making it ideal for node-level troubleshooting when the API server or kubelet is unavailable. The unmarked options do not belong: kubelet (A) is the node agent that itself calls the CRI, not a tool for directly interacting with the runtime; docker (B) is a higher-level engine/CLI that is not the Kubernetes CRI runtime in modern clusters; and kubectl (E) communicates exclusively through the Kubernetes API server, which the question explicitly excludes.

Answer

kubelet

Answer

docker

Answer

kubectl

Question 3

You need to configure Kubernetes audit logging to log all requests at the Metadata level for a specific namespace. Which audit policy level should you use?

Accepted Answer

Metadata. The Metadata audit level logs request metadata (who, when, what resource, verb, etc.) but not the request or response body. This is exactly what is needed to log all requests at the Metadata level for a specific namespace. The other levels either log too much (Request, RequestResponse) or nothing (None).

Answer

Request

Answer

None

Answer

RequestResponse

Question 4

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

Accepted Answer

crictl logs. crictl logs <container-id> displays logs from a container. crictl ps lists containers, crictl exec runs a command in a container, and crictl inspect shows detailed container information.

Answer

crictl ps

Answer

crictl exec

Answer

crictl inspect

Question 5

A Falco rule is triggered when a shell is spawned inside a container. Which syscall is typically used to detect shell execution?

Accepted Answer

execve. Falco detects shell execution by monitoring the `execve` syscall, which is the standard Linux system call used to execute a new program. When a shell like `/bin/bash` or `/sh` is spawned inside a container, the kernel invokes `execve` to replace the current process image with the shell binary. Falco's rule engine matches this syscall against its default rule set (e.g., `run_shell_untrusted`) to trigger an alert.

Answer

clone

Answer

open

Answer

read

Question 6

You are investigating a compromised pod. You suspect the attacker used 'kubectl exec' to gain shell access. Which command can you use to check the audit logs for exec events?

Accepted Answer

kubectl get events. None of the listed commands can be used to check Kubernetes audit logs for exec events. Kubernetes audit logs are stored on control plane nodes, commonly at /var/log/kubernetes/audit/audit.log or in the configured audit backend, and are not exposed via 'kubectl get events', 'kubectl logs --audit', or 'kubectl describe pod'. 'kubectl exec' runs inside a container and cannot read control-plane audit files unless a hostPath mount is explicitly configured. To inspect exec audit events, access the control plane and use host-level tools such as 'grep exec /var/log/kubernetes/audit/audit.log' according to your audit log configuration.

Answer

kubectl exec -it pod-name -- cat /var/log/audit/audit.log

Answer

kubectl logs --audit

Answer

kubectl describe pod pod-name

Question 7

You have deployed a DaemonSet to run a logging agent on every node. After an update, the new pods are stuck in 'Pending' state. You run 'kubectl describe pod ds-pod-xxxxx' and see '0/3 nodes are available: 3 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate'. What is the MOST likely cause?

Accepted Answer

The DaemonSet does not have tolerations for the node taints. The error message indicates that the pod cannot be scheduled because all three nodes have a taint (specifically `node-role.kubernetes.io/master`), and the DaemonSet's pod template does not include a corresponding toleration. By default, control-plane nodes are tainted to prevent general workloads from running on them, so a DaemonSet intended to run on all nodes must include tolerations for these taints. Without tolerations, the scheduler will not place the pod on tainted nodes, leaving it in Pending state.

Answer

The DaemonSet has a nodeSelector that doesn't match any nodes

Answer

The DaemonSet uses hostNetwork which conflicts with existing pods

Answer

The nodes are cordoned

Question 8

Which Falco rule condition would detect an attempt to read the /etc/shadow file in a container?

Accepted Answer

evt.type=open and fd.name=/etc/shadow. The Falco rule condition `evt.type=open and fd.name=/etc/shadow` specifically detects the `open` system call targeting the `/etc/shadow` file. Reading a file in Linux typically involves the `open` syscall (with flags like O_RDONLY) followed by `read`, but Falco's `open` event captures the initial access attempt, making it the standard way to detect file reads. This matches the requirement to detect an attempt to read `/etc/shadow` in a container.

Answer

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

Answer

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

Answer

evt.type=execve and proc.name=shadow

Question 9

You want to ensure that a container's root filesystem is immutable. Which field in the Pod spec should you set?

Accepted Answer

spec.containers[].securityContext.readOnlyRootFilesystem. The correct field to make a container's root filesystem immutable is 'spec.containers[].securityContext.readOnlyRootFilesystem'. When set to true, this mounts the container's root filesystem as read-only, preventing any writes to the filesystem. This is a key security measure to prevent runtime modifications.

Answer

spec.containers[].securityContext.privileged

Answer

spec.hostNetwork

Answer

spec.containers[].volumeMounts[].readOnly

Question 10

You need to configure a NetworkPolicy that allows egress traffic only to an external database at IP 10.0.0.5 on port 5432, and denies all other egress. Which policy BEST achieves this?

Accepted Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: db-egress
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.5/32
    ports:
    - port: 5432. The correct policy uses an ipBlock with cidr 10.0.0.5/32 and port 5432, which precisely allows egress only to that single external database IP on the PostgreSQL port. Because policyTypes includes Egress and the egress rule is the only one, all other egress traffic is implicitly denied. This matches the requirement exactly.

Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: db-egress
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0
    ports:
    - port: 5432

Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: db-egress
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: db

Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: db-egress
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress: []

Question 11

You have a pod that is in CrashLoopBackOff. You want to inspect the logs from the previous instance of the container. Which flag should you use with kubectl logs?

Accepted Answer

--previous. When a pod is in CrashLoopBackOff, the current container instance has crashed and restarted, so its logs may be empty or not reflect the crash. The `--previous` flag (or `-p`) tells `kubectl logs` to show logs from the previous instance of the container, which contains the output from the crashed process. This is the correct way to retrieve crash-related logs without waiting for the new instance to produce output.

Answer

--tail

Answer

--all-containers

Answer

--since

Question 12

Which THREE of the following are recommended steps during incident response for a compromised pod?

Accepted Answer

Apply a NetworkPolicy to isolate the pod. Option A is correct because applying a NetworkPolicy to the compromised pod isolates it from other workloads, blocking lateral movement and command-and-control traffic while keeping the pod alive for analysis. Option D is correct because using kubectl exec to collect running processes and network connections captures volatile forensic evidence (e.g., process lists, sockets) that would be lost if the pod were terminated. Option E is correct because preserving the pod and its logs maintains the evidence chain for investigation, including container logs and cluster events needed to determine the attack's scope and root cause. Option B is not recommended because deleting and recreating the pod destroys volatile evidence and may allow the attacker to re-establish persistence. Option C is not recommended because immediately deleting the pod erases forensic artifacts and prevents understanding the compromise, even though it might stop the immediate attack.

Answer

Restart the pod by deleting and recreating it

Answer

Delete the pod immediately to stop the attack

Question 13

Which TWO tools can be used to directly interact with a container runtime on a Kubernetes node without using kubectl?

Accepted Answer

ctr. crictl and ctr are CLI tools for interacting with CRI-compatible container runtimes. kubectl and docker are not available on nodes by default; docker is not always the runtime.

Answer

systemctl

Answer

kubectl

Answer

docker

Question 14

A security team wants to detect any attempt to read the /etc/shadow file inside a container. Which Falco rule condition would trigger an alert for such an event?

Accepted Answer

evt.type=open and fd.name=/etc/shadow and evt.arg.flags contains O_RDONLY. Reading /etc/shadow requires the open syscall with the O_RDONLY flag. Falco's rule condition `evt.type=open and fd.name=/etc/shadow and evt.arg.flags contains O_RDONLY` precisely matches an attempt to open the file for reading, which is the event that should trigger an alert for unauthorized read access.

Answer

evt.type=open and proc.name=bash and fd.name=/etc/shadow

Answer

evt.type=open and fd.name contains /etc

Answer

evt.type=open and fd.name=/etc/shadow and evt.arg.flags contains O_WRONLY

Question 15

You want to run crictl to list all running containers on a node. Which command should you execute?

Accepted Answer

crictl ps. The crictl ps command lists running containers on a node by querying the CRI-compatible container runtime (containerd or CRI-O). It is the direct equivalent of 'docker ps' in the CRI world and is the correct command to enumerate running containers.

Answer

crictl stats

Answer

crictl images

Answer

crictl pods