RBAC Scope & Inheritance

In Azure, permissions are applied at a scope. This scope defines where the role applies. Permissions are automatically inherited downwards unless explicitly overridden with deny assignments.

RBAC Scope Levels

• Management Group → Applies to multiple subscriptions grouped together.
• Subscription → Applies across all resource groups and resources inside.
• Resource Group → Applies to all resources inside that group.
• Resource → Applies to a single resource (VM, Storage Account, etc.).

How Inheritance Works

• Assign a role at a higher level (e.g., Subscription), and it automatically flows down to lower levels (Resource Groups, Resources).
• Assign at a lower level (e.g., single VM), and it applies only there.
• You cannot break inheritance — only add more specific permissions lower down.

Confusion Buster 🚨

RBAC vs IAM in AWS
– In Azure, RBAC inheritance is always top-down and cannot be blocked.
– In AWS IAM, you can create more fine-grained policies with explicit denies.
Exam trick: Microsoft loves to test that “RBAC inheritance cannot be broken.”

Simple Example

You assign Mary the Reader role at the Subscription level. She can now view all Resource Groups and all resources inside. If you also assign her Contributor role at one Resource Group, she can manage resources only in that group, while being read-only everywhere else.

Exam Tip

Always identify the lowest scope mentioned in the question. If the requirement is resource-specific, don’t over-assign at a higher scope.

What to Expect in the Exam

• Direct Q: “If you assign a role at the subscription level, where does it apply?” → Subscription, RG, and all resources.
• Scenario: “User must manage only one storage account but see nothing else.” → Assign Contributor at the Storage Account resource scope.
• Trick Q: “You can block inheritance of RBAC permissions at the RG level.” (False).