Azure RBAC looks simple when reduced to a sentence: assign a role to a security principal at a scope. The operational difficulty is choosing the narrowest role and scope that let the workload or administrator do the job without creating an unnecessary path to broader control. AZ-104 candidates need to reason about that decision across subscriptions, resource groups, resources, managed identities, groups, and privileged administrative roles.<\/p>\n
The live Microsoft AZ-104 exam<\/a> expects administrators to manage identities and governance as part of operating Azure. A useful broader frame is cloud identity and access<\/a>: an authorization design should answer who or what is acting, what actions are allowed, where those permissions apply, and how privilege is reviewed over time. RBAC is the Azure control plane mechanism that turns those questions into enforceable assignments.<\/p>\n Every Azure RBAC assignment connects a security principal to a role definition at a particular scope. The principal can be a user, group, service principal, or managed identity. The role definition is the permission set. The scope can be a management group, subscription, resource group, or individual resource.<\/p>\n Those three parts should be evaluated together. Reader at subscription scope may expose more information than Contributor at a single resource, while a narrow custom role at management-group scope could still be broader than expected because child scopes inherit permissions. Least privilege is not only about picking a role with a reassuring name.<\/p>\n For AZ-104 scenarios, translate the requirement into the three-part model before choosing an answer. Which identity needs access? Which operations are actually required? What is the narrowest scope containing the resources it must manage?<\/p>\n Azure scopes form a hierarchy. A role assigned at a management group can flow to subscriptions beneath it; a subscription assignment reaches resource groups and resources; a resource-group assignment reaches the resources it contains. That inheritance is useful when a team genuinely owns a whole environment.<\/p>\n The same feature can create excessive access. Assigning Contributor at subscription scope because a user needs to restart one virtual machine solves the immediate ticket while dramatically increasing blast radius. A resource-level or purpose-built role may be more appropriate.<\/p>\n Candidates should also recognize that moving resources between groups or subscriptions can alter effective access because inherited assignments change with scope. Troubleshooting therefore includes checking inherited roles, not just the assignments visible directly on the resource.<\/p>\n Azure provides built-in roles such as Owner, Contributor, Reader, and a large set of service-specific roles. Owner has full resource-management access and can assign roles. Contributor can manage resources but cannot normally assign Azure RBAC roles. Reader provides read access. Privileged access roles require particular caution because they can expand other identities’ permissions.<\/p>\n Choose the built-in role whose actions match the task, then verify scope. Avoid defaulting to Owner or Contributor simply because they are familiar. Microsoft recommends limiting privileged administrator role assignments and granting only the access needed to perform the job.<\/p>\n When a built-in role is close but still too broad, a custom role can narrow actions. Custom roles should be designed carefully, avoiding broad wildcards when a smaller permission set is practical.<\/p>\n Assigning roles directly to many individual users creates a lifecycle problem. Team membership changes, people leave, temporary access becomes permanent, and the same entitlement is recreated repeatedly. Assigning roles to groups makes membership the primary control while the Azure assignment remains stable.<\/p>\n For applications and Azure services, managed identities are often preferable to long-lived secrets because Azure manages the credential lifecycle. The managed identity still needs an appropriate RBAC assignment; managed identity is not a permission by itself.<\/p>\n This distinction matters on the exam. Authentication establishes who the caller is. RBAC authorization determines what the authenticated identity can do at the Azure resource scope.<\/p>\n A role that is necessary for one hour may be excessive as a permanent assignment. Microsoft Entra Privileged Identity Management can support eligible, time-bound activation for privileged access scenarios. That makes the duration and approval of privilege part of the control design.<\/p>\n Delegated role-assignment management can also be constrained. Instead of giving a delegate unrestricted Owner-style authority, Azure supports the Role Based Access Control Administrator role and conditions that can limit which roles or principals a delegate may manage. This is a useful example of least privilege applied to the administration of privilege itself.<\/p>\n For AZ-104, think beyond \u201ccan this user do the task?\u201d A stronger design asks whether the access is appropriately scoped, appropriately privileged, and appropriately persistent.<\/p>\n Azure role assignments can include conditions for supported scenarios, and Azure also uses attribute-based conditions to constrain delegated role assignment management. The important architectural idea is that a broad role can sometimes be made safer by adding rules about what resources, actions, or assignment operations are permitted.<\/p>\n Conditions are not a substitute for choosing the right role and scope. Start with the smallest sensible role and scope, then use conditions when the requirement needs additional precision. Adding complexity to compensate for a needlessly broad base assignment creates harder troubleshooting and governance.<\/p>\n On the exam, read the requirement carefully. If the objective is to let a user manage resources, that is different from letting the user grant access to those resources. Authorization administration is itself privileged work.<\/p>\n When an Azure action fails with authorization errors, identify the caller first. Then inspect direct and inherited role assignments, confirm the requested action exists in the role definition, and verify that the assignment scope covers the target resource. If the role was just granted, remember that propagation can introduce short delays.<\/p>\n Service principals can also fail during assignment workflows because the caller lacks directory permissions to look up the assignee. Azure CLI can use the assignee object ID to avoid that directory lookup in supported cases. This illustrates why a failed role assignment is not always the same as a failed resource action.<\/p>\n For permission excess, reverse the process: enumerate assignments and inheritance, identify which one grants the unwanted action, and change the smallest relevant assignment rather than stripping unrelated access.<\/p>\n Azure Policy evaluates resource configuration and compliance; RBAC controls who can perform management actions. Resource locks protect against selected deletion or modification actions. These controls can overlap in effect but should not be confused.<\/p>\n An administrator may have an RBAC role that normally allows an action yet still encounter a policy denial or a resource lock. Conversely, a policy that requires a secure configuration does not grant an identity permission to deploy it. Understanding the boundary among authorization, policy, and locks prevents misdiagnosis.<\/p>\nA role assignment has three parts: principal, role, and scope<\/h2>\n
Scope inheritance is powerful because it reduces assignments and dangerous because it multiplies impact<\/h2>\n
Built-in roles should be the first choice, but role names are not enough<\/h2>\n
Groups and managed identities reduce identity-management friction<\/h2>\n
Least privilege includes time and delegation, not only permission lists<\/h2>\n
RBAC conditions can narrow selected role-assignment scenarios<\/h2>\n
Troubleshoot effective access by following the assignment chain<\/h2>\n
RBAC works with governance controls but solves a different problem<\/h2>\n