Azure RBAC Lab Guide: Assign Roles Using Security Principals, Role Definitions, and Scope

This lab introduces Azure role-based access control (RBAC) and demonstrates how to assign permissions to an identity in a controlled and auditable way. RBAC is the authorization system in Azure that determines who can access a resource, what actions they can perform, and where those permissions apply. The lab focuses on the three components that make RBAC work: the security principal (the identity), the role definition (the permissions), and the scope (the boundary where the permissions apply). You will create a role assignment at the resource group scope using a built-in role and validate the access outcome.

RBAC is important because it prevents over-permissioning, supports least privilege, and reduces the risk of losing track of access across subscriptions and resource groups. In production environments, RBAC is central to security posture management because it controls administrative and operational access to Azure resources without relying on ad-hoc permissions.

Step-by-step lab instructions

Prerequisites and preparation

1. Confirm you have an active Azure subscription.
2. Confirm you have permissions to assign roles at the intended scope:
   • Owner, or
   • User Access Administrator, or
   • Role Based Access Control Administrator (with appropriate scope permissions)
3. Identify the target scope for the lab:
   • A resource group (recommended), or
   • A subscription (broader), or
   • A specific resource (narrowest)
4. Identify the identity you will assign access to (security principal):
   • User, group, managed identity, or app registration (service principal)

Task 1: Review the RBAC components you will configure

1. Security principal (who)
   • The identity that will receive permissions
   • Must exist in Microsoft Entra ID (user, group, service principal, or managed identity)
2. Role definition (what)
   • A set of allowed actions (for example: read, write, delete)
   • Use built-in roles whenever possible to reduce maintenance and complexity
3. Scope (where)
   • The boundary where permissions apply
   • Supported scopes:
     • Management group
     • Subscription
     • Resource group
     • Resource

Task 2: Assign a built-in role at resource group scope

1. Open the Azure portal.
2. Navigate to Resource groups.
3. Select the resource group you want to use (example: AlpacaRG).
4. Open Access control (IAM).
5. Select Add, then select Add role assignment.
6. On the Role tab:
   • Search for and select Contributor
   • Select Next
7. On the Members tab:
   • Set Assign access to: User, group, or service principal
   • Select Select members
   • Search for the target identity (example: Alpaca-Ma-Bags identity, a user, or a group)
   • Select the identity, then choose Select
   • Select Next
8. On the Review + assign tab:
   • Review the role, scope, and selected members
   • Select Review + assign to complete the assignment

Verification

1. Confirm the role assignment exists:
   • Resource group → Access control (IAM) → Role assignments
   • Verify the identity appears with the Contributor role at the resource group scope
2. Validate effective access (recommended):
   • Sign in as the assigned user (or test with the application identity)
   • Attempt to create or update a resource inside the resource group
   • Confirm the identity can manage resources but cannot grant access to others (Contributor cannot assign roles)

Task 3: Validate scope behavior (optional but recommended)

1. Confirm the identity does not have permissions outside the resource group:
   • Attempt to access or modify resources in a different resource group
   • Confirm access is denied or limited (expected if no broader assignments exist)
2. Confirm role inheritance within scope:
   • Review resources inside the resource group
   • Confirm the role applies to existing and newly created resources within that resource group

Operational guidance and common pitfalls

1. Use built-in roles where possible
   • Custom roles increase administrative overhead and can drift over time
2. Avoid assigning at subscription scope unless necessary
   • Subscription-scope assignments are easy to overuse and can lead to broad access
3. RBAC changes may take time to propagate
   • If access does not work immediately, wait a few minutes and retry
4. RBAC can be blocked by other controls
   • Network Security Groups, firewalls, resource locks, and policy can still prevent changes even if RBAC allows them
5. Groups simplify access management
   • Prefer assigning roles to groups rather than individual users for maintainability

Completion criteria

1. You can identify the three RBAC components: security principal, role definition, scope.
2. You successfully created a role assignment using a built-in role (Contributor).
3. You verified the role assignment appears at the intended scope.
4. You validated the identity can manage resources within the scope and does not have unintended access outside it.