Azure Policy
Slide deck explaining Azure Policy: governance tool for enforcing rules on Azure resources. Covers policy definitions, assignments, scopes, effects (Audit, Deny, Remediate), scenarios (allowed regions, required tags, approved VM sizes), initiatives (policy sets), and differences from RBAC.
Azure Policy
Introduction to Azure Policy: governance tool for enforcing rules and standards on Azure resources.
Azure Policy
Introduction to Azure Policy: governance tool for enforcing rules and standards on Azure resources.
Why governance matters
Governance sets rules for how resources should be configured and where they can exist. Consistent standards across teams. Compliance and cost control needs. Rules can 'report', 'block', or 'help fix'. Azure Policy is the guardrail tool.
Azure Policy: what it does
Azure Policy enforces and checks rules for Azure resources. Allowed regions (locations). Required tags (cost/ownership). Allowed tiers/sizes: Stock Keeping Unit (SKU). Required configurations (example: diagnostics).
Policy vs RBAC
RBAC controls permissions; Azure Policy controls resource rules. Azure Policy: what is allowed/required. Role-Based Access Control (RBAC): who can do what. RBAC can allow an action, Policy can still block/flag it. Use both together.
How Azure Policy is built
Policies work when definitions are assigned to a scope and then evaluated for compliance. Policy definition equals the rule (JavaScript Object Notation (JSON)). Policy assignment equals apply rule to a scope. Scope equals where it applies (MG/sub/RG/resource). Compliance equals who passes vs who fails. Definition alone does nothing.
Scope: where policies apply
Scope controls coverage—from one resource group to many subscriptions. Management group can span many subscriptions. Subscription covers all its resource groups. Resource group is a smaller rollout target. Exclusions allow carve-outs.
Policy effects
Effects decide whether you see, stop, or fix non-compliance. Audit equals report non-compliance (visibility). Deny equals block create/update (prevention). Remediate equals help fix when supported. Effect drives the behavior.
Scenario: allowed regions
Use Azure Policy to enforce where resources can be deployed. Requirement: only specific locations. Assign at subscription or management group scope. Deny effect to block non-compliant deployments. RBAC cannot enforce region rules.
Scenario: required tags
Azure Policy can require (or add) tags at the right scope. Example tags: CostCenter, Environment. Assign at management group for many subscriptions. Goal: consistent cost/ownership reporting. Definition must be assigned to take effect.
Scenario: approved VM sizes
Use Audit first for visibility, then Deny to enforce approved SKUs. Restrict Virtual Machine (VM) sizes by Stock Keeping Unit (SKU). Deny blocks non-approved create/update. Start with Audit to measure impact. Policy behavior depends on effect.
Initiatives (policy sets)
An initiative bundles multiple policies into one manageable assignment. Initiative equals policy set (bundle). Apply tags plus regions plus SKUs together. One assignment instead of many. Easier to manage standards at scale.
Avoid these pitfalls
Most issues come from mixing up Policy vs RBAC, or forgetting scope, assignment, and effects. Policy does not equal access control (that's Role-Based Access Control (RBAC)). Definition must be assigned. Scope limits where rules apply. Effect decides: Audit vs Deny vs remediate.