Practice Kubernetes policy vocabulary: Pod Security Admission, pod security standards, admission controllers, Kyverno policies, and network policy generation.
0 / 15 completed
1 / 15
What does PSA stand for in Kubernetes policy?
PSA (Pod Security Admission) replaced PodSecurityPolicy in Kubernetes 1.25+. It enforces built-in security standards (privileged, baseline, restricted) at the namespace level.
2 / 15
What is the 'restricted' pod security standard?
The 'restricted' pod security standard is the most hardened PSA level. It enforces: non-root containers, read-only root filesystem, no privilege escalation, no hostPath volumes, and limited capabilities.
3 / 15
'The admission controller ___ the pod.' Which verb fits a blocking action?
'Rejected' is the standard term: the admission controller rejected the pod because it violates a policy (e.g., runs as root under the restricted standard). The pod is not created.
4 / 15
What is Kyverno used for in Kubernetes?
Kyverno is a Kubernetes-native policy engine. Unlike OPA/Rego, policies are written in YAML. It can validate resources (block non-compliant), mutate them (add defaults), and generate related resources.
5 / 15
'The policy ___ default network policies.' Which verb describes Kyverno creating resources automatically?
Kyverno's 'generate' rule automatically creates companion resources — e.g., when a new namespace is created, Kyverno can generate a default NetworkPolicy that denies all ingress/egress by default.
6 / 15
Reviewer: 'I'm seeing a `Pod` created with `resources.limits` set to `0`. This violates our policy to ensure all pods have some CPU and memory allocated. Can you explain how Kyverno is enforcing this? This seems like a critical security oversight.
This question tests understanding of Kyverno's enforcement capabilities. Kyverno policies can be applied at the Pod level to ensure specific resource constraints are met, preventing potential denial-of-service attacks or misconfigurations. The correct answer highlights the policy's proactive role in controlling resource usage for individual pods.
7 / 15
Dev1 (Sarah): 'Hey team, just noticed a PR that's attempting to create a `Deployment` with no labels. We need those for proper application tracking in our monitoring tools. I'm going to use Kyverno to block this until it's fixed. Anyone know how we can configure Kyverno to require specific labels on Deployments?'
This scenario assesses understanding of Kyverno's policy configuration. The correct answer focuses on Kyverno's ability for admins to create custom policy rules that specify label requirements – a core function of its flexible rule engine. The other options present misconceptions about how Kyverno operates or the default behavior.
8 / 15
Reviewer: 'The PR is attempting to scale the ReplicaSet with a request rate exceeding 1000 requests per second. Our policy prevents this to avoid overwhelming the backend services. Can you confirm Kyverno is actively limiting this scaling behavior?'
Kyverno's primary function is to prevent undesirable deployments and configurations by actively blocking them. Option 1 accurately describes how Kyverno would implement a scaling limit based on resource constraints, directly addressing the reviewer's concern. Options 2, 3, and 4 represent other potential responses or actions, but don't reflect Kyverno's core enforcement mechanism.
9 / 15
Reviewer: 'We're seeing a deployment attempting to use a private DNS name without explicit authorization. Our policy requires all deployments to be configured with approved DNS names via a Policy Resource. Can you investigate how Kyverno is handling this and ensure it's correctly blocking unauthorized access?'
This scenario tests understanding of Policy Resources and their role in defining allowed configurations. The correct answer focuses on *implementing* a whitelist – this is how Kyverno actually enforces policies by creating constraints. Options B and C represent misinterpretations: disabling enforcement would bypass the policy entirely, while simply removing authorization doesn't address the core issue of using unauthorized names.
10 / 15
Dev1 (Mark): 'I've been reviewing PRs and noticed several deployments are being created with overly permissive security contexts. Our policy is setting a minimum `allowPrivilegeEscalate` to `false`. Can you explain how Kyverno identifies these violations and what actions it's taking?'
The correct answer highlights Kyverno's event-driven approach. It actively *monitors* Kubernetes events (specifically deployment creation) and triggers a policy violation when it detects non-compliant configurations. Options A is incorrect as Kyverno doesn't directly scan all YAML; B misrepresents the matching mechanism, and C suggests a manual process which isn't how Kyverno operates.
11 / 15
Reviewer: 'I'm seeing a deployment attempting to expose port 8080 publicly. Our policy restricts external access to only specific services and ports. Can you explain how Kyverno is preventing this exposure?' Which of the following best describes Kyverno's action in this scenario?
Kyverno operates through admission control – it actively *blocks* requests that violate configured policies. Option A describes redirection, which is not Kyverno's primary function. Option B is incorrect because Kyverno doesn't disable network policy creation entirely; it enforces specific rules. The correct answer reflects Kyverno's core mechanism of preventing unauthorized deployments based on policy constraints.
12 / 15
Dev1 (David): 'Just noticed a PR trying to deploy a StatefulSet with no resource requests. Our policy mandates minimum CPU and memory requests for all StatefulSets to ensure proper scaling and stability. Can you confirm Kyverno is actively enforcing this?' Which statement accurately reflects Kyverno's response?
Kyverno's role is primarily *preventative*; it actively *rejects* requests that don't adhere to defined policies. Option A describes a notification system, which Kyverno doesn't implement directly. Option B is an unnecessary reporting action; Kyverno focuses on blocking. The correct answer reflects the core function of admission control – preventing non-compliant deployments.
13 / 15
PR Description: 'This PR introduces a new deployment for our analytics service. We've configured it to use the default Kubernetes network policy. However, I'm getting an error indicating that Kyverno is blocking this deployment due to a lack of explicit network policy definitions. Can you explain how Kyverno handles these situations?'
Default policies are commonly used in Kyverno. The correct answer reflects Kyverno's ability to *automatically generate* basic network policies based on service configurations – this is a key feature of its operational simplicity and ease of use. Options B and C represent manual intervention that Kyverno avoids, while option D is an overly aggressive action.
14 / 15
Dev1 (Emily): 'During my daily stand-up, I mentioned that we're using Kyverno to enforce a policy restricting pod privileges. Specifically, we've set a minimum `allowPrivilegeEscalate` value of `false`. I wanted to confirm if Kyverno is correctly preventing pods from gaining elevated privileges.' Which action does Kyverno take when it detects a violation?
Kyverno's role is *preventative* and *enforcement*. The correct answer accurately describes its core function: it *blocks* deployments that violate privilege escalation restrictions. Options A and B represent actions Kyverno doesn't directly perform; option C reflects the fundamental principle of admission control, and D involves a separate alerting mechanism.
15 / 15
API Response (Kyverno Policy Engine): {
"status": "error",
"message": "Deployment creation blocked due to policy violation: 'No approved DNS names'.",
"policy": "dns-validation"
}
This API response clearly indicates a *policy violation* – specifically, the failure to comply with the 'dns-validation' policy. The message explains that Kyverno is monitoring the deployment's DNS configuration, which is central to its function. Option A and B are incorrect; option D would require more granular details within the response.
What will I practice in "Kubernetes Policy Vocabulary"?
This is a Policy As Code exercise set. It walks through 15 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 15 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.