Why RBAC Matters

Azure is a multi-tenant, multi-user platform. If access is not properly controlled, users may unintentionally (or maliciously) affect resources outside their scope.

Role-Based Access Control (RBAC) ensures that users, groups, and applications only get the minimum permissions required to perform their tasks — no more, no less.

This principle is known as Least Privilege Access and is a cornerstone of Azure governance.

Key Elements of RBAC

1. Scopes of Assignment

• Management Group → apply roles across multiple subscriptions.

• Subscription → apply at the subscription level.

• Resource Group → apply to all resources inside.

• Resource → apply to a single VM, storage account, etc.

 Permissions cascade down. For example: assigning Contributor at the subscription level gives that role across all resource groups and resources inside it.

2. Built-In Roles

• Owner → Full access + delegate access.

• Contributor → Can create/manage resources but cannot assign roles.

• Reader → Read-only access.

• User Access Administrator → Can assign roles to others.

3. Custom Roles

• Created using JSON.

• Define specific allowed actions (Microsoft.Storage/*/read, Microsoft.Compute/virtualMachines/start/action, etc.).

• Used when built-in roles are too broad.

4. Assignment Targets

• Individual users → not recommended.

• Groups → best practice, easier to manage.

• Service principals (apps) → used for automation.

• Managed identities → secure access for Azure resources.

Best Practices for RBAC Design

1. Follow Least Privilege
   Grant the lowest necessary role (e.g., Reader, not Contributor).

2. Use Groups Instead of Individuals
   Assigning roles to groups reduces management overhead.

3. Use PIM for Elevated Roles
   Combine RBAC with PIM to ensure critical roles are temporary.

4. Separate Duties
   Avoid giving one person Owner on everything. Split responsibilities (e.g., Networking vs Security vs Dev teams).

5. Audit Regularly
   Review role assignments periodically to ensure they still make sense.

Example Enterprise Scenario

A development team needs to manage resources in a Resource Group for testing but must not delete resources in production.

Correct design:

• Assign the Contributor role at the Dev Resource Group.

• Assign Reader role at the Production Resource Group.

This way, developers can fully manage their sandbox but only observe production.

Confusion Buster

• RBAC vs Policy:

  • RBAC controls who can do what.

  • Policy controls what can/cannot be deployed.

• RBAC vs PIM:

  • RBAC defines permissions.

  • PIM manages time-bound activation of those permissions.

Exam Tips

• “Who has permissions at subscription level?” → Look for Owner/Contributor at subscription scope.

• “Restrict users from creating VMs but allow them to view resources” → Reader.

• “Ensure least privilege” → Assign at lowest possible scope.

• “Custom role needed for fine-grained control” → JSON-based RBAC role.

What to Expect in the Exam

• Direct Q: “Which Azure role allows management of resources but not delegation?” → Contributor.

• Scenario Q: “Developers need full access to Dev but only read access to Prod.” → Contributor on Dev RG, Reader on Prod RG.

• Trick Q: “RBAC and Azure Policy are the same.” → False.