Azure Policy changes happen in most enterprises like this… somebody made a careful change in the portal, copied a few notes into a ticket, and hoped nobody else touched the same thing the next day.
It works until it doesn’t. The day you have to explain why a new policy broke a critical deployment, or why ten subscriptions drifted from the baseline, the portal stops feeling like a control plane and starts feeling like a shared Google Doc with no track changes.
Move policy to pull requests. This is the change, insight into what gets better, and the parts that surprise us.
Who this is for
Platform engineering, cloud ops, and governance teams running Azure at scale
Anyone managing policy across management groups and many subscriptions
Teams that want guardrails without turning every change into a meeting
Before: portal-first policy feels fast, but it is fragile
The portal makes policy feel easy. You can tweak an effect, hit Save, and see it live right away.
The problem is that speed without process is just risk moving faster.
Here is what we run into:
No reliable review. A change could be technically valid but operationally dangerous.
Hard to answer basic questions later: Who changed it? Why? What else was updated?
Inconsistent rollouts. Some scopes get updated, others lag, and drift becomes normal.
Exceptions are a mess. Some live in email, some in tickets, some in people’s heads.
Testing is informal. Most validation happens after a deployment fails.
We are not missing tools. We are missing a repeatable workflow that makes the safe path the default.
After: policy moves to PRs, the workflow does the heavy lifting
Moving policy to PRs is not just “store JSON in Git.” The real win is that the PR becomes the unit of change: reviewable, testable, and auditable.
What changes
A single repo becomes the source of truth for policy definitions, initiatives, and assignments.
Every change requires a PR with an owner, a reason, and a rollout plan.
Automated gates validate policy structure, parameters, and scope impact before merge.
Exemptions become explicit objects with metadata, expiry dates, and ownership.
Rollout moves to rings: canary first, then broader scope once signals stay clean.
The new shape of work
Here is how the flow looks once things settle down. Notice how little of it depends on hero knowledge.
Author opens a PR with the policy change and a short rationale written for operators, not auditors.
PR template forces the basics: scope, effect changes, blast radius, and a backout plan.
Automated checks run: JSON schema validation, naming standards, and “what changed” diffs for initiatives and assignments.
A test deployment hits a safe scope (dev management group or a known subscription) using What-If and then an apply.
Reviewers sign off using Code Owners rules so the right teams see the PR (platform, security, networking, FinOps).
Merge triggers a controlled rollout: canary, pause, expand, repeat.
If something goes sideways, rollback is a commit. Not a scramble.
Before vs after, in one table
The PR gates that mattered most
Validation to your heart’s content. Only a few are truly non-negotiable.
Here are the ones that kept us out of trouble:
Policy schema and parameter validation. No “it deployed but behaves weird” surprises.
Diff-aware review. The pipeline summarizes effect changes so reviewers do not have to read raw JSON to understand risk.
What-If against the target scope. If the plan is scary, you see it before it is live.
Ring-based deployment controls. Canary scope first, then a pause before broad rollout.
Automated policy assignment identity checks (managed identity roles, permissions, and required locations).
Exemptions stop being a loophole and become a control
If you operate at scale, you will have exceptions. The question is whether you can explain them, defend them, and delete them later.
PR-based workflow gives us a clean pattern:
Every exemption is a file with the owner, reason, scope, and expiry.
No expiry means it fails review. Permanence needs a real argument.
Exemptions live next to the policy they override, so context is never lost.
Quarterly review is easy: search for exemptions expiring in the next 30 days and clean up.
Results: fewer surprises, cleaner ownership, and faster safe changes
The biggest shift is cultural: policy stops being “something the platform team does to you” and becomes “a change request you can see and review.”
Practical benefits almost immediately:
Audit trail became automatic. The PR captures intent, discussions, approvals, and rollout notes.
Drift drops because we have one source of truth and repeatable deployments.
Rollbacks get boring. That is a compliment.
Review quality improves because the right people are pulled in consistently via Code Owners.
Moving from portal changes to pipeline-based deployments cuts policy deployment cycle times, and review and rollouts become repeatable instead of being reinvented every time.
What surprises us
People stop fearing policy changes once they can see the blast radius in the PR.
The first month feels slow. Then the firefights go away, and overall velocity increases.
The repo structure matters more than the pipeline. If files are hard to find, everything suffers.
Exemption hygiene is the difference between “governed” and “policy theater.”
If you want to try this: a quick operator checklist
You can start small. Pick one initiative, one scope, and one PR gate. Make the workflow real, then widen it.
Choose your first scope. A management group is ideal for consistency, but start with a safe ring if your org is nervous.
Create a repo layout that separates definitions, initiatives, assignments, and exemptions.
Write a PR template that forces scope, reason, effect changes, rollout ring, and rollback plan.
Add the minimum gates: schema validation and What-If. Anything else is optional at first.
Define Code Owners and require review from the platform plus the domain team most impacted (security, networking, FinOps).
Ship canary rollouts with a pause. Treat policy like production code.
Make exemptions time-bound and review them on a cadence.
Closing thought
Moving policy to PRs does not make governance stricter. It makes governance clearer. That clarity is what makes teams faster, because nobody has to guess what will happen after a policy change.