CKS Monitoring, Logging and Runtime Security Practice Question
An administrator wants to set an immutable root filesystem for a container in a Pod. Which securityContext field should be set to true?
⚠ Common exam trap
CKS often tests the confusion between readOnlyRootFilesystem and other securityContext fields like allowPrivilegeEscalation or runAsNonRoot, where candidates might incorrectly associate privilege escalation or user ID with filesystem immutability.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
readOnlyRootFilesystem
The readOnlyRootFilesystem field, when set to true in a container's securityContext, mounts the container's root filesystem as read-only. This prevents any process inside the container from writing to the root filesystem, which is a key security hardening measure to prevent runtime modifications, such as an attacker downloading tools or modifying binaries. It directly addresses the requirement for an immutable root filesystem.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
allowPrivilegeEscalation
Why it's wrong here
This setting controls whether any process in the container can gain more privileges than its parent, for example via setuid/setgid binaries or file capabilities. The administrator's goal is to prevent mutations of the container's filesystem, but this key only governs privilege escalation behavior, not write access to the root filesystem. Therefore it does not achieve an immutable root filesystem.
- ✓
readOnlyRootFilesystem
Why this is correct
Setting readOnlyRootFilesystem to true mounts the container's root filesystem as read-only, so any attempt by the container process to write, create, or delete files in / fails. This makes the root filesystem effectively immutable from the container's perspective because all write operations are blocked at the mount layer. Note that volumes can still be mounted writable, so immutability applies only to the root filesystem itself, not to data volumes.
- ✗
runAsNonRoot
Why it's wrong here
This field forces the container to run with a nonzero user ID by setting the user that the entrypoint executes as, thereby preventing processes from running as root. While this reduces the impact of a container breakout and limits file permissions, it does nothing to configure the root filesystem as read-only. An immutable root filesystem is a property of the filesystem mount, unrelated to the user identity of the processes.
- ✗
privileged
Why it's wrong here
The privileged flag grants the container all capabilities of the host and strengthens access to devices, effectively disabling many isolation mechanisms such as seccomp, SELinux, and AppArmor. It makes the container more powerful, not less, and does not set the root filesystem to be read-only. In fact, a privileged container can mount and modify the host filesystem, which is the opposite of the desired immutability.
Go deeper
Related to this question
About these practice questions
This CKS question is part of Courseiva's 845-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way this is tested on CKS
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. A pod runs with an immutable root filesystem (readOnlyRootFilesystem: true). The application attempts to write to /tmp. What is the expected behavior?
medium- ✓ A.The write fails with a permission error unless a writable volume is mounted at /tmp
- B.The application can write to any directory because /tmp is always writable
- C.The container crashes immediately
- D.The write succeeds and is silently dropped
Why A: 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.
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official CNCF exam blueprint
This CKS practice question is part of Courseiva's free CNCF certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CKS exam.