RBAC Scope
In Azure Role-Based Access Control, scope defines the boundary at which a role assignment applies — management group, subscription, resource group, or individual resource — with permissions inheriting downward from broader to narrower scopes. Assigning a role at the narrowest scope that satisfies the need follows the principle of least privilege and limits the blast radius of a compromised identity.
RBAC Scope
Scope determines how far a role assignment reaches. Assigning "Contributor" at the subscription level grants it everywhere beneath — assigning it on one resource group limits the blast radius.
Why It Matters in Production
PhonePe assigns its CI/CD service principal "Contributor" scoped only to phonepe-staging-rg, not the whole subscription, so a compromised pipeline credential can't touch production resources.
az role assignment create --assignee
--role Contributor
--scope /subscriptions//resourceGroups/phonepe-staging-rg
SecurityAlways scope role assignments to the narrowest level that gets the job done — broad subscription-level Contributor access is one of the most common Azure security misconfigurations.
Frequently Asked Questions
Why would you assign a role at the management group level instead of per-subscription?
Management-group-level assignments let you grant a role once and have it inherit down to every subscription, resource group, and resource underneath — useful for org-wide roles like a central security team needing Reader access everywhere, without manually replicating the assignment across dozens of subscriptions. The tradeoff is blast radius: a mistake at that level (or a compromised identity holding it) affects everything beneath it, which is exactly why least-privilege scoping pushes assignments as narrow as the use case allows.
What's a common mistake when troubleshooting 'access denied' errors in Azure RBAC?
Assuming a missing permission means you need a broader scope, when usually the fix is a more specific role at the correct narrow scope. Because permissions are purely additive and inherit downward, a user can accumulate unexpected access from assignments at a parent scope they forgot about — use the Azure Portal's 'Check access' or `az role assignment list --all` to see the full effective set at a resource before assuming you need to grant more.