What is Policy as Code and Why Use It in DevOps?
Learn what policy as code is, how OPA and Sentinel enforce rules automatically, and where checkpoints run — a DevOps interview answer.
Expected Interview Answer
Policy as code is the practice of writing an organization’s compliance, security, and operational rules — like "no S3 bucket may be public" or "every deployment must have resource limits" — as machine-readable, version-controlled code that is automatically evaluated against infrastructure or application changes, rather than enforced through manual review or a document nobody reads.
Instead of a wiki page listing security guidelines that engineers may or may not remember to check, policy as code encodes those rules in a policy engine such as Open Policy Agent (using the Rego language) or HashiCorp Sentinel, and evaluates them automatically at defined checkpoints: a pre-merge check against a Terraform plan, an admission-control check before a Kubernetes Pod is scheduled, or a pre-deploy gate in a CI/CD pipeline. Policies are typically written to `allow`, `warn`, or `deny` an action based on structured input (like a Terraform plan JSON or a Kubernetes manifest), and because they live in version control alongside the infrastructure code they govern, they get code review, testing, and change history just like application code. This turns tribal knowledge and manual audits into consistent, automatically enforced guardrails that scale across every team and every pipeline, without requiring a human reviewer to manually re-check every diff for a public bucket or an overly permissive IAM role.
- Enforces security and compliance rules consistently across all teams
- Shifts governance left, catching violations before deployment instead of after an audit
- Version-controls policy alongside infrastructure for review and change history
- Removes reliance on manual checklists and tribal knowledge
AI Mentor Explanation
Policy as code is like replacing a verbally-remembered list of ground rules with a written rulebook that the match officials’ review system automatically checks against every delivery — no-ball line, front-foot fault, bowling restrictions — rather than trusting umpires to remember every rule from memory each time. The system automatically flags a violation the instant it happens, consistently, regardless of which umpire is standing that day. This turns rules that used to depend on individual memory into something enforced the same way every single match. A bowler cannot argue the rule was applied differently last week.
Step-by-Step Explanation
Step 1
Write the rule as code
Encode a compliance rule (e.g. no public S3 buckets) in a policy language like Rego or Sentinel.
Step 2
Define the checkpoint
Decide where the policy is evaluated: pre-merge on a Terraform plan, admission control on Kubernetes, or a CI/CD gate.
Step 3
Evaluate against structured input
The engine reads structured input (plan JSON, manifest) and returns allow, warn, or deny.
Step 4
Version and test the policy
Store policies in version control with their own tests, reviewed and changed like application code.
What Interviewer Expects
- Understanding that policy as code replaces manual review with automated, machine-readable rules
- Knowledge of at least one concrete tool (OPA/Rego, Sentinel)
- Awareness of common checkpoints: pre-merge, admission control, CI/CD gate
- Recognition that policies are version-controlled and tested like other code
Common Mistakes
- Confusing policy as code with general infrastructure testing
- Not distinguishing allow/warn/deny enforcement modes
- Writing policies that are never version-controlled or code-reviewed
- Assuming policy as code replaces all manual security review entirely
Best Answer (HR Friendly)
“Policy as code means we write our compliance and security rules — like 'no public storage buckets' — as actual code that automatically checks every infrastructure change, instead of relying on someone remembering to check a document. It gets applied the same way every time, for every team, which closes gaps that manual review can miss and lets us catch problems before they ever reach production.”
Code Example
package terraform.s3
deny[msg] {
resource := input.resource_changes[_]
resource.type == "aws_s3_bucket_acl"
resource.change.after.acl == "public-read"
msg := sprintf("Public S3 ACL not allowed: %s", [resource.address])
}Follow-up Questions
- What is the difference between OPA and HashiCorp Sentinel?
- How would you roll out a new policy without breaking existing pipelines?
- What is the difference between an advisory (warn) policy and a hard-blocking (deny) policy?
- How does policy as code integrate with Kubernetes admission control?
MCQ Practice
1. What is the core idea behind policy as code?
Policy as code encodes governance rules as version-controlled, automatically evaluated code rather than manual, document-based review.
2. Which of these is a common checkpoint where policy-as-code engines run?
Policy engines are typically wired into pre-merge checks, Kubernetes admission control, or CI/CD deployment gates to catch violations automatically.
3. What language does Open Policy Agent primarily use to write policies?
OPA policies are written in Rego, a declarative query language purpose-built for expressing policy rules over structured data.
Flash Cards
What is policy as code? — Compliance and security rules written as version-controlled, machine-readable, automatically enforced code.
Name two policy-as-code engines. — Open Policy Agent (Rego) and HashiCorp Sentinel.
Where do policy checks commonly run? — Pre-merge plan checks, Kubernetes admission control, and CI/CD deployment gates.
Why version-control policies? — So they get code review, testing, and change history like the infrastructure code they govern.