3.6 Azure Governance Features: Putting It All Together

Quick Answer: Azure governance = Management Groups (scope) + Azure Policy (resource rules) + RBAC (access) + Resource Locks (protection) + Tags (organization) + Budgets (cost). These tools layer together so one request must pass every relevant gate before it succeeds.

The Azure Governance Stack

No single feature delivers governance; each plays one role and they compound.

The scope hierarchy that ties it together flows top-down: Management Group → Subscription → Resource Group → Resource. Both Policy and RBAC assignments inherit down this chain, so where you assign matters as much as what you assign.

How the Features Interact

Policy + RBAC (complementary gates)

• RBAC decides: Can this identity perform the action?
• Policy decides: Is the resulting resource configuration allowed?
• Both run inside Azure Resource Manager, so an Owner can still be blocked by a Deny policy. Granting access does not exempt anyone from configuration rules.

Management Groups + Policy (inheritance)

• Assign a policy once at the Dev management group and every dev subscription beneath it inherits it.
• Example: "Deny VM SKUs above 4 vCPUs" at the Dev management group stops oversized VMs across all dev subscriptions in one move — far better than per-subscription assignments.

Tags + Cost Management (chargeback)

• Tag resources with Department: Marketing, then filter Microsoft Cost Management by that tag to see Marketing's exact spend and set a tag-scoped budget.

Locks + RBAC (layered protection)

• A CanNotDelete lock on a production resource group blocks accidental deletion even for Owners, while RBAC still governs who may edit — two independent safety nets.

Governance Decision Matrix

Microsoft Purview Compliance Manager

Microsoft Purview Compliance Manager quantifies your posture as a compliance score and lists prioritized improvement actions mapped to standards such as ISO 27001, GDPR, and NIST. It separates Microsoft-managed controls from your-managed controls so you know what you still owe.

On the Exam: Governance questions usually describe a goal and ask which feature fits. Decode the intent — who can act = RBAC, what config is allowed = Policy, don't let it be deleted = Locks, organize/track cost = Tags, apply broadly across subscriptions = assign at a Management Group.

An End-to-End Governance Scenario

A bank consolidates governance under one root management group, then creates child groups for Production and Non-Production. At the Production group it assigns RBAC so only the platform team holds Contributor, and an initiative that denies non-HTTPS storage and restricts regions to two approved data residencies. Those rules inherit to every production subscription automatically, so onboarding a new subscription requires no extra setup — it is compliant by inheritance the moment it joins the group.

Production databases receive CanNotDelete locks so an accidental deletion is impossible even for an Owner. Every resource is tagged with CostCenter and Environment, enabling Finance to chargeback spend per department in Cost Management and to set budget alerts at eighty percent of the monthly cap. Finally, the security team watches Microsoft Purview Compliance Manager to track the bank's compliance score against ISO 27001 and GDPR, working through the prioritized improvement actions it surfaces.

Notice how the layers reinforce each other: RBAC limits who, Policy constrains what, locks prevent accidents, tags drive cost visibility, and management groups make all of it scale through inheritance. A single misconfigured request is checked against every applicable gate before Azure Resource Manager allows it.

Common Traps

• Assign at the management group when a rule must span many subscriptions — do not repeat per subscription.
• A high RBAC role never bypasses a Deny policy; the gates are independent.
• Locks stop deletion, not size or region — those need Policy.
• Compliance Manager measures posture; it does not enforce — Policy enforces.