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

Question 1

In a Falco rule, you have the condition: 'evt.type=execve and proc.name=bash and container.id!=host'. What does this rule detect?

Accepted Answer

A bash shell being spawned inside a container. The rule triggers when a bash shell is executed (execve) inside any container (container.id != host). It does not check for interactive use; it simply detects bash execution.

Answer

A non-root bash process on the host

Answer

An interactive shell session inside a container

Answer

A bash process reading /etc/shadow

Question 2

You need to isolate a compromised pod named 'malicious-pod' in the 'default' namespace so that it cannot communicate with any other pod, but can still receive traffic from a specific monitoring pod. Which NetworkPolicy should you apply?

Accepted Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: isolate-pod
spec:
  podSelector:
    matchLabels:
      app: malicious-pod
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: monitoring-pod
  policyTypes:
  - Ingress
  - Egress. It selects the compromised pod, allows ingress only from the monitoring pod (using podSelector), and specifies policyTypes as both Ingress and Egress. Since no egress rules are defined, egress traffic is denied by default, isolating the pod from initiating communication. Option B incorrectly allows all egress via an empty egress rule. Option C denies all ingress (no ingress rules) and thus blocks the monitoring pod. Option D allows all ingress and does not restrict egress, failing to isolate the pod.

Answer

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

Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: isolate-pod
spec:
  podSelector:
    matchLabels:
      app: malicious-pod
  policyTypes:
  - Ingress
  - Egress

Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: isolate-pod
spec:
  podSelector:
    matchLabels:
      app: malicious-pod
  ingress:
  - {}
  policyTypes:
  - Ingress

Question 3

You run 'kubectl exec -it <pod> -- /bin/sh' inside a pod that has an immutable root filesystem. What happens?

Accepted Answer

The shell starts successfully, but any attempt to write to the root filesystem will be denied. When a container has an immutable root filesystem (e.g., readOnlyRootFilesystem: true in Kubernetes), the root filesystem is mounted as read-only. Running 'kubectl exec' to start a shell will succeed because the shell binary is already present and executable. However, any attempt to write to the root filesystem (e.g., creating a file) will be denied with a 'Read-only file system' error. The shell itself does not bypass the restriction.

Answer

The command fails with an error because the container has an immutable root filesystem

Answer

The shell starts and can write to any directory because 'exec' bypasses the restriction

Answer

The pod is restarted with a writable filesystem

Question 4

Which audit policy level logs all requests and responses, including the request body and response body?

Accepted Answer

RequestResponse. RequestResponse logs both the request object and the response object, including bodies. Request logs only the request object. Metadata logs only metadata. None logs nothing.

Answer

None

Answer

Request

Answer

Metadata

Question 5

Which kubectl command(s) can you use to view the logs of a specific container in a multi-container pod? (Select all that apply)

Accepted Answer

kubectl logs -c . The `kubectl logs` command supports both `-c` and `--container` flags to specify a container name in a multi-container pod. Both are equivalent and valid. The other options are either incorrect syntax or would display logs from all containers, which does not target a specific container.

Answer

kubectl logs

Answer

kubectl logs <pod> --all-containers

Question 6

You need to configure the Kubernetes API server to enable audit logging at the 'Metadata' level for all requests. Which flag should be used when starting the kube-apiserver?

Accepted Answer

--audit-policy-file=/etc/kubernetes/audit-policy.yaml. Audit logging is enabled by specifying --audit-policy-file pointing to a policy file. The policy file defines the level. The flag itself is --audit-policy-file.

Answer

--feature-gates=Auditing=true

Answer

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

Answer

--audit-log-maxsize=100

Question 7

During a security incident, you need to isolate a compromised pod named 'malicious-pod' in namespace 'default' to prevent it from communicating with other pods. Which command should you run?

Accepted Answer

kubectl apply -f networkpolicy.yaml. Pod isolation is achieved by applying a NetworkPolicy that denies ingress/egress traffic. 'kubectl apply -f networkpolicy.yaml' applies the policy. The policy must be written to deny all traffic.

Answer

kubectl run networkpolicy --image=nginx --restart=Never

Answer

kubectl delete pod malicious-pod

Answer

kubectl create networkpolicy isolate --pod-selector=app=malicious --policy-types=Ingress,Egress

Question 8

An administrator wants to ensure that containers in the 'secure-app' namespace cannot write to their own filesystem. Which pod security context setting should be used?

Accepted Answer

securityContext: { readOnlyRootFilesystem: true }. Setting readOnlyRootFilesystem: true mounts the container's root filesystem as read-only, preventing any process inside the container from writing to it. This directly satisfies the requirement that containers cannot write to their own filesystem. Writable volumes can still be mounted separately for legitimate write needs.

Answer

securityContext: { runAsNonRoot: true }

Answer

securityContext: { privileged: false }

Answer

securityContext: { capabilities: { drop: ["ALL"] } }

Question 9

A Falco rule is written to detect access to /etc/shadow inside a container. Which condition should be used?

Accepted Answer

evt.type=open and fd.name=/etc/shadow. The correct condition is 'evt.type=open and fd.name=/etc/shadow' because reading a file in Linux typically involves the open or openat syscall to obtain a file descriptor. Falco's fd.name field captures the file path, and evt.type=open detects the attempt to open the file. This directly detects access to /etc/shadow without relying on specific tools like cat or less.

Answer

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

Answer

spawned_process and proc.name in (cat, less) and container

Answer

evt.type=execve and proc.name=cat and fd.name=/etc/shadow

Question 10

You are using crictl to debug a container. Which command lists all running containers on the node?

Accepted Answer

crictl ps. `crictl ps` is the command used to list running containers on a node when using the CRI (Container Runtime Interface) compatible runtimes like containerd or CRI-O. It mirrors the Docker `docker ps` syntax and shows only running containers by default, which is exactly what the question asks for.

Answer

crictl containers

Answer

crictl get pods

Answer

crictl list

Question 11

A pod is stuck in 'Pending' state. You run 'kubectl describe pod mypod' and see the event: '0/1 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate'. What is the most likely solution?

Accepted Answer

Add a toleration to the pod spec for the taint 'node-role.kubernetes.io/master'. The pod is unschedulable because the node has a taint that the pod does not tolerate. To allow the pod to be scheduled on that node, you must add a toleration to the pod spec that matches the taint. This is the correct solution.

Answer

Delete the pod and recreate it without any tolerations

Answer

Remove the taint from the node using 'kubectl taint nodes ...'

Answer

Add a nodeSelector to the pod to match the node's labels

Question 12

Which command can be used to view the logs of a container using the container runtime interface (crictl)?

Accepted Answer

crictl logs <container-id>. crictl logs is the command to fetch logs of a container, similar to 'docker logs'.

Answer

crictl status <container-id>

Answer

crictl inspect <container-id>

Answer

crictl log <container-id>

Question 13

You suspect a container has been compromised. You want to preserve the container's filesystem for forensic analysis before terminating the pod. Which approach should you use?

Accepted Answer

Use kubectl cp to copy files from the container to a safe location. Using kubectl cp to copy files from the container to a safe location preserves the container's filesystem for forensic analysis without altering the running container. This method allows you to extract files for offline analysis while keeping the container intact for further investigation.

Answer

Exec into the container and delete suspicious files

Answer

Restart the kubelet on the node

Answer

Immediately delete the pod to stop the attack

Question 14

Which TWO of the following are valid audit levels in a Kubernetes audit policy? (Select TWO.)

Accepted Answer

None. Option B (None) is a valid audit level: it tells the API server not to log matching requests at all, which is useful for excluding noisy or sensitive events from the audit log. Option C (Metadata) is also valid: it logs request metadata such as the user, timestamp, resource, verb, and whether the request succeeded, but omits the request and response bodies. Kubernetes audit policies define exactly these levels — None, Metadata, Request, and RequestResponse — so the remaining choices do not belong: Response (A) is not a level (the response-body level is RequestResponse), Log (D) is not a defined audit level, and Full (E) is not a Kubernetes audit level name.

Answer

Response

Answer

Log

Answer

Full

Question 15

Which TWO of the following are valid techniques to detect and respond to runtime incidents in a Kubernetes cluster? (Select TWO.)

Accepted Answer

Applying a NetworkPolicy to isolate a compromised pod. Option C is correct because applying a NetworkPolicy to a compromised pod lets you isolate it at the network layer — by selecting the pod with a label selector and defining ingress/egress rules (or an empty egress/ingress set) you cut off lateral movement and C2 traffic while keeping the pod alive for investigation, which is a standard containment step in runtime incident response. Option D is correct because kubectl exec into a running container allows you to collect volatile forensic evidence — running processes, open sockets, environment variables, and in-memory artifacts — that would be lost if the pod were deleted or restarted, making it a valid detection/response technique. Option A is not a valid detection technique: deleting the pod destroys evidence and, if the workload is managed by a ReplicaSet/Deployment, the controller immediately recreates it, so the attack resumes. Option B is not a runtime incident detection/response technique: crictl images only enumerates images cached on the node and provides no runtime behavioral insight. Option E is not correct here because kubectl logs --previous only retrieves logs from a previously terminated container instance and does not itself detect or respond to a live runtime incident.

Answer

Deleting the compromised pod immediately to stop the attack

Answer

Using crictl images to list container images on the node

Answer

Running kubectl logs --previous to view logs of a terminated container