CKS Minimize Microservice Vulnerabilities Practice Question
You need to enforce that all pods in the 'production' namespace run with read-only root filesystems. Which OPA Gatekeeper resource do you create first?
⚠ Common exam trap
The exam often tests the order of Gatekeeper resources: candidates mistakenly think a Constraint (option C) is created first, but the ConstraintTemplate must exist first to define the Rego logic, as the Constraint only applies the rule.
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
✓
A ConstraintTemplate containing a Rego policy that checks for readOnlyRootFilesystem: true
OPA Gatekeeper requires a ConstraintTemplate first to define the Rego policy logic that checks for `readOnlyRootFilesystem: true`. The ConstraintTemplate is a custom resource that tells Gatekeeper what rule to enforce; without it, you cannot create a Constraint to apply the policy to the 'production' namespace. This follows the Gatekeeper workflow: template → constraint → enforcement via admission webhooks.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
A ConfigMap containing the Rego policy, then reference it in a custom admission controller
Why it's wrong here
Gatekeeper does not use ConfigMaps for Rego policies; ConfigMaps store plain key/value or file data and are not interpreted as OPA policy by the admission controller. A custom admission controller would require you to implement and deploy your own webhook server, load the Rego from the ConfigMap, and register it — completely bypassing Gatekeeper's declarative ConstraintTemplate workflow. Even then, a ConfigMap lacks the schema and custom resource definitions that Gatekeeper uses to validate constraints, making it an unsuitable and non-standard approach for policy enforcement in a CKS context.
- ✓
A ConstraintTemplate containing a Rego policy that checks for readOnlyRootFilesystem: true
Why this is correct
A ConstraintTemplate is the correct and mandatory first step for defining Gatekeeper policy because it wraps the Rego logic in a custom resource definition (CRD) that the Gatekeeper controller can process. The `spec.targets[].rego` field in the template contains the actual OPA policy, which evaluates `input.review.object.spec.containers` to enforce `readOnlyRootFilesystem: true`. Creating the ConstraintTemplate before instantiating a Constraint ensures the policy logic exists and is compiled, because the Constraint merely references the template and supplies matching rules and parameters — without the template, no enforcement can occur.
- ✗
A Constraint resource that enforces the readOnlyRootFilesystem rule
Why it's wrong here
A Constraint resource alone is insufficient because a Constraint is an instance of a ConstraintTemplate — it does not carry the Rego policy logic itself. The Constraint's role is to declare which resources to match (e.g., pods in the production namespace) and to pass parameters to the template's policy. If no ConstraintTemplate exists, the Constraint will fail to be recognized or will be non-functional, since the Gatekeeper controller depends on the template to load the underlying OPA policy that actually performs the security check.
- ✗
A ValidatingWebhookConfiguration that points to the Gatekeeper service
Why it's wrong here
While Gatekeeper does rely on a ValidatingWebhookConfiguration to route admission requests to its controller-manager service, that webhook is part of the Gatekeeper installation itself and is not the place to define policy. Manually creating a ValidatingWebhookConfiguration that points to the Gatekeeper service is redundant or dangerous — it does not contain any Rego, and without a pre-existing ConstraintTemplate and Constraint, there is no policy for the webhook to evaluate. Moreover, a misconfigured webhook (e.g., wrong service path or failure policy) can block all cluster admission requests, so the correct sequence is to install Gatekeeper (which manages the webhook), then create the ConstraintTemplate, then the Constraint.
Go deeper
Related to this question
Learn chapter
Supply Chain Security: Policy Enforcement and Admission Controllers
Key term
Admission Controllers
Admission controllers are plugins that intercept and process requests to the Kubernetes API server after authentication and authorization, but before the request is persisted, allowing policies to be enforced on objects being created, modified, or deleted.
Key term
OPA Gatekeeper
OPA Gatekeeper is a Kubernetes admission controller that enforces custom security and compliance policies on resources before they are created or updated in a cluster.
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.