CKS Minimize Microservice Vulnerabilities Practice Question
An admin wants to enforce that all pods in a namespace use a read-only root filesystem except for a specific deployment that needs to write to a temporary directory. Which approach best meets this requirement?
⚠ Common exam trap
CNCF often tests the distinction between mutating webhooks (which can set defaults but require careful exception handling) and validating webhooks like Gatekeeper (which can enforce policies with label-based exceptions), leading candidates to choose the simpler but less robust mutating approach.
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
✓
Use a Gatekeeper Constraint that denies pods with readOnlyRootFilesystem not set to true, but add an exception label on the specific deployment's namespace or pod, and modify the Constraint to skip pods with that label
Gatekeeper (OPA/Gatekeeper) allows you to define a Constraint that denies pods without `readOnlyRootFilesystem: true`, and you can add an exception label on the specific deployment's pod template. By modifying the Constraint to skip pods with that label (using a `labelSelector` or `excludedNamespaces` in the Constraint's spec), you enforce the policy for all pods except the exempted deployment, meeting the requirement without manual patching or legacy PSPs.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Use a Gatekeeper Constraint that denies pods with readOnlyRootFilesystem not set to true, but add an exception label on the specific deployment's namespace or pod, and modify the Constraint to skip pods with that label
Why this is correct
Gatekeeper, built on the OPA admission controller, can enforce a Constraint that rejects any Pod whose spec does not set readOnlyRootFilesystem: true. By configuring the Constraint's match to exclude a specific label placed on the exception Pod or its namespace, administrators gain per-workload exemptions without weakening the overall policy. This approach is declarative, versionable in Git, and applies at admission time, so the exemption is explicit and auditable. It is fundamentally different from a mutating default because the policy actively denies non-compliant Pods while allowing known exceptions.
- ✗
Set a default readOnlyRootFilesystem: true via a mutating webhook, and then manually patch the specific deployment after creation
Why it's wrong here
While a mutating webhook can inject `readOnlyRootFilesystem: true` into every Pod, the subsequent manual patch to the exception Deployment is a fragile, one-time action. If that Deployment is rolled, scaled, or recreated, the patch is lost, and the Pod may become non-compliant or fail, depending on the image. Moreover, this approach requires operational coordination and does not scale across many exceptions, making it unsuitable for a namespace-wide policy with a single exception.
- ✗
Modify the PodSecurityPolicy to allow readOnlyRootFilesystem: false for the specific deployment's service account
Why it's wrong here
PodSecurityPolicy (PSP) is deprecated and slated for removal, so relying on it to enforce root filesystem policy is invalid for modern clusters. Even when PSP existed, it was bound to ServiceAccounts and not to individual Deployments or labels, so carving out a single Deployment required creating and binding a separate PSP with `readOnlyRootFilesystem: false` to that ServiceAccount. That separation is coarse and cannot express a label-based exception for one Pod while keeping the rest of the namespace read-only.
- ✗
Set readOnlyRootFilesystem: true in the deployment's pod template and add an emptyDir volume for the temporary directory
Why it's wrong here
Editing the Deployment's pod template to set `readOnlyRootFilesystem: true` and mounting emptyDir for `/tmp` only hardens that particular workload; it does nothing to enforce the same requirement on other Pods in the namespace. An emptyDir volume is writable but does not negate the read-only root filesystem; it simply provides a scratch space. The key problem is that this is a per-Deployment change, not a namespace-wide policy, so an administrator cannot rely on it to satisfy the enforcement 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 →
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.