Monitoring, Logging and Runtime Security practice questions
Practise Certified Kubernetes Security Specialist CKS Monitoring, Logging and Runtime Security practice questions — original exam-style scenarios with answer choices, explanations, and analysis of common mistakes.
Courseiva uses original exam-style practice questions designed for learning and revision. The goal is to understand the concepts, recognise exam patterns, and improve through explanations — not memorise copied exam dumps.
You are investigating a pod that is suspected of being compromised. You need to preserve the container's filesystem for forensic analysis. Which `crictl` command should you use to export the container's filesystem as a tar archive?
Trap 1: crictl logs <container-id>
crictl logs retrieves container logs, not filesystem.
Trap 2: crictl inspect <container-id>
crictl inspect shows detailed container configuration and state, not filesystem content.
Trap 3: crictl exec <container-id> tar cvf /tmp/fs.tar /
This runs tar inside the container, modifying the container's state, which is not ideal for forensic preservation.
A Falco rule is written to detect when a shell is spawned inside a container. The rule condition is: `spawned_process and container and proc.name = bash`. The rule is not triggering. Which of the following is the most likely reason?
Trap 1: The rule is missing `proc.name in (bash, sh, zsh)` because only…
While adding more shells helps, the rule not triggering at all suggests a broader issue.
Trap 2: Falco is not running with the required syscall capabilities
If Falco were not running with capabilities, no rules would trigger.
Trap 3: The priority is set to `ERROR` but the output is being filtered
Output filtering does not prevent the rule from triggering; it only affects output display.
You are configuring Kubernetes audit logging. You want to log all requests to the `secrets` resource in the `kube-system` namespace at the `RequestResponse` level, while logging all other requests at the `Metadata` level. Which audit policy configuration achieves this?
You have deployed a pod and set `securityContext.readOnlyRootFilesystem: true`. The pod is failing to start with an error about writing to `/tmp`. What is the most likely cause?
Trap 1: The `securityContext` is misspelled
Misspelling would cause a validation error, not a runtime write error.
Trap 2: The container image does not have `/tmp` directory
Even if the directory exists, writing to it requires a writable filesystem.
Trap 3: The container is running as a non-root user
Non-root users can still write if the filesystem is writable; the issue is the read-only root filesystem.
An administrator runs `kubectl exec -it nginx-pod -- sh` and inside the container runs `curl http://example.com`. This succeeds. However, the administrator wants to detect such outbound connections using Falco. Which syscall should Falco monitor to detect this network connection?
Trap 1: open
open is used for file operations, not network connections.
Trap 2: execve
execve is used to execute a program, not to make network connections.
Trap 3: bind
bind is used to bind a socket to a local address, typically for listening, not for outbound connections.
You are writing a Falco rule to detect when a container tries to read the file `/etc/shadow`. Which condition in the Falco rule correctly matches this event?
Trap 1: container.name=shadow and evt.type=open
container.name is the container name, not the file path.
Trap 2: evt.type=read and fd.name=/etc/shadow
The read syscall often does not have fd.name populated; open is the correct syscall to capture file access.
Trap 3: proc.name=cat and fd.name=/etc/shadow
This only detects if the process name is 'cat', which is too specific and misses other tools.
You are responding to a security incident where a pod named `compromised-pod` in namespace `default` is suspected of being used for cryptocurrency mining. You need to immediately isolate the pod from the network while preserving evidence. Which command sequence should you use?
Trap 1: kubectl cordon <node-of-compromised-pod>
Cordoning the node prevents new pods from scheduling, but does not isolate existing pods.
Trap 2: kubectl delete pod compromised-pod && kubectl describe pod…
Deleting the pod destroys evidence. Describe would fail because the pod is gone.
Why wrong: Cordoning the node prevents new pods from scheduling, but does not isolate existing pods.
B
kubectl run temp-pod --image=busybox --restart=Never -- /bin/sh -c 'kubectl label pod compromised-pod isolated=true' && kubectl apply -f networkpolicy.yaml that selects pod with label isolated=true and denies all traffic
This creates a network policy that isolates the pod by denying all ingress/egress. The pod remains running for forensics.
C
kubectl delete pod compromised-pod && kubectl describe pod compromised-pod
Why wrong: Deleting the pod destroys evidence. Describe would fail because the pod is gone.
A Falco rule has priority `WARNING` and output: `Sensitive file opened (user=%user.name command=%proc.cmdline file=%fd.name)`. The rule is triggering correctly. You want to reduce noise from legitimate administrative activity. What is the best approach?
Trap 1: Modify the rule condition to add `and not user.name in (admin,…
This would exclude all admin and root users, which might be too broad and miss real threats from those accounts.
Trap 2: Change the rule priority to `INFO`
Changing priority does not reduce the number of alerts; it only changes the severity level.
Trap 3: Disable the rule
Disabling the rule would stop detecting the activity entirely, which may not be desired.
You need to ensure that all containers in a pod cannot write to their root filesystem except for a specific directory `/data`. You set `securityContext.readOnlyRootFilesystem: true` and mount an emptyDir volume at `/data`. However, the container still cannot write to `/data`. What is the most likely cause?
Trap 1: The emptyDir volume is not mounted correctly in the pod spec
If the volume were not mounted, the container would fail to start or the directory would be empty, but the issue is permissions.
Trap 2: The emptyDir volume is using a read-only storage class
emptyDir volumes are ephemeral and always writable; there is no storage class.
Trap 3: readOnlyRootFilesystem also applies to mounted volumes
readOnlyRootFilesystem only affects the root filesystem of the container, not mounted volumes.
A security team wants to detect any attempt to read /etc/shadow from within a container using Falco. Which condition in a Falco rule would match this behavior?
What does the CKS exam test about Monitoring, Logging and Runtime Security?
Monitoring, Logging and Runtime Security questions test whether you can apply the concept in context, not just recognise a definition.
How should I use these practice questions?
Select your answer before revealing the explanation. Then read why each option is right or wrong — this active recall approach builds retention far faster than re-reading notes.
Can I practise just Monitoring, Logging and Runtime Security questions in a focused session?
Yes — the session launcher on this page draws every question from the Monitoring, Logging and Runtime Security domain. Use a 10-question session first to gauge your baseline, then move to 20 or 30 once the weak spots are clear.
Where can I practise other CKS topics?
Use the topic links above to move to related areas, or go back to the CKS question bank to see all topics.
Are these real exam questions or dumps?
These are original practice questions written to test the same concepts the CKS exam covers. They are not copied from any real exam or dump site.