Manage Azure identities and governance
Scope and inheritance are the backbone
Every Azure RBAC assignment is a triple: a security principal (user, group, service principal, or managed identity), a role definition, and a scope. Scopes nest as management group > subscription > resource group > resource, and permissions flow downward. Assignments are additive, so a Reader at the management group plus Contributor at one resource group yields Contributor there. Owner manages everything including access; Contributor manages everything except access; User Access Administrator manages only access. Deny assignments, produced by managed applications and blueprints, override any allow.
Policy, RBAC, and locks answer different questions
RBAC answers who can act. Azure Policy answers what a resource may look like; it evaluates on create and update, and existing resources change only through a remediation task. Effects worth memorizing: Deny, Audit, Append, Modify, DeployIfNotExists, AuditIfNotExists, Disabled. An initiative is a group of policy definitions. Resource locks answer whether an action can complete: CanNotDelete and ReadOnly. Locks ignore RBAC, so even a subscription Owner must remove the lock before deleting the resource.
Identity plumbing
Entra ID holds users (member or guest), groups (assigned, dynamic user, dynamic device; dynamic membership needs P1 licensing), service principals, and managed identities. A system-assigned identity shares the resource lifetime; a user-assigned identity stands alone and can be attached to several resources. Treat SSPR, MFA, Conditional Access, and PIM as separate controls.
Worked rule of thumb
When a task is blocked, ask three questions in order: is there a lock, does Policy deny or modify, and does the role allow it? That order usually matches the answer choices. Tags do not inherit from a resource group automatically, so enforce them with a Modify policy.