Azure RBAC and Governance for AZ-104: Management Groups, Policy, and Locks

Few topics on the Microsoft AZ-104 (Azure Administrator) exam generate as much confusion as governance, and the reason is simple: it bundles together four features that look similar on the surface but answer completely different questions. Role-based access control decides who can do what. Azure Policy decides what is allowed to exist. Resource locks decide what cannot be changed or deleted. Tags decide how you label and account for things. Candidates lose points not because these ideas are hard, but because the exam deliberately writes questions where two of them seem to fit and only one actually does. This article untangles them so that on test day you reach for the right tool without hesitating.

RBAC: who can do what, and where

Azure role-based access control has exactly three moving parts, and every RBAC question is really testing whether you understand how they combine. A role definition is a named collection of permissions — a list of allowed actions like read a virtual machine or restart it. A security principal is who you are granting access to: a user, a group, a service principal, or a managed identity. A scope is where that access applies. Bolt those three together — this principal, gets this role, at this scope — and you have a role assignment. That is the object you actually create.

The single most important thing to internalize is that scope is hierarchical and permissions inherit downward. Azure has four scope levels, from broadest to narrowest: management group, subscription, resource group, and individual resource. Assign someone the Contributor role at a subscription, and they are Contributor on every resource group and every resource inside it, automatically. This is why the Microsoft Azure Administrator exam loves questions where a user "unexpectedly" has access to a resource — the answer is almost always an assignment made higher up the tree that flows down. You cannot see that inheritance if you only look at the resource itself, which is exactly the trap.

A few rules make the exam's edge cases predictable. RBAC is additive: if you have Reader from one assignment and Contributor from another at the same scope, you get the union of both. The only thing that overrides an allow is an explicit deny assignment, which is rare and usually created by Azure itself, not by you. And crucially, assigning a role is itself a privileged action — you need Owner or User Access Administrator to hand out roles. A Contributor can do almost everything to resources but cannot grant access to others, and that distinction is a frequent exam question.

Built-in roles you must know cold

Azure ships hundreds of built-in roles, but four cover the majority of AZ-104 scenarios. Owner has full access including the right to delegate access to others. Contributor can create and manage every type of resource but cannot grant access to anyone else — that one exclusion is the whole point of the role. Reader can view everything and change nothing. User Access Administrator can manage access but not the resources themselves. When a question describes someone who needs to deploy and configure resources but explicitly should not be able to assign roles to teammates, the answer is Contributor, not Owner. Learning to spot that "but not manage access" qualifier is worth several marks.

Management groups: governance above the subscription

If subscriptions are the top of your billing world, management groups sit above them. A management group is a container for organizing multiple subscriptions so you can apply access and policy to all of them at once. Picture a company with separate subscriptions for production, development, and finance: rather than configuring each one individually, you place them under management groups and assign roles or policies at that level, and everything beneath inherits. There is always a root management group at the very top, and the hierarchy can nest several levels deep.

The exam wants you to recognize management groups as the answer whenever a scenario says "across all subscriptions" or "for the entire organization." Assign a Reader role at a management group and every subscription under it, present and future, gets that Reader access. Apply a policy there and it cascades the same way. This is the highest leverage point in the whole governance model, which is why it appears so often in the practice questions for AZ-104 that deal with enterprise-scale scenarios.

Azure Policy versus RBAC: the distinction the exam hunts for

This is the confusion that separates a confident answer from a coin flip. RBAC and Azure Policy both restrict things, so it is tempting to treat them as interchangeable. They are not, and understanding why is the highest-yield concept in this topic.

Work through a concrete example. Suppose the requirement is: "storage accounts may only be deployed in the West Europe region." No RBAC role can express that. RBAC can let someone create storage accounts or forbid it entirely, but it has no concept of where or how the resource is configured. Azure Policy does exactly that — a policy with a deny effect blocks any storage account whose location is not West Europe, and it applies to an Owner just as firmly as to a Contributor, because policy evaluates the resource, not the person. Conversely, "Jane should be able to restart VMs but not delete them" is pure RBAC and has nothing to do with policy. When a question mentions allowed regions, required tags, permitted SKUs, or enforced configurations, think Policy. When it mentions who can perform an action, think RBAC. Policy effects worth knowing include deny (block non-compliant creation), audit (allow but flag it), and deployIfNotExists (remediate automatically).

Resource locks and tags: the small features that decide questions

Two lighter topics round out the governance domain, and both are easy points if you have seen them once. A resource lock protects against accidental change, and it comes in two flavors. A CanNotDelete lock lets you read and modify a resource but blocks deletion; a ReadOnly lock is stricter, allowing only read operations so nothing can be modified or deleted. The exam's favorite trick here is that locks apply to everyone regardless of their RBAC role — an Owner with full permissions still cannot delete a resource that carries a CanNotDelete lock until they remove the lock first. Locks also inherit downward, so a lock on a resource group protects everything inside it.

Tags are name-value pairs you attach to resources for organization, cost tracking, and automation — think environment: production or costcenter: 4501. The detail candidates miss is that tags do not inherit by default: a tag on a resource group does not automatically appear on the resources within it. If you need that behavior, you enforce it with an Azure Policy that applies or inherits the tag — which is a neat illustration of how these features interlock rather than duplicate each other.

Turning understanding into exam-ready recall

Governance rewards a specific skill: reading a scenario, spotting the qualifier, and mapping it to the one correct feature. That is a pattern you build through repetition on realistic items, then reviewing every miss until the distinctions are automatic. On ExamStudyApp, adaptive practice keeps serving you more RBAC-and-governance questions precisely when that is your weak area, and full-length timed AZ-104 exam simulations mirror the real Microsoft Azure Administrator format and pass mark so your readiness score reflects the actual test rather than a hopeful guess. Study the four features until you can state in one sentence what each one governs, drill until the qualifiers jump out at you, and the governance domain of AZ-104 turns from a minefield into some of the most reliable points on the exam.