Imagine managing 50 subscriptions across multiple teams. Applying RBAC to each one individually would take forever. Management Groups let you apply policies and permissions to all subscriptions at once. Azure Policy then enforces rules automatically (e.g., "all VMs must be encrypted"). Together, they're how enterprises scale governance.
Without management groups: Admin must set policies individually on 7 subscriptions (tedious, error-prone).
With management groups:
Root Management Group (TechCorp)
βββ Finance MG
β βββ Accounting Sub (Policy applies automatically)
β βββ Billing Sub (Policy applies automatically)
βββ Engineering MG
β βββ Dev Sub (Policy applies automatically)
β βββ QA Sub (Policy applies automatically)
β βββ Prod Sub (Policy applies automatically)
βββ Operations MG
βββ Ops Sub (Policy applies automatically)
βββ Backup Sub (Policy applies automatically)
Admin applies one policy at the root level β All 7 subscriptions inherit it automatically.
How Azure Policy Works
Policy = Automated Compliance Rule
Example Policy: "All virtual machines must have encryption enabled"
βββββββββββββββββββββββββββββββββββββββββββββββββββ
β Azure Policy: VM Encryption Required β
βββββββββββββββββββββββββββββββββββββββββββββββββββ€
β IF: Someone creates a VM β
β AND: Encryption is NOT enabled β
β THEN: Block the VM creation (deny) β
β β
β OR (depending on policy): β
β THEN: Create the VM but mark as non-compliant β
βββββββββββββββββββββββββββββββββββββββββββββββββββ
Policy Actions: Deny vs. Audit
Action
What Happens
Use Case
Deny
Block non-compliant action
Critical security rules (encryption, firewall)
Audit
Allow action, but log it as non-compliant
Monitor violations before enforcing
Modify
Automatically fix it
Add tags, enable monitoring, etc.
Common Azure Policies
Policy
What It Enforces
Example
Encryption Required
All storage must use encryption
Block unencrypted storage accounts
Tag Enforcement
All resources must have specific tags
Require "Owner" and "CostCenter" tags
Allowed Locations
Resources can only be created in certain regions
Only allow East US and West US
SKU Restrictions
Resources can only use approved sizes
Only allow Standard_B1s or larger VMs
HTTPS Required
All web apps must use HTTPS
Block HTTP-only apps
Mental Model: Policy as a Gatekeeper
Developer wants to create VM
β
[Azure Policy Check]
Is encryption enabled?
β
ββββββ΄βββββ
β β
YES NO
β β
Create [Deny]
VM Not allowed
(unless audit mode)
Worked Example: Real Scenario
The Scenario
Company Goal:
All VMs must have backup enabled (compliance requirement)
All resources must be tagged with Department and CostCenter (for billing)
Policy 1: "All VMs must have backup enabled"
- Action: Deny non-compliant VM creation
- Scope: Root (applies to all subscriptions)
Policy 2: "All resources must have tags"
- Action: Audit first, then Deny after 30 days
- Required tags: Department, CostCenter
- Scope: Root (applies to all subscriptions)
Policy 3: "Only Standard_B2s or larger VMs allowed"
- Action: Deny small VM creation (too costly)
- Scope: Root (applies to all subscriptions)
Step 3: Result
Developer tries to create:
βββ VM without backup β Policy DENIES (backup required)
βββ VM without tags β Policy DENIES (tags required)
βββ VM size: Standard_B1s β Policy DENIES (too small)
βββ VM with everything correct β VM is created β
Policy: "Deny all VM creation"
β
No one can create VMs (including legitimate business needs)
β
Team stuck, can't deploy applications
Fix
Use audit mode first:
β’ Set policy to "Audit" (log violations, don't deny)
β’ Review violations for 2-4 weeks
β’ See what legitimate use cases exist
β’ Adjust policy to allow legitimate actions
β’ Switch to "Deny" mode once tuned
Why it fails: Policies that are too strict block legitimate work.
β Mistake 2: Inconsistent Management Group Structure
Wrong
Some subscriptions organized by department
Other subscriptions organized by environment
Some subscriptions not in any management group
Result: Policies apply inconsistently
Fix
Plan structure carefully:
β’ All subscriptions must be in a management group
β’ Use consistent structure (by department,
by environment, or both)
β’ Document the structure so others understand it
Why it fails: Inconsistent structure = inconsistent governance.
β Mistake 3: Creating Policy But Never Reviewing It
Wrong
Set policy, forget about it
β
6 months later, policy blocks legitimate business need
β
Team calls admin: "This policy is breaking our work!"
Fix
Set up regular reviews (quarterly):
β’ Check policy compliance reports
β’ Review denied/blocked requests
β’ Adjust policies if they're too strict
β’ Document changes
Why it fails: Policies need maintenance.
Summary: Management Groups vs. Resource Groups
Aspect
Management Group
Resource Group
Purpose
Organize subscriptions
Organize resources
Contains
Subscriptions
Resources (VMs, storage, etc.)
Policies
Policies apply to all subscriptions within it
N/A (policies apply via management groups)
RBAC
Assign roles to all subscriptions at once
Assign roles to specific resources
Use Case
Governance across company
Organization within a subscription
How This Connects to Other Topics
Related to Module 01 (Identity)
RBAC + Management Groups: Assign roles at management group level, inherit across all subscriptions
Example: "Finance team gets Contributor role on Finance management group" β applies to all Finance subscriptions
Related to Module 02 (Storage)
Storage Encryption Policy: Enforce encryption on all storage accounts via policy
Storage Access: Combine policy with RBAC for complete control
Related to Module 04 (Networking)
NSG Policy: Enforce security groups on all resources
Allowed Regions: Use policy to limit resources to specific regions
Related to Module 05 (Monitor)
Audit Logging: See when policies block actions
Compliance Reports: Track which subscriptions violate which policies