role-based access control (RBAC) (canonical definition)

Role-based access control (RBAC) is an authorization system built on Azure Resource Manager that provides fine-grained access management of Azure resources based on roles assigned to users, groups, and service principals.

A top-level Azure container above subscriptions used to group subscriptions for unified governance. Policies and RBAC applied here inherit to all child subscriptions.

An Azure boundary for billing and access control that contains resource groups and resources. Often mapped to environments or business units.

A logical container within a subscription that holds related resources that share a lifecycle, such as an app and its database and storage.

What is Policy scope?

The level of the Azure hierarchy where a policy assignment is applied: management group, subscription, resource group, or resource.

What is Subscription?

An Azure boundary for billing and access control that contains resource groups and resources, often mapped to environments or business units.

Governance Foundations: Azure Policy and Resource Organization — Mastering Microsoft Azure Fundamentals (AZ-900): Complete Exam-Ready Course

Q: Your team accidentally deleted a critical production resource group last month. Management asks you to prevent this from happening again, but they still want the team to update resources inside that group. What should you configure?

A CanNotDelete lock on the resource group. A CanNotDelete lock on the resource group prevents deletion of the group and its resources but still allows updates. ReadOnly would block updates as well, which is not desired. Policy with Audit would not block deletion, and removing RBAC roles would prevent legitimate work.

Why Governance Matters in Azure

Governance vs Management

Governance is about rules and standards. Management is about day-to-day operations. In Azure, governance keeps your environment safe and consistent as it grows.

Analogy: University Policies

University academic policies are like governance. Professors teaching and grading daily are like management. Azure also separates rules from daily operations.

Azure Governance Tools

Azure governance uses Azure Policy, management groups, subscriptions, resource groups, and resource locks to define and enforce rules across your environment.

Why It Matters in 2026

Organizations must prove compliance and manage large, fast-changing cloud estates. Azure governance lets you enforce rules and track compliance at scale.

Azure Resource Organization: Management Groups, Subscriptions, Resource Groups

The Azure Hierarchy

Azure organizes resources as: management groups > subscriptions > resource groups > resources. Governance rules can be applied at any of these levels.

Management Groups

Management groups sit above subscriptions. They group subscriptions for governance. Policies and RBAC set here flow down to all child subscriptions.

Subscriptions and Resource Groups

A subscription is a billing and security boundary. Inside it, resource groups organize related resources that share a lifecycle.

Scopes for Governance

Azure Policy scopes can be a management group, subscription, resource group, or resource. Wider scopes cover more resources with the same rules.

Introducing Azure Policy: The Canonical Definition

Canonical Definition

Azure Policy is a service in Azure that you use to create, assign, and manage policies that enforce rules and effects over your resources, so those resources stay compliant with your corporate standards and service level agreements.

Policy as a Platform Service

Azure Policy is built into Azure Resource Manager. It evaluates resource changes at the platform layer, not inside individual VMs or apps.

Rules and Effects

Policies define conditions and effects. They can deny changes, mark resources non-compliant, or remediate configuration issues.

Policy vs RBAC

RBAC controls who can do what. Azure Policy controls what configurations are allowed, regardless of who is acting.

Governance vs Management: Azure Policy vs RBAC

RBAC: Who Can Do What

RBAC answers who is allowed to perform which actions. It grants permissions like Reader or Contributor over scopes such as subscriptions or resource groups.

Azure Policy: What Is Allowed

Azure Policy answers what configurations are allowed, regardless of who acts. It enforces rules like allowed regions or required encryption.

Typical Scenario Split

Need to control regions or security settings? Use Azure Policy. Need to control which team can manage which resources? Use RBAC.

Exam Trap Reminder

If a question is about configuration standards or compliance, think Azure Policy. If it is about permissions, think RBAC.

Inside Azure Policy: Definitions, Assignments, Parameters, Effects

Policy Definitions

A policy definition describes what is evaluated and what effect to apply. It is the rule template, like “only certain regions are allowed.”

Policy Assignments and Scope

A policy assignment applies a definition to a scope: management group, subscription, resource group, or resource. One definition can have many assignments.

Parameters for Reuse

Parameters let one definition be reused with different settings, such as different allowed regions per subscription.

Effects: Deny, Audit, and More

Effects control behavior: Deny blocks non-compliant changes, Audit flags them, and more advanced effects like DeployIfNotExists can remediate.

Example: Enforcing Allowed Regions with Azure Policy

Scenario: EU-Only Production

A company wants all production resources to stay in EU regions. They have Dev, Test, and Prod subscriptions and must enforce this only in Prod.

Scope and Definition

They choose the Prod subscription as the scope and use the built-in “Allowed locations” policy definition with a parameter for allowed regions.

Assignment and Effect

They assign the policy to Prod with allowedLocations set to West Europe and North Europe, using the Deny effect to block non-EU regions.

Result and Compliance

Any attempt to create resources in disallowed regions is denied, even if RBAC permits it. The compliance dashboard shows which resources meet the rule.

Policy Scope in Practice: Management Groups, Subscriptions, Resource Groups

Management Group Scope

Assign policies at a management group to enforce standards across all child subscriptions, such as a finance-wide security baseline.

Subscription Scope

Use subscription scope for environment or business-unit rules, like allowed regions in a production subscription.

Resource Group and Resource Scope

Resource group scope targets specific apps or projects. Resource scope is rare but can enforce rules on a single critical resource.

Inheritance

Policies inherit down the hierarchy. A management group policy flows to its subscriptions, resource groups, and resources.

Resource Locks: Extra Protection Against Accidental Changes

What Resource Locks Do

Resource locks prevent accidental deletion or modification. They can be applied at subscription, resource group, or resource level.

Lock Types

ReadOnly blocks updates and deletes but allows reads. CanNotDelete allows updates but blocks deletes.

Locks vs Policy vs RBAC

RBAC controls who can act. Policy controls allowed configurations. Locks block dangerous actions even if they are allowed and permitted.

When to Use Locks

Use locks on mission-critical or rarely changed resources, such as production databases or core networking components.

Thought Exercise: Designing Governance for a Simple Environment

Work through this scenario mentally. You do not need to write code, just reason about which Azure features you would use.

Scenario

Your university runs a small Azure environment with:

One management group for the IT department.
Three subscriptions: Dev, Test, Prod.
Each subscription has multiple resource groups for different applications.

The IT lead defines these rules:

All subscriptions must tag resources with `department = IT`.
Only the Prod subscription must restrict regions to West Europe and North Europe.
The main production database must never be deleted by accident.

Your task

For each rule, decide:

Which tool you would use (Azure Policy, RBAC, resource locks, or something else).
At which scope you would apply it (management group, subscription, resource group, resource).

Pause and think it through before reading the suggested solution.

Suggested solution (check your reasoning)

Tagging rule

Tool: Azure Policy (to enforce tags for governance and reporting).
Scope: IT management group, so it applies to all three subscriptions.

Region restriction for Prod

Tool: Azure Policy with an “allowed locations” definition.
Scope: Prod subscription only.

Protect main production database

Tool: Resource lock (CanNotDelete, possibly ReadOnly depending on needs).
Scope: The specific database resource.

Reflect: Did you accidentally use RBAC for any of these where policy or locks were a better fit? That is a common exam pitfall.

Quick Check: Governance Concepts

Test your understanding of the core distinctions between RBAC, Azure Policy, and resource locks.

You need to ensure that no one can create virtual machines in regions outside your approved list, but developers should still be able to create VMs freely within those regions. Which feature is the best fit?

Deny the VM creation action for all users using RBAC
Create an Azure Policy with an 'allowed locations' rule and assign it to the subscription
Apply a CanNotDelete lock to the subscription
Remove Contributor permissions from all developers

Show Answer

Answer: B) Create an Azure Policy with an 'allowed locations' rule and assign it to the subscription

The requirement is about enforcing which regions are allowed, not about who can create VMs. Azure Policy with an 'allowed locations' rule at the subscription scope is the correct governance control. RBAC manages permissions, not configuration standards. Locks prevent deletion or modification, not region selection.

Quick Check: Scopes and Locks

Another short quiz to solidify scopes and when to use locks.

Your team accidentally deleted a critical production resource group last month. Management asks you to prevent this from happening again, but they still want the team to update resources inside that group. What should you configure?

An Azure Policy with the Audit effect on the resource group
A ReadOnly lock on the resource group
A CanNotDelete lock on the resource group
Remove all RBAC roles from the team