Azure RBAC often looks straightforward in a diagram: choose a role, choose a user or group, choose a scope. The complexity appears later, when a person has a role at a management group, another role at a resource group, membership in two nested teams, and temporary privileged access somewhere else. The effective permission is the result of all those assignments and the hierarchy beneath them.
For AZ-104, scope and inheritance are best understood as a control-boundary problem. The goal is not merely to know the four common scope levels. It is to know where a role should be assigned so that the intended people can perform the intended actions without accidentally extending privilege into unrelated resources.
Scope answers where the role assignment applies
Azure Resource Manager scopes are hierarchical. At the broad end is a management group, followed by subscription, resource group, and individual resource. A role assignment made at a parent scope is inherited by child scopes. This makes broad assignments operationally convenient and potentially dangerous.
If a platform team needs to manage every network resource across several subscriptions, a higher-level assignment may be appropriate. If an application team needs to restart one production web app, subscription-level Contributor is difficult to justify. The smallest scope that meets the requirement makes future review easier because the assignment describes the real job rather than granting a large permission set and relying on good behavior.
Azure RBAC provides the foundation: a role assignment connects a principal, a role definition, and a scope.
Inheritance reduces repetition but can hide the true source of access
Inherited permission is useful because teams do not need to repeat the same role assignment on every child resource. The downside is that a reviewer looking only at one resource can miss why a user has access. The assignment may exist several levels above the resource being investigated.
This matters during incident response and access review. Removing a direct assignment from a resource does not revoke an inherited assignment from the subscription. Likewise, moving a resource into a resource group with different inherited assignments can change who has access even though the resource’s own configuration was untouched.
Good operational practice therefore records why broad assignments exist and uses group-based assignment where possible. The team should be able to trace effective access back to its parent scope instead of treating inherited permission as mysterious platform behavior.
Role definitions and scopes solve different parts of least privilege
A narrow scope cannot compensate for an excessively powerful role, and a narrow role cannot compensate for an unnecessarily broad scope. Least privilege requires both dimensions.
A built-in Reader role at subscription scope exposes a large amount of resource information but does not allow normal modification. Contributor at one resource group allows substantial change inside that group while excluding role-assignment management. Owner adds authority to manage access. Custom roles can reduce the action set further when built-in roles are too broad, but they also create lifecycle and maintenance work.
A useful review asks two separate questions: does the principal need these actions, and does the principal need them across this many resources? If either answer is no, the assignment should be redesigned.
Groups usually make access easier to govern than individual assignments
Direct user assignments feel fast during a project but accumulate into a difficult access graph. Assigning roles to well-governed Microsoft Entra groups can separate business membership from Azure configuration. The cloud administrator manages the role assignment once, while the appropriate owner manages group membership through a controlled process.
The risk moves rather than disappears. If the group has weak ownership or uncontrolled membership, the Azure role becomes indirectly weak. A sensitive group should therefore have clear owners, membership review, and change evidence. Dynamic membership can improve automation, but the source attributes and rules become part of the trust chain.
This relationship between identity and resource access is why the Microsoft Entra identity model matters even to administrators focused on Azure infrastructure.
Privilege at a parent scope should be treated as a blast-radius decision
A subscription-level or management-group role is not merely a convenient way to avoid repetitive assignments. It determines the number of resources affected by credential compromise, administrative error, or malicious action. A broad Contributor or Owner assignment can turn one account compromise into an environment-wide event.
High-level access therefore deserves stronger controls: phishing-resistant authentication where appropriate, privileged identity management, time-bound activation, approval for sensitive roles, strong monitoring, and separate administrative identities. The exact mechanism can vary, but the architectural idea is stable: the wider the scope and stronger the role, the more evidence the organization should require before and during use.
Privileged access should also be exercised from controlled devices and reviewed for unusual role assignment changes, not only unusual resource changes.
RBAC is not Azure Policy and it is not a resource lock
RBAC answers whether a principal is authorized to perform an action at a scope. Azure Policy evaluates resource state and can audit, modify, deploy supporting configuration, or deny noncompliant resource changes depending on the policy effect. A resource lock can block deletion or modification even when the user otherwise has RBAC permission.
These controls can overlap in outcome while operating for different reasons. An Owner might be allowed by RBAC to delete a resource but be blocked by a Delete lock. A Contributor might be authorized to create a resource but encounter an Azure Policy deny because the requested configuration violates an organizational rule.
Understanding the separation prevents overloading RBAC with problems it was not designed to solve.
Evidence should reconstruct effective access, not just assignments
A useful access review goes beyond listing direct role assignments. Reviewers need inherited assignments, group membership, privileged activation, custom roles, deny assignments where applicable, and changes over time. Activity logs can show who changed role assignments or resources, while identity logs can add authentication context.
Testing is equally important. Create a representative low-privilege account and verify what it can actually do at the intended scope and at neighboring scopes. Confirm that removing group membership or a role assignment revokes access on the expected timeline. Verify that emergency access paths are exceptional rather than quietly becoming the normal administrative route.
The control is working when the team can explain not only who has access, but why, from where, for how long, and through which assignment path.
Resource movement and organizational change can alter effective access
Scope-based authorization means architecture changes can change access even when no role assignment is edited. If a resource is moved between resource groups or subscriptions, the inherited assignments around that resource can change. A team that focuses only on the resource’s direct assignments may miss the new parent-scope permissions.
This is important during reorganizations and landing-zone changes. A resource group moved under a different subscription can inherit a different set of administrators, monitoring roles, or deployment identities. The move may be technically successful while silently expanding or reducing who can manage the resources afterward. Change review should therefore include an authorization comparison before and after the move.
Temporary elevation is another place where effective access differs from the static assignment list. Privileged identity management can make eligible roles activatable for a limited period rather than permanently active. That reduces standing privilege, but the organization still needs evidence of who activated a role, why, for how long, and what changes followed. A review that sees only “eligible” versus “assigned” without activation history can miss the most important part of the control.
Finally, Azure can contain deny assignments created by platform features or managed solutions. These can restrict actions even when an allow assignment appears sufficient. They are not the everyday mechanism for administrator access design, but they reinforce the broader lesson: effective authorization is the result of the whole evaluation path, not one visible role assignment.
Choose scope as deliberately as you choose the role
The common anti-pattern is granting a familiar broad role at a convenient high scope because it makes the immediate task easy. That default transfers complexity into future reviews, incident response, and separation of duties. A better design begins with the exact operations and resources required, then selects the role and the narrowest practical scope.
For the Azure Administrator Associate path, RBAC scope and inheritance are central because almost every Azure service is administered through identities and Resource Manager boundaries. The practical question worth asking is not “which role gives access?” It is “what is the smallest understandable assignment that gives the right access without creating an inherited surprise elsewhere?”
Custom roles deserve special caution. They can remove permissions that built-in roles grant unnecessarily, but they become code that the organization must understand and maintain. New Azure resource-provider actions appear over time, and a role definition built years ago may not reflect today’s services. Reviews should confirm that custom actions and exclusions still match the job. Creating dozens of nearly identical custom roles can make least privilege look precise while making effective access harder to audit.
Service principals and managed identities make the same scope choices consequential for automation. A deployment identity with Contributor at subscription scope can change far more than a workload that only needs to manage one resource group. Because nonhuman identities do not “notice” that their privileges are excessive, reviews should include workload identities, ownership, credential or federation method, and the exact scopes where automation runs. Least privilege is incomplete if it applies only to human administrators.
Finally, permissions should be reviewed from the resource owner’s perspective as well as the identity team’s perspective. The owner knows which actions are operationally necessary and which resources are sensitive. Combining that context with identity governance produces better scope decisions than either team can make from a role list alone.
