Why RBAC Matters

Azure resources must be secured by ensuring only the right people have the right access at the right time. Over-provisioned permissions lead to security risks, compliance issues, and possible data breaches.

Azure RBAC (Role-Based Access Control) is the main mechanism for assigning fine-grained permissions to resources in Azure. As a Solution Architect, you must design least privilege models that balance security with operational efficiency.

Core RBAC Concepts

1. Roles

• Built-in roles (e.g., Owner, Contributor, Reader, User Access Administrator).

• Resource-specific roles (e.g., Storage Blob Data Reader).

• Custom roles (JSON-defined, for unique org needs).

2. Scope

• RBAC is hierarchical: Management Group → Subscription → Resource Group → Resource.

• Permissions inherit down the hierarchy.

3. Assignments

• RBAC role = applied to a user, group, service principal, or managed identity.

• Best practice: assign to groups, not individuals.

Design Best Practices

1. Least Privilege Access

• Grant only required permissions, no more.

• Use Reader role for visibility without changes.

• Use Owner sparingly (reserved for platform admins).

2. Role Segregation

• Developers = Contributor to app resources.

• Security Team = Security Reader or Security Admin.

• Operations = Monitoring Reader + Virtual Machine Contributor.

3. Just-in-Time Access

• Combine RBAC with PIM (Privileged Identity Management).

• Provides time-limited elevation for sensitive roles.

4. Service Identities

• Assign Managed Identities to applications.

• Avoid storing credentials in code/config files.

Example Enterprise Scenario

A financial services company requires:

• Developers to deploy apps but not delete subscriptions.

• Operations to restart VMs but not access customer data.

• Security team to monitor logs but not change configs.

• Admin roles must not be permanently assigned.

Correct design:

• Assign Contributor role to Dev group at Resource Group level.

• Assign VM Contributor to Ops team, Reader on storage accounts.

• Assign Security Reader to Security team.

• Use PIM for admin access.

Confusion Buster

• Owner vs Contributor

  • Owner = full control + assign roles.

  • Contributor = full control, but cannot assign roles.

• Reader vs Security Reader

  • Reader = view all resources.

  • Security Reader = view security-related info only.

• Custom Roles vs Built-in Roles

  • Built-in = predefined.

  • Custom = defined in JSON with specific actions.

Exam Tips

• “Which role can assign other roles?” → Owner or User Access Administrator.

• “Which role for read-only access to Storage?” → Storage Blob Data Reader.

• “Which principle enforces minimal access rights?” → Least Privilege.

• “Which tool provides time-limited elevation of RBAC roles?” → PIM.

What to Expect in the Exam

• Direct Q: “Which Azure RBAC role grants full access but not role assignments?” → Contributor.

• Scenario Q: “Company requires Ops team to manage VMs but not storage.” → VM Contributor.

• Scenario Q: “Company wants to avoid permanent admin assignments.” → PIM with just-in-time RBAC.

• Trick Q: “RBAC applies only at subscription level.” → False (works at all scopes).