CKS Minimize Microservice Vulnerabilities Practice Question
Which THREE of the following are valid approaches to enforce that all pods in a cluster run with a read-only root filesystem? (Select THREE)
⚠ Common exam trap
Candidates often confuse dropping capabilities with making the root filesystem read-only. Dropping capabilities limits kernel privileges but does not prevent writes to the filesystem; they are separate security contexts.
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
✓
Deploy a ValidatingWebhookConfiguration that checks for readOnlyRootFilesystem: true
Option A is correct because a ValidatingWebhookConfiguration can intercept pod CREATE/UPDATE admission requests and reject any pod whose containers do not set securityContext.readOnlyRootFilesystem: true, thereby enforcing the requirement cluster-wide. Option C is correct because the Pod Security Admission 'restricted' profile mandates that every container sets securityContext.readOnlyRootFilesystem to true (among other hardening controls), so labeling namespaces with pod-security.kubernetes.io/enforce=restricted blocks non-compliant pods. Option D is correct because a MutatingWebhookConfiguration can patch incoming pod specs to inject readOnlyRootFilesystem: true into each container's securityContext, ensuring all admitted pods run with a read-only root filesystem. Option B is not correct because a Gatekeeper policy that drops all capabilities addresses Linux capabilities, not the read-only root filesystem setting. Option E is not correct because a NetworkPolicy only controls pod ingress/egress traffic and has no effect on container filesystem mutability.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Deploy a ValidatingWebhookConfiguration that checks for readOnlyRootFilesystem: true
Why this is correct
A ValidatingWebhookConfiguration intercepts Pod create and update requests and can reject any pod that does not explicitly set readOnlyRootFilesystem: true in its container securityContext. This is a valid enforcement approach because the webhook runs as part of the admission chain and denies non-compliant resources before they are persisted in etcd, ensuring workloads never run with a writable root filesystem.
- ✗
Use a Gatekeeper policy to drop all capabilities
Why it's wrong here
A Gatekeeper constraint that drops all capabilities only removes Linux capabilities from container processes; it does not modify the filesystem mount options or set readOnlyRootFilesystem. This is a wrong approach for this question because capability reduction and read-only root filesystem are orthogonal security controls, so a pod can still have a writable root filesystem even after all capabilities are dropped.
- ✓
Enable Pod Security Admission (PSA) with the 'restricted' profile
Why this is correct
Pod Security Admission's restricted profile is a built-in admission controller that enforces a set of hardened security standards, and one of its required fields is readOnlyRootFilesystem: true for each container. By labeling a namespace with pod-security.kubernetes.io/enforce=restricted, the API server will reject any pod that fails this check, making it a valid and natively supported enforcement mechanism.
- ✓
Deploy a MutatingWebhookConfiguration that adds readOnlyRootFilesystem: true to all pods
Why this is correct
A MutatingWebhookConfiguration can automatically inject readOnlyRootFilesystem: true into every pod's container securityContext during the mutation phase, before validation occurs. This is a valid approach because it transparently fixes non-compliant pod specs and ensures the final object stored in etcd satisfies the requirement, though it requires maintaining a custom webhook deployment.
- ✗
Apply a NetworkPolicy that denies egress
Why it's wrong here
A NetworkPolicy that denies egress governs network traffic by restricting allowed destinations, ports, and protocols at L3/L4; it does not affect container filesystem mounts or securityContext settings. Denying egress cannot make the root filesystem read-only, because the network layer is completely separate from the container runtime's filesystem permissions, so the pod remains vulnerable to writes to its root layer.
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.