Practice the vocabulary of enforcing compliance rules as automatically evaluated code.
0 / 5 completed
1 / 5
At standup, a dev mentions expressing an organization's security and compliance rules as version-controlled code that's automatically evaluated against infrastructure changes, instead of a manually enforced written policy document. What is this practice called?
Policy as code expresses an organization's security and compliance rules as version-controlled code that's automatically evaluated against an infrastructure or configuration change, rather than relying on a manually enforced written policy document that a person has to remember and apply consistently. A manually enforced document depends entirely on human diligence and doesn't scale as the number of changes and reviewers grows. Policy as code applies the same rules consistently and automatically to every change, catching a violation a person might otherwise miss.
2 / 5
During a design review, the team wants a proposed infrastructure change to be automatically evaluated against the policy rules before it's allowed to merge or deploy. Which capability supports this?
A policy evaluation gate integrated into the CI/CD pipeline automatically checks a proposed infrastructure change against the defined policy rules before it's allowed to merge or deploy, catching a violation before it ever reaches production. Evaluating policy manually only after a change has already deployed means a violation is discovered after the fact, when it's already live and potentially causing harm. This pre-deployment gate is what makes policy as code a genuinely preventive control rather than just a retrospective audit tool.
3 / 5
In a code review, a dev notices a policy rule is written in a dedicated policy language, like Rego, and tested with its own unit tests before being applied to real infrastructure changes. What does this represent?
Testing a policy rule as code, written in a dedicated policy language and covered by its own unit tests, catches a bug in the policy rule itself, like an overly broad or incorrectly scoped condition, before that flawed rule starts blocking or allowing the wrong changes. Writing an untested, informal policy note risks the policy itself containing a subtle logic error nobody catches until it causes a real problem. Treating a policy rule with the same testing discipline as application code is a natural consequence of policy as code being genuinely code, not just documentation.
4 / 5
An incident report shows a policy rule intended to block a public storage bucket had an off-by-one logic error, silently allowing several public buckets to be created before anyone noticed the flaw. What practice would prevent this?
Writing automated tests for a policy rule itself, verifying it correctly blocks a known-bad case and allows a known-good one, catches a logic error in the rule before it's enforced against real infrastructure changes. Deploying a rule with no test coverage of its own logic risks exactly this kind of silent, undetected flaw letting a genuinely non-compliant change slip through. This test coverage of the policy rule's own correctness is just as important as testing any other piece of code the organization depends on.
5 / 5
During a PR review, a teammate asks why the team enforces security and compliance rules through policy as code instead of relying on a manually enforced written policy document reviewed by a person. What is the reasoning?
A manually enforced written policy document depends on a person consistently remembering and correctly applying every rule to every single change, which realistically varies with reviewer diligence, workload, and familiarity with the rules. Policy as code applies the same rules automatically and consistently to every change through an evaluation gate. The tradeoff is the upfront engineering investment of writing, testing, and maintaining the policy rules themselves as actual code rather than prose.