Azure
Intermediate 15 min read Azure

Azure Management and RBAC

The identity, scope and policy layer

Management groups, subscriptions, resource groups and Azure RBAC define how Azure organizes access and billing. Entra ID houses identities; roles grant scoped permissions; Azure Policy enforces guardrails.

Azure RBACresource groupsubscriptionmanagement groupEntra IDAzure Policyrole
Prerequisites: Azure Service Catalog Cloud Account Structure
Before we start

What you will learn

  • Structure management groups → subscriptions → resource groups
  • Apply Azure RBAC roles with correct scope
  • Use Azure Policy for guardrails
In 60 seconds

Tenant holds the directory; management groups group subscriptions; subscriptions group resource groups; resource groups hold resources. Entra ID identities attach RBAC role assignments at any of these scopes, and Azure Policy enforces rules across them.

Introduction

What is this?

An Azure tenant (Backed by Entra ID) is the top scope. Management groups organize subscriptions into a hierarchy for policy and billing assignment. A subscription is a billing and boundary unit; resources live in resource groups (a logical container with lifecycle). Azure RBAC grants access via role assignments (who, what role, at which scope) — classic roles include Owner, Contributor, Reader. Azure Policy defines guardrails (e.g. deny public storage, tag requirements) applied at management group / subscription / RG scope.

Motivation

Why do you need it?

  • Scope is the lever: a role at subscription scope affects everything below unless overridden.
  • Resource groups make cleanup, tagging and TLS/security auditing coherent.
  • Policy + RBAC together gate 'who can do what' AND 'what may exist at all'.
  • Entra ID unifies sign-in for users, service principals and managed identities.
Think about it

Mental model

Imagine

A company with departments, teams and desks

Think of

Azure hierarchy

The company (tenant) has departments (management groups), which own teams (subscriptions), which issue desk allocations (resource groups). Security badges (RBAC) are sized per team, and company policy (Azure Policy) applies entry-level rules to every office.

Mechanics

How it works

  • Identities live in Entra ID: users, groups, service principals, managed identities.
  • Role assignments bind a role definition to a principal at a scope (management group → subscription → RG → resource).
  • Effective permissions = highest scope where assigned, minus Deny assignments, minus Policy denies.
  • Managed identities give Azure resources their own identity without credentials.
  • Azure Policy (built-in definitions + custom) evaluates resources continuously and can deny non-compliant creation.
  • Locks guard critical resources from deletion/modification regardless of RBAC.

Azure governance stack.

Tenant / Entra ID
Management group
Subscription
Resource group
Resources
Hands-on

Examples

Scope an RBAC assignment and check it

Scope an RBAC assignment and check it
# Create a resource group
az group create --name rg-apps --location eastus
 
# Give a group Reader access at the resource-group scope
az role assignment create --assignee "devs@contoso.com"   --role Reader --scope "/subscriptions/$SUBID/resourceGroups/rg-apps"
 
# List current assignments
az role assignment list --scope "/subscriptions/$SUBID/resourceGroups/rg-apps" --output table

Role assignments apply at the scope you choose; Reader at RG scope lets the Devs group view everything in that RG but nothing above it.

Real world

In production

  • An enterprise uses one management group per environment (prod/dev) with a Policy denying public blob access at the prod node.
  • A platform team gives each product team a resource group and grants Contributor only within it.
  • A security team uses managed identities for Functions to talk to Key Vault, removing all human keys.
Guidelines

Best practices

  • Grant the least privilege that works; prefer Reader → Contributor migration only when evidence demands.
  • Assign roles to groups, not individual users.
  • Apply Policy at management-group scope; review policy compliance regularly.
  • Protect critical subscriptions with locks and restricted high-risk actions.
Watch out

Common mistakes

  • Giving everyone Owner because 'debugging permissions is annoying'.
  • Creating one giant resource group mixing environments.
  • Assigning roles at subscription scope when RG-level would do.
  • Writing policy that denies and breaking pipelines — stage policies in a 'detect only' audit mode first.
Root cause analysis

Common issues

Error
Can't create a resource a new pipeline needs
Root cause

A deny Policy or missing role at the subscription/RG scope

Fix

Review policy compliance and add the needed role at the narrowest scope.

Error
Service deleted by mistake by a team member
Root cause

No delete lock and Contributor role allowed deletion

Fix

Apply CanNotDelete locks to critical resources and minimise deletion-capable roles.

When things break

Debugging tips

  • 'Unauthorized' with a valid role usually means a Policy deny or higher-scope restriction — check policy events.
  • Use the activity log (Azure Monitor) to see which operation failed and why.
  • Check that a managed identity's role is attached to the right scope (ARM role propagation can lag).
  • Policy 'non-compliant' doesn't mean blocked — read the effect (audit vs deny).
Interviews

Interview checkpoint

Practice

Hands-on lab

Scope an RBAC Role with the Azure CLI
25 min · beginner
In progress
Objectives
  • Create a resource group
  • Assign a role at resource-group scope
  • Verify the effective assignment

Scope an RBAC Role with the Azure CLI

25 min · beginner

0/5 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/2
1

Which is the smallest RBAC scope that contains resources?

2

Azure Policy can deny the creation of non-compliant resources.

Go deeper

Official documentation

Azure — What is Azure role-based access control?
docs
Azure — Management groups
docs
Azure — Policy overview
docs