AZ-104 expects administrators to manage built-in Azure roles, assign roles at different scopes, interpret access assignments, implement Azure Policy, configure resource locks, apply tags, manage resource groups and subscriptions, control costs, and work with management groups. The AZ-104 identity-and-governance domain therefore tests several controls that can look similar in a scenario but operate for different reasons.
The most important boundary is between authorization and governance. Role-based access control determines what an identity can do at a scope. Azure Policy evaluates or enforces resource configuration. Locks protect resources from specific kinds of administrative change. Tags add metadata. Knowing which control owns the requirement is more important than memorizing where the portal button lives.
Solve RBAC with principal, role, and scope
Every Azure RBAC decision can be reduced to three elements: who receives access, which role defines allowed operations, and where the assignment applies. The principal can be a user, group, service principal, or managed identity. The role is usually a built-in role unless a custom definition is genuinely required. The scope can be a management group, subscription, resource group, or resource.
Exam scenarios often contain one correct role at several possible scopes. The least-privilege answer grants only the access required and limits the scope accordingly. A team that manages one resource group does not automatically need the same role at the subscription. Conversely, a central operations team responsible for every resource group may be better served by one higher-scope assignment than dozens of repeated child assignments.
Inheritance means an assignment at a parent scope can explain access that is not visible as a direct resource assignment. Interpret effective access rather than checking only the nearest scope.
Choose built-in roles before inventing custom access
Built-in roles cover many common administrative responsibilities and are easier to understand and maintain than one-off custom definitions. If the scenario asks for read-only access, resource contribution without access management, or a service-specific operational role, look for a built-in role that matches the requirement before considering broader permissions.
Do not use Owner as a troubleshooting shortcut. Owner includes the ability to manage access, which is unnecessary for many operational tasks. Contributor is also broader than service-specific roles in many cases. Least privilege is both a security principle and a frequent exam clue.
Custom roles become relevant when the required action set cannot be represented by built-in roles, but the current AZ-104 objective emphasizes managing built-in roles and assignments. Keep your study focus aligned with that wording.
Use Policy for configuration standards, not user permissions
Azure Policy is designed to evaluate resource properties and enforce organizational rules. It can audit noncompliant resources, require or append certain configuration, or deny deployments that violate a standard depending on the policy effect and definition. It is not the tool for deciding whether Alice may restart a virtual machine.
Examples make the boundary clear. Restricting allowed regions, requiring tags, or auditing encryption settings are governance problems. Giving a network team permission to manage virtual networks is an RBAC problem. If a scenario combines both, use both controls rather than forcing one to do the other’s job.
Policy scope and inheritance matter just like RBAC scope. A high-level assignment can create consistent standards across many subscriptions, while an overly broad assignment can block legitimate workloads. Always read the organizational boundary in the question.
Use locks for accidental change protection
Resource locks add a protection layer against administrative modification or deletion, depending on the lock type. They are useful when a critical resource should not be casually changed even by someone who otherwise has permission. A lock does not replace RBAC, policy, backup, or disaster recovery.
This distinction appears in scenario wording. “Prevent accidental deletion” points to a lock. “Only the backup team may delete” is an authorization requirement. “Resources of this type must not be deployed” is a policy requirement. Choosing the correct control starts with the verb in the business request.
Because locks can affect operations, administrators should know where they are applied and how inheritance influences child resources. A troubleshooting workflow that ignores locks may incorrectly conclude that RBAC is broken.
Use tags and resource groups for organization and operations
Tags provide key-value metadata that can support cost allocation, automation, ownership, and reporting. Resource groups provide a management boundary for related resources, but they are not simply folders. Decisions about lifecycle, access, deployment, and organization often intersect at the resource-group level.
A useful governance design gives tags clear semantics. If `CostCenter` or `Environment` is used for reporting, define allowed values and consider Policy to improve consistency. Tags with inconsistent spelling or meaning create the appearance of governance without reliable data.
Resource groups should reflect operational management where possible. If resources must be deployed, updated, or removed together, their grouping deserves thought. The exam may test moves between resource groups or subscriptions elsewhere, so understand that organizational structure affects administrative tasks.
Manage subscriptions, costs, and management groups coherently
Subscriptions are both administrative and billing boundaries. Budgets and alerts help detect spending patterns, while Azure Advisor recommendations can identify opportunities related to cost and other operational concerns. Cost governance works better when resource ownership and tagging are already consistent.
Management groups sit above subscriptions and allow policy or access structure to scale across a larger environment. This is useful for enterprises with multiple subscriptions, but it also increases the blast radius of a mistake. Apply high-level controls only when the requirement is truly shared.
Candidates who also study AZ-305 may think in terms of organization-wide architecture. For AZ-104, keep the emphasis on implementing and operating the governance hierarchy rather than merely recommending one.
Interpret failures by control type
If a deployment is denied, inspect policy before broadening the user’s role. If a user can read but cannot modify, inspect RBAC. If an authorized administrator cannot delete a critical resource, inspect locks. If the environment has inconsistent cost reporting, inspect tags and budget configuration. This symptom-to-control mapping is an efficient troubleshooting method.
Inherited state can complicate the picture, so follow the hierarchy upward. A policy assigned at a management group or role assigned at a subscription can explain behavior in a child resource group. Record the scope of each relevant control before changing anything.
The goal is to fix the governing rule, not merely make one operation succeed. A local exception may be appropriate, but only after you understand the broader assignment that created the behavior.
Practice governance with small matrices
Build a table of requirements with columns for principal, action, resource scope, and control type. Fill it with scenarios such as “developers can restart test VMs,” “production resources cannot be deleted,” “all resources need a cost-center tag,” and “only approved regions are allowed.” Mapping each sentence to RBAC, lock, tag, or Policy strengthens the boundaries between features.
Then change the scope. Apply the same rule to one resource, one resource group, one subscription, or many subscriptions. The correct Azure feature may stay the same while the assignment scope changes. That combination of control and scope is at the heart of AZ-104 governance questions.
Understand effective access without overgranting
Effective access can come from several assignments. A user may receive one role directly and another through a group, with both inherited from different scopes. When the user reports a missing permission, list the principals and scopes before adding anything. The objective is to understand the effective permission set, not to make the error disappear by adding Contributor or Owner at a high level.
The reverse problem matters too: unexpected access often comes from a parent-scope or group assignment that an administrator forgot about. Removing a direct assignment will not change access if the principal still inherits a suitable role elsewhere. This is why scope is inseparable from role interpretation on AZ-104.
A strong operational habit is to document why a high-scope assignment exists and prefer group-based administration when a stable team responsibility is being granted. That reduces individual exceptions and makes later reviews easier.
Use policy compliance as an operating signal
Azure Policy is not only a deployment gate. Audit effects and compliance results can show where the estate has drifted from organizational standards. Administrators can use that information to identify noncompliant resources and decide whether to remediate, exempt, or redesign them. The policy assignment should express the standard clearly enough that teams understand what they are expected to fix.
Remediation should be planned around the effect and the resource type. A policy that reports a missing tag is different from one that denies a prohibited configuration. Before changing the policy, determine whether the problem is an incorrect resource, an incorrect assignment scope, or a legitimate exception. Broad exceptions can weaken governance as quickly as broad role assignments weaken access control.
For the exam, look for language such as audit, enforce, require, deny, or compliance. Those verbs usually signal policy rather than RBAC.
Audit governance changes before widening scope
When a requirement grows from one team or resource group to an entire subscription, reassess the assignment instead of simply moving it upward. A higher scope reduces repetitive administration but increases the number of resources affected by a mistake. Review exceptions, inherited roles, policy effects, and resource ownership before changing the scope.
This trade-off is a recurring AZ-104 theme: least administrative effort does not mean broadest possible control. The best design balances operational simplicity with least privilege and the intended governance boundary.
Continue exploring the technologies and certification concepts that matter most to you.