CKS Minimize Microservice Vulnerabilities Practice Question
A developer wants to ensure that all containers in a pod run with a read-only root filesystem except for a specific volume mounted for writing logs. Which container-level security context field should be set to true?
⚠ Common exam trap
It's easy for candidates to confuse `readOnlyRootFilesystem` with `runAsNonRoot` or `allowPrivilegeEscalation`, mistakenly thinking those options also restrict filesystem writes, when in fact they address entirely different security concerns (user identity and privilege escalation).
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
Setting `readOnlyRootFilesystem: true` in the container-level security context forces the container's root filesystem to be read-only, preventing any writes to the root filesystem. This is exactly what the developer needs to enforce immutability for the root filesystem while allowing writes only to a specific volume (e.g., for logs) mounted with write access. The field is a boolean in the `securityContext` of a container specification in Kubernetes.
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
allowPrivilegeEscalation governs whether a process can gain more privileges than its parent, such as via setuid binaries; it does not make the root filesystem read-only. It is tempting because it is a genuine container-level hardening field, but the stem requires readOnlyRootFilesystem, which this setting leaves untouched.
- ✓
readOnlyRootFilesystem
Why this is correct
readOnlyRootFilesystem mounts the container's root filesystem as read-only, blocking writes outside explicitly mounted volumes. Setting it true satisfies the stem's constraint: the pod stays immutable while the designated log volume remains writable, since volume mounts override the read-only root.
- ✗
privileged
Why it's wrong here
privileged grants the container all Linux capabilities and unrestricted device access, the opposite of restricting writes; it does not set a read-only root filesystem. It is tempting because it is a container-level security context field, but it widens privileges rather than confining the filesystem, so it fails the requirement outright.
- ✗
runAsNonRoot
Why it's wrong here
runAsNonRoot enforces that the container process runs as a non-root UID; it says nothing about filesystem writability. It is tempting because it is a common container-level hardening control, but the stem asks for a read-only root filesystem, which requires readOnlyRootFilesystem instead.
Go deeper
Related to this question
About these practice questions
Courseiva writes every CKS question from scratch — 845 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
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.