Practice the precise vocabulary used when configuring and communicating about Kubernetes admission controllers: mutating vs. validating webhooks, policy enforcement decisions, OPA Gatekeeper language, and how to explain a rejected workload to a teammate.
0 / 5 completed
1 / 5
A developer asks why their Deployment failed. You say: 'The pod was rejected because...' — which completion is grammatically and technically correct?
'The pod was rejected because...' is the standard phrasing for an admission denial. The correct completion identifies: (1) which webhook type made the decision (validating), (2) which specific policy was violated, (3) which enforcement tool detected it (OPA Gatekeeper). A mutating webhook timeout would usually cause a failure-open or failure-closed error, not a clean policy rejection. Schema validation errors come from the API server before admission webhooks run.
2 / 5
What is the key operational difference between a mutating webhook and a validating webhook in Kubernetes?
Admission chain order: (1) authentication/authorization, (2) mutating admission webhooks (can modify), (3) object schema validation, (4) validating admission webhooks (can only allow/deny). Practical use: mutating webhook injects the Linkerd proxy sidecar into every pod automatically. Validating webhook (OPA Gatekeeper) then checks the final pod spec — including the injected sidecar — against policy. Key phrase: 'the mutating webhook sets the default runAsNonRoot value; the validating webhook enforces it.'
3 / 5
What is 'policy enforcement' in the Kubernetes admission controller context?
Policy enforcement via admission controllers: the policy is enforced at the Kubernetes API server — not in CI, not by convention, but as a hard technical control. A developer cannot deploy a non-compliant resource even if they try to. Key vocabulary: 'hard enforcement' (deny with error), 'soft enforcement' or 'audit mode' (allow but log/alert), 'dry-run mode' (test policy impact without blocking). OPA Gatekeeper supports audit mode: it evaluates existing resources without blocking new ones.
4 / 5
In OPA Gatekeeper vocabulary, what is the relationship between a ConstraintTemplate and a Constraint?
Gatekeeper vocabulary: ConstraintTemplate (cluster-admin installs) defines the Rego logic and creates a new CRD kind — e.g., K8sRequiredLabels. Constraint (team installs an instance) specifies where the policy applies and its parameters — e.g., 'require labels: app, owner on all Pods in namespace production.' This separation allows a platform team to author policies (templates) that app teams configure (constraints). Phrase: 'There is a K8sRequiredLabels constraint in the production namespace enforcing the app and owner labels.'
5 / 5
Fill in the blank: 'We set the webhook's failurePolicy to _____ during the Gatekeeper rollout so that a webhook outage would not block all deployments across the cluster.'
failurePolicy in a Kubernetes webhook configuration: Fail (default) = if the webhook is unreachable, deny the request (safe but operationally risky during rollout). Ignore = if unreachable, allow the request through (available but policy not enforced during outage). Common rollout strategy: start with failurePolicy: Ignore and low replica count, validate webhook stability, then switch to Fail for hard enforcement. Phrase: 'We are using failurePolicy: Ignore during the pilot — we will harden to Fail once Gatekeeper is HA-configured.'
What will I practice in "Admission Controller Vocabulary — Kubernetes Policy"?
This is a Policy As Code exercise set. It walks through 5 scenario-based multiple-choice questions built around real usage of policy as code terminology that IT professionals encounter on the job.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to complete with no account, sign-up, or paywall.
How many questions are in this exercise?
This set contains 5 questions. Each one shows immediate feedback and a detailed explanation after you answer, so you learn the correct usage right away rather than waiting for a final score.
Do I need prior experience to complete this exercise?
No prior experience is required. Each question includes a full explanation covering the reasoning behind the correct answer, so the exercise itself teaches the policy as code vocabulary as you go.
Can I retry the exercise if I get questions wrong?
Yes — use the "Try again" button on the results screen to reset your answers and go through all the questions again. There is no limit on attempts.
Is my progress saved?
Your answers and score for the current session are tracked in the browser as you go. No account or login is needed, and there is nothing to install.
What if I don't understand a term used in a question?
Read the explanation shown after you answer each question — it breaks down the correct term in plain English with a real-world example. You can also check the site Glossary for quick definitions.
How is this different from reading a blog article on the topic?
Exercises like this one are interactive drills that test and reinforce specific vocabulary through multiple-choice questions, while blog articles explain concepts in prose. Practising here after reading builds active recall, not just passive recognition.
Where can I find more Policy As Code exercises?
See the Policy As Code exercises hub for the full set of related pages, or browse all exercise categories from the main Exercises index.
Can I use this exercise to prepare for a technical interview?
Yes — policy as code vocabulary comes up often in technical discussions and interviews. Pair this exercise with our dedicated Interview Preparation section for role-specific practice.