Overview
Monitoring, Logging and Runtime Security is about spotting and limiting attacks in progress. You use Falco, which watches system calls through an eBPF probe or kernel module, to detect behaviour such as a shell spawned in a container or a write under /etc, and you adjust or add rules and change their output format. You investigate alerts by mapping a process or container ID back to a Pod with crictl and kubectl, identifying what stage an attacker reached and stopping the affected workload. You make containers immutable with readOnlyRootFilesystem and emptyDir mounts for paths that must stay writable.
The audit competency asks you to write an audit Policy with None, Metadata, Request and RequestResponse levels, enable it with kube-apiserver flags and hostPath mounts, and read the JSON log to see who did what. Falco and Kubernetes documentation are both on the allowed list.
How it's tested
Runtime tasks often begin with evidence rather than instructions. A Falco alert, syslog line or audit entry points to suspicious activity, and you identify the Pod responsible, then scale it to zero or delete it. Other tasks ask you to configure an audit policy with exact rules, or make a Deployment's containers immutable without breaking the application.
-
Alert to workload
A Falco or log entry shows a container ID or process; you map it with crictl ps and crictl inspect to a Pod and namespace, then act on the owning Deployment.
-
Policy from requirements
You write an audit Policy where each sentence of the task becomes a rule, ordered so specific rules come before broad catch-alls.
-
Freeze the container
A Pod writes to its filesystem at runtime; you set readOnlyRootFilesystem true and add emptyDir volumes only for paths that the application legitimately writes.
A task needs Secrets logged at Metadata, Pod changes in namespace prod at RequestResponse, and everything else at None. Audit rules are evaluated in order and the first match wins, so placing level None first would silence everything. The policy must list the Secrets and prod Pod rules first, then the catch-all None. Logging Secrets at Request would write their contents into the log.
Competencies 5
Official competencies from the CNCF / The Linux Foundation outline, in outline order.
6.1 Perform behavioral analytics to detect malicious activitiesRuntime detection with Falco rules and output.
- What it means
- Behavioral analytics watches what workloads actually do at runtime, such as process launches, file access and network connections, and flags patterns that suggest compromise. Falco is the CNCF tool for this in Kubernetes.
- What to understand
- Falco rules combine a condition, output and priority, built from macros and lists. Default rules live in falco_rules.yaml; put custom or overriding rules in falco_rules.local.yaml or the rules.d directory so upgrades do not overwrite them. Output fields like %container.id, %k8s.pod.name and %proc.name enrich alerts. Read alerts with journalctl -u falco or the configured file output.
- How it shows up
- Expect to change a rule's output format or priority, or write alerts for a named behaviour to a file.
- Common confusion
- Editing the default rules file, which may be replaced, instead of the local overrides file.
6.2 Detect threats within physical infrastructure, apps, networks, data, users and workloadsRecognising signs of compromise across layers.
- What it means
- Threats appear at every layer: hosts, applications, network flows, stored data, user accounts and containers. Detection means knowing which signal reveals each one and which tool collects it.
- What to understand
- Host and container activity come from Falco and syslog, API actions from audit logs, network behaviour from CNI flow logs such as Cilium Hubble, and application issues from container logs. Typical indicators include shells in containers, reads of /etc/shadow, unexpected outbound connections, new privileged Pods and service accounts listing Secrets. Frameworks such as the MITRE ATT&CK matrix for containers help classify what you see.
- How it shows up
- A task may ask which source would reveal a given activity, or to find a workload doing something unusual.
- Common confusion
- Expecting audit logs to show in-container activity, which never reaches the API server.
6.3 Investigate and identify phases of attack and bad actors within the environmentTracing an incident to its source and stage.
- What it means
- Investigation connects alerts into a story: how the attacker got in, what they ran, whether they gained privileges or persistence, and what they reached. The aim is to find the bad actor's workload or identity and contain it.
- What to understand
- Use crictl ps, crictl inspect and crictl pods to map container IDs and PIDs to Pods; check /proc/PID for the command and namespace. Correlate with audit log entries by user, verb and timestamp. Attack phases follow the usual chain of initial access, execution, persistence, privilege escalation, lateral movement and impact. Contain by scaling the Deployment to zero or deleting the Pod as instructed.
- How it shows up
- Expect to identify the Pods behind suspicious syscalls and scale their Deployments to zero.
- Common confusion
- Deleting a Pod managed by a Deployment, which promptly recreates it.
6.4 Ensure immutability of containers at runtimePreventing changes inside running containers.
- What it means
- An immutable container cannot have its files or binaries changed after it starts. If an attacker gets in, they cannot install tools or alter the application, and replacing the container restores a known state.
- What to understand
- Set securityContext.readOnlyRootFilesystem true and mount emptyDir volumes only for directories that must be writable, such as /tmp or a cache path. Avoid privileged mode and added capabilities, run as non-root, and remove shells from images where possible. Use startupProbe or init containers only for setup that cannot be baked into the image.
- How it shows up
- A task may give several Pods and ask you to find and fix the ones that are not immutable.
- Common confusion
- Making the root filesystem read-only without an emptyDir, which crashes apps that write temporary files.
6.5 Use Kubernetes audit logs to monitor accessConfiguring and reading API server audit logs.
- What it means
- Kubernetes audit logging records requests to the API server: who made them, what they targeted, and what happened. A Policy file decides which requests are logged and at what detail level.
- What to understand
- Levels are None, Metadata, Request and RequestResponse; the first matching rule applies. omitStages RequestReceived reduces duplicates. Enable with --audit-policy-file and --audit-log-path, plus --audit-log-maxage, --audit-log-maxbackup and --audit-log-maxsize for retention, and mount both paths into the API server Pod with hostPath volumes. Log Secrets and ConfigMaps at Metadata to avoid recording contents.
- How it shows up
- Expect a policy with three or four ordered rules and retention flags, then a check that entries appear.
- Common confusion
- Setting audit flags without mounting the policy file, so the API server fails to start.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Falco rule structure
Each rule has a condition, output, priority and optional tags.
- Remember
- Conditions reference fields like proc.name, fd.name and container.id.
- Tested as
- Rule edits are a recurring exam task.
- Trap
- Changing the condition when the task only asked for a new output format.
-
falco_rules.local.yaml
Location for custom and overriding Falco rules.
- Remember
- Rules here load after defaults and can replace them by name.
- Tested as
- Keeps edits safe from package upgrades.
- Trap
- Editing falco_rules.yaml directly.
-
crictl inspect
Shows container details including Pod name, namespace and PID.
- Remember
- Use it to map Falco container IDs to Kubernetes objects.
- Tested as
- Investigation tasks start here.
- Trap
- Searching kubectl output for a runtime container ID.
-
Scale to zero
kubectl scale deployment name --replicas=0 stops all its Pods.
- Remember
- Containment that the controller will not undo.
- Tested as
- Common final step after identifying a bad workload.
- Trap
- Deleting Pods that the ReplicaSet recreates.
-
readOnlyRootFilesystem
securityContext field that mounts the container root read-only.
- Remember
- Pair it with emptyDir for writable paths.
- Tested as
- Core of the immutability competency.
- Trap
- Setting it at Pod level, where the field does not exist.
-
Audit levels
None, Metadata, Request and RequestResponse.
- Remember
- Higher levels record request and response bodies.
- Tested as
- Policy tasks assign a level per resource.
- Trap
- Logging Secrets at Request and exposing their values.
-
First-match rule order
Audit policy rules are evaluated top to bottom; the first match wins.
- Remember
- Place specific rules before catch-all rules.
- Tested as
- Ordering mistakes silently change what is logged.
- Trap
- Putting a level None rule at the top.
-
Audit flags and mounts
--audit-policy-file, --audit-log-path and retention flags on kube-apiserver.
- Remember
- Mount the policy file and log directory with hostPath volumes.
- Tested as
- Required for any audit configuration task.
- Trap
- Mounting the log file path read-only.
-
Attack phases
Initial access, execution, persistence, privilege escalation, lateral movement, impact.
- Remember
- Each phase leaves different evidence in different logs.
- Tested as
- Helps classify investigation findings.
- Trap
- Assuming a single log source reveals every phase.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Audit levels
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| None | Do not log matching requests | Nothing recorded | Placing it first and suppressing every other rule |
| Metadata | Logs user, verb, resource and timestamps | No request or response bodies | Assuming it hides who accessed a Secret |
| Request | Metadata plus the request body | No response body | Using it for Secrets and logging their data |
| RequestResponse | Metadata plus request and response bodies | Most detail and largest logs | Applying it cluster-wide and filling the disk |
Runtime evidence sources
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Falco alerts | Syscall-level events from containers and hosts | Sees activity inside containers | Expecting it to show API calls made with kubectl |
| Audit logs | API server requests and responses | Records identity and API actions | Looking here for a shell spawned in a container |
| crictl | Container runtime view of containers and Pods | Links container IDs and PIDs to Pods | Using docker commands on a containerd node |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Recreated attacker Pod
- What candidates pick
- Deleting the Pod named in the alert.
- Why it looks right
- It removes the suspicious process immediately.
- Why it's wrong
- The owning ReplicaSet starts a replacement, so the workload remains active.
Clue to watch for A Pod name with a ReplicaSet hash suffix.
-
Audit rule order
- What candidates pick
- Writing the catch-all rule first for readability.
- Why it looks right
- General-to-specific reads naturally.
- Why it's wrong
- The first matching rule wins, so specific rules after it never apply.
Clue to watch for A task listing exceptions to a default level.
-
Leaking Secret data
- What candidates pick
- Logging all resources at RequestResponse to be thorough.
- Why it looks right
- More detail seems better for monitoring.
- Why it's wrong
- Request bodies and responses include Secret values, which then sit in plain text in the log.
Clue to watch for Any requirement that Secrets be audited.
-
Wrong Falco file
- What candidates pick
- Editing the default rules file in place.
- Why it looks right
- The rule to change lives there.
- Why it's wrong
- Package updates can replace it, and local overrides are the supported place for changes.
Clue to watch for A task asking to modify or add a rule.
-
Immutability by deletion
- What candidates pick
- Removing the write-heavy container from the Pod.
- Why it looks right
- The Pod no longer writes anything.
- Why it's wrong
- The application must keep working; read-only root plus emptyDir is the intended fix.
Clue to watch for A requirement that the Pod remains functional.
-
Wrong log source
- What candidates pick
- Checking audit logs for a process launched inside a container.
- Why it looks right
- Audit logs feel like the security record.
- Why it's wrong
- Starting a process inside a container is not an API request, so audit logs never record it; runtime tools such as Falco see it.
Clue to watch for Evidence described as syscalls, files or processes.
Answer framework
Follow these steps for detection, investigation and audit tasks so evidence leads to the right action.
- Identify the evidence type in the task, such as a Falco alert, a process, a container ID or an API action, and choose the matching tool.
- Map the evidence to Kubernetes objects with crictl ps, crictl inspect, kubectl get pods -o wide and the owning controller.
- Decide the required action from the wording: scale to zero, delete, make immutable, adjust a Falco rule or write an audit policy.
- For configuration changes, back up the API server manifest or Falco file, apply the edit and add any needed volumes and mounts.
- Verify the result by checking the new log entries, the Falco alert output, the replica count or a write test inside the container.
Practice question
Want more like this? The CKS practice test has questions for every domain.
Checklist
0 of 11
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Install Falco on a lab worker using the falco.org packages and trigger its default rules: exec a shell in a Pod, read /etc/shadow, write under /etc. Watch alerts with journalctl, then override one rule in the local file to change its output and confirm the new format appears. Map each alert's container ID to a Pod with crictl so that step becomes automatic.
Next, build audit logging from scratch on a kubeadm control plane. Write a four-rule policy, add the flags and both hostPath volumes, wait for the API server to return and query the log with jq for a test action you performed. Break the setup on purpose with a wrong path and recover using journalctl -u kubelet and crictl logs.
Finish by converting a few common images to read-only root filesystems, adding emptyDir mounts until they run. Review MITRE ATT&CK container techniques briefly so you can name attack phases from evidence.
FAQ
How much of the CKS exam covers Monitoring, Logging and Runtime Security?
Monitoring, Logging and Runtime Security is weighted at 20% in the official curriculum, equal to the two other heaviest domains. Expect three or four tasks, frequently including Falco and audit logging.
Is Falco documentation allowed in the exam?
Yes. The Linux Foundation allowed resources for CKS include falco.org/docs, alongside the Kubernetes documentation that covers audit logging and security contexts.
Do I need to write Falco rules from scratch?
Tasks more often ask you to adjust an existing rule's output or priority, or to find which workload triggered a rule. Being able to write a short custom rule is still useful.
Where should audit logs be written in the exam?
Use exactly the path the task gives, and mount its directory into the API server Pod with a writable hostPath volume. A missing mount is the most common reason the API server fails to restart.
Why use scale to zero instead of delete?
A Deployment's ReplicaSet recreates deleted Pods within seconds. Scaling to zero stops them while keeping the object for investigation, unless the task explicitly asks for deletion.
Can a read-only root filesystem break applications?
Yes, if they write logs, caches or temporary files. Add emptyDir volumes for those specific paths so the root stays read-only while the application keeps working.
Other DevOps & Containers certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 6 knowledge
Test Falco, crictl investigation, immutability and audit logging tasks under realistic time pressure across this 20% domain.