Configuring Role-Based Access Control in Azure

Overview and What You Will Learn

In this lab, you will assign a built-in RBAC role to a user scoped to a single Resource Group, verify that access actually works as expected, and understand why picking the correct scope matters as much as picking the correct role.

Why This Matters in Production

At a payments company like Razorpay, a contractor granted Contributor access at the Subscription level instead of a single Resource Group can accidentally modify or delete production resources belonging to teams they were never supposed to touch. RBAC scoped correctly the first time prevents this category of incident entirely, rather than relying on people simply being careful.

Core Principles

Every RBAC assignment in Azure has exactly three parts, and all three must be set correctly for access to work as intended.

Scope can be set at four levels, and permissions granted higher up automatically apply to everything beneath.

Three built-in roles cover almost every real scenario: Owner (full access, including granting access to others), Contributor (full access to manage resources, but cannot grant access), and Reader (view-only, no changes at all).

Remember

Owner includes the ability to grant other people access - a capability most day-to-day tasks never actually need. Default to Contributor unless a specific requirement genuinely calls for Owner.

Detailed Step-by-Step Practical Lab

1. Create a Resource Group to scope the access assignment to:

2. List the built-in roles available, to see the options beyond just Owner/Contributor/Reader:

3. Get the object ID of the user you want to assign access to:

4. Assign the Contributor role, scoped only to the lab Resource Group, not the whole subscription:

Note

Using --resource-group instead of no scope flag at all is what keeps this assignment narrow. Omitting it and using --scope with a subscription-level path instead would grant Contributor across every Resource Group in the entire subscription.

5. Verify the assignment was created correctly and check exactly what scope it applies to:

6. Confirm the user cannot act outside that scope by attempting an action in a different Resource Group (as that user, via their own CLI session) and observing the expected access-denied result.

7. Remove the role assignment once the lab is complete:

8. Clean up the Resource Group:

Production Best Practices & Common Pitfalls

Common Mistake

Assigning the Owner role by default "just in case something needs more permission later." Owner's ability to grant access to others is rarely actually needed for daily work, and it meaningfully expands what a compromised account could do. Start with Contributor and escalate only when a specific need genuinely requires it.

Tip

Use Groups instead of individual user assignments wherever more than one or two people need the same access. Assigning a role to a group once, then adding and removing members from that group, is far easier to audit than tracking dozens of individual role assignments.

• Prefer the narrowest scope that gets the job done. If someone only needs access to one Resource Group, scope the assignment there, not at the Subscription level "to save time."
• Review role assignments periodically, not just when they are created. Access that made sense six months ago for a project that has since ended is exactly the kind of forgotten permission that causes an incident later.

Quick Reference & Troubleshooting Commands