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

Question 1

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?

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

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 2

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 3

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 is 'spec.containers[].securityContext.readOnlyRootFilesystem'. Setting this field to true makes the container's root filesystem read-only, effectively immutable. Option A (privileged) grants elevated capabilities but does not affect filesystem immutability. Option B (hostNetwork) configures network namespace, not filesystem. Option D (volumeMounts[].readOnly) only applies to specific volumes, not the root filesystem.

Answer

spec.containers[].securityContext.privileged

Answer

spec.hostNetwork

Answer

spec.containers[].volumeMounts[].readOnly

Question 4

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 has an egress rule that allows traffic to 10.0.0.5 on port 5432, and no other egress rules, so all other egress is denied by default.

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 5

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 6

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

Accepted Answer

Apply a NetworkPolicy to isolate the pod. Applying a NetworkPolicy to isolate the compromised pod is a critical containment step. By defining a policy that denies all ingress and egress traffic (e.g., `podSelector: {}` with `policyTypes: [Ingress, Egress]` and empty `ingress`/`egress` rules), you immediately cut off lateral movement and data exfiltration from the pod without destroying evidence. This aligns with the NIST SP 800-61 incident response framework's containment phase.

Answer

Restart the pod by deleting and recreating it

Answer

Delete the pod immediately to stop the attack

Question 7

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 8

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 9

You need to configure the Kubernetes API server to log all requests at the Metadata level. Which flag should you use when starting kube-apiserver?

Accepted Answer

--audit-policy-file=/etc/kubernetes/audit-policy.yaml. The --audit-policy-file flag points to a YAML file that defines the audit policy. The policy file specifies the level for different resources. Option B is correct. Option A is not a valid flag; Option C sets a different level; Option D is used to set the audit log path.

Answer

--audit-log-level=Metadata

Answer

--audit-webhook-mode=Metadata

Answer

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

Question 10

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

Accepted Answer

crictl ps. crictl ps lists containers. By default it shows only running ones. Option A is correct. Option B shows stats; Option C shows images; Option D shows pods.

Answer

crictl stats

Answer

crictl images

Answer

crictl pods

Question 11

A pod runs with an immutable root filesystem (readOnlyRootFilesystem: true). The application attempts to write to /tmp. What is the expected behavior?

Accepted Answer

The write fails with a permission error unless a writable volume is mounted at /tmp. When a pod is configured with `readOnlyRootFilesystem: true`, the container's root filesystem is mounted as read-only. The `/tmp` directory is part of the root filesystem, so any write attempt to it will fail with a permission error (EPERM) unless a writable volume (e.g., `emptyDir`, `hostPath`, or `PersistentVolumeClaim`) is explicitly mounted at `/tmp`. This is enforced by the Linux kernel's mount flags and is a common security hardening practice to prevent unauthorized writes.

Answer

The application can write to any directory because /tmp is always writable

Answer

The container crashes immediately

Answer

The write succeeds and is silently dropped

Question 12

You suspect a container has been compromised. You run 'kubectl exec -it <pod> -- bash' to investigate. Which of the following is the BEST next step to preserve evidence?

Accepted Answer

Use 'kubectl cp' to copy files from the container to a secure location, and 'kubectl logs' to capture log output. 'kubectl cp' allows you to extract files from the container without modifying the container's state, preserving the original evidence. 'kubectl logs' captures the container's stdout/stderr output, which is critical for forensic analysis. This approach avoids altering the container's filesystem or process state, which is essential for maintaining the integrity of the evidence.

Answer

Install forensic tools inside the container using apt-get

Answer

Run 'kubectl exec' to capture memory dumps

Answer

Delete the pod and create a new one for analysis

Question 13

You have a Falco rule that triggers on 'spawned a shell in a container'. The rule is firing too many false positives. Which field in the Falco rule could you modify to reduce false positives?

Accepted Answer

priority. The 'priority' field in a Falco rule sets the severity level (e.g., WARNING, CRITICAL). By increasing the priority threshold, you can filter out lower-severity false positives and only receive alerts for more critical events. The 'filter' field (A) defines the event conditions, but modifying it would change the rule logic, not reduce false positives directly. The 'output' field (B) specifies the alert message format and does not affect filtering. The 'format' field (C) is not a standard Falco rule field; the correct term is 'output' for message formatting. Therefore, adjusting 'priority' is the most appropriate way to reduce false positives while keeping the rule intact.

Answer

filter

Answer

output

Answer

format

Question 14

A developer reports that a pod cannot reach an external database at 192.168.1.100:3306. The pod's namespace is 'app'. You need to create a NetworkPolicy that allows egress to that IP only. Which policy is correct?

Accepted Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-egress
  namespace: app
spec:
  podSelector: {}
  egress:
  - to:
    - ipBlock:
        cidr: 192.168.1.100/32
    ports:
    - port: 3306
      protocol: TCP
  policyTypes:
  - Egress. The correct NetworkPolicy must allow egress traffic from pods in the 'app' namespace to the specific IP 192.168.1.100 on port 3306. Option D meets this requirement by using 'podSelector: {}' to apply to all pods, specifying an egress rule to the ipBlock with the correct CIDR and port 3306, and setting 'policyTypes: [Egress]'. Option A is missing the port specification, so it would allow egress to the IP on any port, which is too permissive. Option B uses 'matchLabels: app: myapp', restricting the policy to pods with that label, and also lacks the port. Option C defines an ingress rule instead of egress, which does not address the egress requirement.

Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-egress
  namespace: app
spec:
  podSelector: {}
  egress:
  - to:
    - ipBlock:
        cidr: 192.168.1.100/32
  policyTypes:
  - Egress

Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-egress
  namespace: app
spec:
  podSelector:
    matchLabels:
      app: myapp
  egress:
  - to:
    - ipBlock:
        cidr: 192.168.1.100/32
  policyTypes:
  - Egress

Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-egress
  namespace: app
spec:
  podSelector: {}
  ingress:
  - from:
    - ipBlock:
        cidr: 192.168.1.100/32
  policyTypes:
  - Ingress

Question 15

You need to detect when a container attempts to mount the host's Docker socket. Which Falco macro or condition would you use?

Accepted Answer

fd.name=/var/run/docker.sock. Falco has a default macro 'docker_socket' that matches the path '/var/run/docker.sock'. Using fd.name=/var/run/docker.sock in a condition will detect access to the socket. Option A is correct. Option B is a valid path but not the standard. Option C is a directory. Option D is a different socket.

Answer

fd.name=/var/run/containerd.sock

Answer

fd.name=/var/run/docker

Answer

fd.name=/run/docker.sock