Identity and Governance

This domain is best read as a single pipeline. First you establish identity in Microsoft Entra ID (formerly Azure Active Directory / Azure AD), the directory that holds the users and groups who sign in. Then you decide what those identities may do to Azure resources with Azure role-based access control (RBAC). Then you constrain what anyone, however privileged, is allowed to build and keep, with governance guardrails (Azure Policy, resource locks, tags, and cost controls). These are three separate control planes that never substitute for one another: Entra answers 'who is this?', RBAC answers 'is this principal allowed to act?', and Policy answers 'is this resource allowed to look like this?'. Reach for the plane that matches the question, not the one you used last.

The single most-tested confusion in this domain is treating directory power and resource power as the same thing. Microsoft Entra roles (such as Global Administrator and User Administrator) govern the directory itself (users, groups, passwords, licenses, domains) scoped at the tenant, an administrative unit, or one object. Azure RBAC roles (Owner, Contributor, Reader) govern access to Azure resources through Azure Resource Manager, scoped at the resource hierarchy. By default a Global Administrator has zero access to Azure resources, and a subscription Owner cannot create a directory user. The only sanctioned bridge is a Global Administrator toggling 'Access management for Azure resources', which grants User Access Administrator at the root scope across every subscription.

Azure nests everything into one four-level containment tree: management group → subscription → resource group → resource. This same hierarchy is the scope for an RBAC role assignment, for an Azure Policy assignment, and for an inherited resource lock, which is why all three of this domain's access-and-governance subtopics share it. An assignment placed at one level is inherited by every level beneath it and never widens access at a parent, so the durable rule is: assign once at the highest scope that should be affected and let inheritance reach the children, rather than repeating yourself on each subscription or resource group. (Tags are the deliberate exception. They attach to subscriptions, resource groups, and resources but do NOT inherit downward on their own; you enforce parent tags with an Azure Policy tag effect.)

These two layers behave oppositely, and the contrast is load-bearing. Azure RBAC is purely additive: a principal's effective permissions are the union of every role assignment at every applicable scope, so a narrower assignment can never subtract from an inherited broader one (Contributor on the subscription plus Reader on a resource group still yields Contributor on that group). Guardrails work the other way: they stop actions for everyone. A resource lock overrides all RBAC, so even an Owner is blocked until it is removed; an Azure Policy Deny effect rejects a non-compliant create or update before the resource exists. The only thing that subtracts inside RBAC itself is a deny assignment, and those are created by Azure (for example behind a managed application), never authored by an administrator.