Practice the precise vocabulary used when writing, discussing, and reviewing OPA (Open Policy Agent) policies in Rego: how rules are expressed, how documents are described, and how policy decisions are communicated to teammates.
0 / 10 completed
1 / 10
A colleague asks: 'What is a policy rule in Rego?' Which answer is most precise?
A Rego policy rule is a named expression with a head (rule name and optional value) and a body (a set of conditions). When all conditions in the body are true, the rule's value is defined. Multiple rules with the same head are combined with logical OR — if any fires, the value is produced. Key vocabulary: 'the rule fires,' 'the rule is undefined,' 'the rule produces the set.'
2 / 10
In code review your teammate writes: 'The allow rule uses data.users.admins to check membership.' What is data.users.admins referring to?
The data document in OPA is the global policy data store — not the request being evaluated (that is input). Data can be loaded from files (opa run -d), pushed via the API, or included in a policy bundle. Typical uses: allowlists, role-to-permission maps, feature flags. Phrase pattern: 'we look up the resource in data.approved_images' vs 'we read the image name from input.spec.containers[_].image.'
3 / 10
Which sentence correctly uses 'the policy evaluates to' in a pull-request comment?
'The policy evaluates to ' means: after OPA runs the Rego query, the output is . Correct usage: 'The policy evaluates to deny,' 'The policy evaluates to {"allowed": false, "message": "..."},' 'The allow rule evaluates to true for admin users and false otherwise.' It describes the result of running the policy, not a component in the system.
4 / 10
What is the precise difference between 'the input document' and 'the data document' in OPA vocabulary?
Critical OPA vocabulary distinction: input = per-evaluation context (changes with every query), data = shared policy context (loaded once or periodically refreshed). In Rego you access them as input.field and data.package.field. When explaining a policy: 'We read the requested image from input.spec.containers[_].image and check it against the approved list in data.approved_images.' Confusing them is a common source of bugs.
5 / 10
Your team discusses a policy that should block requests by default. Which Rego idiom and phrase best describes this?
Rego deny-by-default pattern: 'default allow = false' means every query returns allow = false unless an explicit allow rule fires. This is the recommended security posture — you cannot accidentally allow something you forgot to deny. Phrase: 'The policy uses deny-by-default: allow evaluates to true only for requests that satisfy all three conditions in the rule body.' Contrast: allow-by-default ('default allow = true') requires comprehensive deny rules, which are harder to make exhaustive.
6 / 10
Sarah from Security flagged a pull request: 'We need to ensure this rule explicitly denies access based on IP address ranges. The current `deny` rule only mentions 'IP' – it's too vague.' Which of the following best reflects Sarah's concern regarding the policy rule?
Insufficient correctly identifies the core issue. Sarah's point is that a policy rule needs precise details to function effectively – simply stating 'deny' without specifying *how* the denial should occur (e.g., based on IP range) leaves room for ambiguity and potential misinterpretation. The other options misinterpret the meaning or suggest unnecessary constraints.
7 / 10
During a Slack conversation about a newly deployed Rego policy, David says: 'The policy evaluates to true if the user's group is in the 'admin_users' data set.' What does he mean by 'evaluates to' in this context?
Correct accurately describes the technical meaning. 'Evaluates to' signifies that the Rego engine processes the policy logic against provided data and produces a boolean (true or false) result – this is fundamental to how policies operate within OPA. The other options misrepresent the function of evaluation in a policy rule.
8 / 10
You're writing a pull request description for a new Rego policy designed to limit access to sensitive data. You want to explain the core principle clearly. Which of the following phrases best communicates this intent?
Correct provides the most technically sound phrasing. 'Evaluates to true based on user attributes' directly reflects the fundamental operation of a Rego policy: it examines input data and produces a boolean outcome. The other options are either too general or focus on the *effect* of the policy rather than its underlying mechanism.
9 / 10
During a standup meeting, your team lead asks: 'Can you explain how the 'data document' differs from the 'input document' in the context of Rego policy evaluation?' Which of the following is the most accurate response?
Correct provides a precise distinction. The *input document* is the raw data that triggers policy evaluation (e.g., user attributes, request parameters). The *data document* represents derived information based on this input – often pre-computed values or aggregated statistics used within the policy logic itself. This separation enables efficient and reusable policy definitions.
10 / 10
A colleague asks you to draft a Rego rule that should block all requests by default. Which of the following Rego idioms and phrases best describes this approach?
Correct accurately describes the intended action. 'Deny all' is the fundamental Rego idiom for establishing a default-deny policy – it explicitly prevents any requests from proceeding unless specifically allowed by another rule. The other options represent alternative approaches that don't achieve the same core objective of blocking by default.
What will I practice in "OPA Rego Vocabulary — Policy Rules and Documents"?
This is a Policy As Code exercise set. It walks through 10 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 10 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.