CKS Minimize Microservice Vulnerabilities Practice Question
Which TWO of the following are valid ways to enforce that containers run with a read-only root filesystem?
⚠ Common exam trap
The CKS exam often tests the distinction between Pod-level and container-level securityContext fields, and candidates may incorrectly assume that Pod-level settings like `runAsNonRoot` or `fsGroup` affect the root filesystem's write permissions, when only the container-level `readOnlyRootFilesystem` field (or a mutating webhook) actually enforces that behavior.
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
✓
Using a MutatingWebhookConfiguration that adds `readOnlyRootFilesystem: true` to all containers
A MutatingWebhookConfiguration can intercept Pod creation requests and automatically add the `readOnlyRootFilesystem: true` field to every container's securityContext, enforcing a read-only root filesystem without requiring manual changes to Pod specs. Option E is correct because setting `readOnlyRootFilesystem: true` directly in the container's securityContext is the explicit Kubernetes API field that makes the container's root filesystem read-only, preventing writes to the filesystem layer.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Setting `runAsNonRoot: true` in the pod's securityContext
Why it's wrong here
runAsNonRoot: true only enforces that the container's primary UID is non-zero; it does not modify mount flags for the container's filesystem. A container running with a UID of 1000 can still write to its root filesystem if that filesystem is mounted read-write and the UID has write permissions, so this setting alone would not make the root filesystem read-only. Therefore it fails to enforce the required immutability.
- ✗
Using an emptyDir volume mounted at /
Why it's wrong here
Mounting an emptyDir volume at / actually achieves the opposite of enforcing a read-only root filesystem. An emptyDir is an ephemeral, writable volume, so overlaying it on the root directory creates a writable root filesystem that is discarded when the pod stops. It neither marks the underlying image root as read-only nor prevents writes; it simply repoints the root path to a scratch volume, violating the enforcement goal.
- ✗
Setting `fsGroup: 1000` in the pod's securityContext
Why it's wrong here
fsGroup: 1000 specifies a supplementary group used for volume ownership and permission checking of mounted volumes, not for the root filesystem's write state. When a volume is attached, Kubernetes may recursively set the group and adjust permissions for the group ID so the pod can access it. This has no impact on whether the container's root filesystem is mounted read-write, so it cannot enforce a read-only root.
- ✓
Using a MutatingWebhookConfiguration that adds `readOnlyRootFilesystem: true` to all containers
Why this is correct
A MutatingWebhookConfiguration is a valid enforcement mechanism because it intercepts Pod create or update requests at admission time and mutates container specs before they are persisted. By injecting readOnlyRootFilesystem: true into every container, the webhook enforces the read-only root policy centrally, even when developers omit the field in their manifests. This is a common pattern for cluster-wide security controls.
- ✓
Setting `readOnlyRootFilesystem: true` in the container's securityContext
Why this is correct
Setting readOnlyRootFilesystem: true in the container's securityContext directly instructs the kubelet to mount the container's root filesystem as read-only. Any attempts by the container to write into its root layer are denied by the kernel, while separate writable volumes such as emptyDir or configMap-provided files can still be used for legitimate writes. This is the standard, built-in field for enforcing this requirement.
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 →
Same concept, more angles
2 more ways 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 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?
medium- A.allowPrivilegeEscalation
- ✓ B.readOnlyRootFilesystem
- C.privileged
- D.runAsNonRoot
Why B: 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.
Variation 2. 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?
easy- A.Set `securityContext.runAsNonRoot: true` in the Pod spec
- B.Mount an emptyDir volume to the container's writable directories
- ✓ C.Set `securityContext.readOnlyRootFilesystem: true` in the Pod spec
- D.Set `securityContext.privileged: false` in the Pod spec
Why C: 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.
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.