CKS Monitoring, Logging and Runtime Security Practice Question
To ensure a container's filesystem is read-only, which field should be set to 'true' in the container spec?
⚠ Common exam trap
CKS often tests the exact field name for read-only root filesystem; candidates may confuse it with other securityContext fields like runAsNonRoot or fsGroup.
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
✓
securityContext.readOnlyRootFilesystem
The `securityContext.readOnlyRootFilesystem` field, when set to `true`, mounts the container's root filesystem as read-only. This prevents any writes to the container's filesystem, enhancing security by making it immutable. It is the correct field to ensure a read-only 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.
- ✓
securityContext.readOnlyRootFilesystem
Why this is correct
securityContext.readOnlyRootFilesystem is a boolean field within a container's security context. When set to true, it mounts the container's root filesystem as read-only, blocking any writes to the container layer. This forces all writable data to be stored in explicitly mounted volumes, such as emptyDir or persistent volumes, which is a key security hardening measure.
- ✗
securityContext.runAsNonRoot
Why it's wrong here
securityContext.runAsNonRoot is used to enforce that a container runs as a non-root user by validating the USER directive in the image or the container's runAsUser setting. It does not modify the filesystem permissions or mount flags; it only governs the user ID under which the process executes. Therefore, even with runAsNonRoot set, the root filesystem remains writable unless readOnlyRootFilesystem is explicitly configured.
- ✗
container.fsGroup
Why it's wrong here
The field fsGroup actually belongs to the Pod's securityContext, not to container.fsGroup as stated. It sets the supplemental group ID for volume mounts, giving pods group-level access to volumes with appropriate permissions. However, fsGroup has no influence on the container's root filesystem writeability; it only affects the ownership and access of mounted volumes, not the container's own image layer.
- ✗
podSpec.containers.readonly
Why it's wrong here
There is no `readonly` field in a container's spec; the correct location for read-only filesystem control is inside `securityContext` as `readOnlyRootFilesystem`. The path `podSpec.containers.readonly` is invalid for two reasons: there is no `readonly` key in the container API, and `podSpec` is not a valid field — a Pod's specification is `spec`, with containers at `spec.containers[]`. Thus this option is entirely fictitious.
Go deeper
Related to this question
About these practice questions
One of 845 original CKS practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
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.