CKS Minimize Microservice Vulnerabilities Practice Question
A DevOps engineer wants to ensure that all microservice containers run with a read-only root filesystem to prevent unauthorized writes. What is the simplest way to enforce this at the Pod level?
⚠ Common exam trap
CNCF often tests the distinction between security contexts that control user identity (runAsNonRoot) versus those that control filesystem permissions (readOnlyRootFilesystem), and the trap here is that candidates may confuse 'non-root' with 'read-only' or assume that disabling privileged mode is sufficient to prevent writes.
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
✓
Set `securityContext.readOnlyRootFilesystem: true` in the Pod spec
Setting `securityContext.readOnlyRootFilesystem: true` in the Pod spec directly enforces that the container's root filesystem is read-only, preventing any unauthorized writes to the root filesystem. This is the simplest and most direct way to achieve the requirement at the Pod level, as it applies to all containers in the Pod unless overridden at the container level.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Set `securityContext.runAsNonRoot: true` in the Pod spec
Why it's wrong here
Setting runAsNonRoot: true only enforces a non-zero UID for the container's main process; it does not alter the mount options of the root filesystem. A non-root process can still write to directories it owns or has write permissions for, so this setting alone fails to prevent modifications to the container's writable layer.
- ✗
Mount an emptyDir volume to the container's writable directories
Why it's wrong here
Mounting an emptyDir volume at writable directories just provides ephemeral in-memory or ephemeral-disk storage that disappears with the Pod. EmptyDir volumes are explicitly writable, so they do not set the root filesystem to read-only; they merely redirect writes under that mount point. Any other writable path in the root filesystem remains modifiable.
- ✓
Set `securityContext.readOnlyRootFilesystem: true` in the Pod spec
Why this is correct
Setting readOnlyRootFilesystem: true instructs the container runtime to mount the container's root filesystem as read-only, so no process can create, delete, or modify files in the root layer. This is the precise securityContext field that the requirement asks for, and it works regardless of the UID the container runs as. Any process that needs to write temporary data must have explicit writable volumes, such as emptyDir, mounted over required paths.
- ✗
Set `securityContext.privileged: false` in the Pod spec
Why it's wrong here
privileged: false is the Kubernetes default and only prevents the container from gaining host privileges like device access or seccomp/profile escalation; it has no bearing on whether the root filesystem is writable. A standard, unprivileged container still has a writable root filesystem layer, so this setting does not satisfy the read-only requirement.
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.