Two questions at the door
Walk into a theatre and three separate things are checked. Your ticket proves you are someone who paid — that is authentication. Your seat number says where, of all the seats, you are allowed to sit — that is authorization. And the fire code says no one, however expensive their ticket, may block the exit — that is policy, and it overrules everybody. Azure guards its resources with the same three ideas, and confusing the first two, or forgetting the third, is where the trouble starts.
Get the first distinction exact, because interviewers ask for it by name and juniors blur it daily.
- Authn
- Authentication — proving who you are. Signing in to Entra ID with a password and a second factor. It answers one question: is this really you?
- Authz
- Authorization — deciding what you may do once you are known. This is the job of role-based access control. It answers: now that we know it is you, what are you allowed to touch?
Authentication happens first and once; authorization happens on every action thereafter. Entra ID from Class Seven handles the first — it is the directory that proves identity. RBAC handles the second, and Azure Policy is the fire code sitting above both: a set of rules about what may exist at all, which even a fully authorized administrator cannot violate. This class is the second and third of those; the first you already met.
The three-part sentence of a role assignment
RBAC grants access through a single structure, and every access decision you ever make is a variation of it. An assignment is always three things joined together — miss one and you cannot reason about it.
- Assignment
- A who (a security principal — a user, a group, or an application), a what (a role definition — a bundle of permitted actions), and a where (a scope — a level on the Class Seven descent). Who, gets what, where.
The where is where Figure 4 pays off. A role granted at a scope applies to that scope and everything beneath it, because permissions inherit down the descent exactly as you were shown. Grant someone Reader at a subscription and they can read every resource group and every resource inside it, now and forever, including the ones created next year. Grant the same Reader at a single resource group and their view stops at that group's edge.
This is the whole game of least privilege, and it is a game about the where as much as the what. The instinct to assign high — "give them Contributor on the subscription, it's simpler" — trades a moment of convenience for a permanent, oversized blast radius. The discipline is to grant the narrowest role at the lowest scope that lets the person do the actual job, and not one level higher. Most access incidents are not the wrong role; they are the right role at the wrong altitude.
Owner, Contributor, Reader — and the trap between them
Azure ships dozens of built-in roles, and you can author custom ones, but three cover most of daily life. Learn what separates them, because the separation is subtler than the names suggest.
| Role | Read resources | Create / manage resources | Grant others access |
|---|---|---|---|
| Reader | Yes | No | No |
| Contributor | Yes | Yes | No |
| Owner | Yes | Yes | Yes |
The load-bearing cell is Contributor's "grant others access: no." Contributor can build anything and give away nothing. It can create, modify and delete resources all day, but it cannot hand a role to another identity — that single power is what separates it from Owner. This is deliberate and precious: it means you can let a team build freely without also letting them widen their own or anyone else's access, which is how privilege quietly sprawls.
So the honest hierarchy of daily use is: Reader for people who only need to look, Contributor for people who build, and Owner reserved for the few who must manage access itself — kept as rare as you can bear. When someone needs to grant access but not to run the resources, there is even a role for exactly that, User Access Administrator, so you never have to reach for Owner just to delegate.1 Owner is not a starting point you dial back from; it is a destination you justify.
Policy: what may exist, regardless of who
RBAC answers "who may act." It has nothing to say about whether an action produces something your organisation should allow. A user with Contributor rights can create a virtual machine — but should they be able to create one in a region you are forbidden by contract to use, or one with no tags, or a storage account open to the whole internet? RBAC will happily permit all three. Closing that gap is Azure Policy's entire job.
RBAC governs who; Policy governs what.
The two are independent and both apply. Policy evaluates every create-or-change against rules attached to a scope — inheriting down the descent, like everything else — and enforces an effect. The three worth knowing cold:3
- Audit
- Allow the action, but record non-compliance. The gentle effect: you learn how bad things are without breaking anything. Always where you start.
- Deny
- Block the create or change outright. The resource never comes into being. This is the fire code — and it stops an Owner just as firmly as anyone else.
- DeployIfNotExists
- Remediate: when a resource appears without a required companion — a diagnostic setting, say — Policy deploys the missing piece for you. Governance that fixes rather than merely scolds.
Sit with the deny row, because it is the fact that reorganises how you think. An Owner cannot override a policy. The most powerful role in the subscription still cannot create a resource that policy forbids, because RBAC and Policy answer different questions and both must say yes. This is why governance lives in Policy, not in careful role assignments: roles decide who you trust, policy decides what is permitted to exist at all, and the second guarantee holds even when the first is compromised.2
Governance as code, clicks as debt
Everything in this class can be done by clicking in the portal, and for learning that is fine. In production it is a slow-motion mistake. A role assignment made by hand is invisible six months later: no record of why, no way to reproduce it, no way to prove to an auditor what access exists without touring every scope by eye. A policy clicked into one subscription protects that subscription and silently forgets the next one someone creates.
The mature posture is to express access and policy as code — declared in files, reviewed like any change, applied identically everywhere — which is precisely what Phase Three builds toward. For now, hold the principle even before you have the tools: every click is a debt. It is a decision with no receipt, and you or your successor pays the interest the day something breaks and nobody can say how the system got the way it is. Governance you cannot reproduce is not governance; it is a rumour.
Campux's first roles and first rules
The RBAC model for six people is deliberately small. Most of the team gets Contributor on the non-prod subscription — build freely where mistakes are cheap — and Reader on prod, so everyone can see production but only a change through the pipeline can alter it. One or two people hold Owner at the management group, used rarely and deliberately. Nobody carries standing Owner on production; when a task truly needs it, it is borrowed just-in-time, not held.
The first two policies are the ones from Class Seven, now enforced rather than hoped for. An allowed-regions policy with a deny effect, so no resource is ever born in a region Campux does not intend to use — closing the door on both accident and the egress surprises of Class Three. And a required-tags policy so owner, env and cost-center are present on every resource, because you already learned that tags do not apply themselves. Both are set once at the management group and inherit to every subscription beneath — the floor plan from Class Seven, now with rules that hold whether or not anyone is watching.
The official module, and a CAMPUX overview
Secure your Azure resources with Azure role-based access control (Azure RBAC)
learn.microsoft.com/training/modules/secure-azure-resources-with-rbac/
Governance depth: Describe features and tools in Azure for governance and compliance
learn.microsoft.com/training/modules/describe-features-tools-azure-for-governance-compliance/
A short walkthrough of RBAC scope and a deny policy will live here. Video to be added.
Grant a role, then watch a policy overrule it
Two guards, side by side. You will assign a role at a scope — RBAC deciding who may act — then assign an allowed-regions deny policy, and watch a create in the wrong region get refused even though your own account has the rights. Who versus what, felt rather than read.
Open Cloud Shell — the >_ icon in the top bar — and choose Bash. (Locally: install the Azure CLI and run az login.)On screen: you are signed in and scoped to your subscription already; az is ready.
Create a throwaway resource group to work in:
az group create --name rg-campux-lab --location westeurope
Assign the Reader role to yourself at that group's scope — a role assignment is a principal, a role, and a scope:
ME=$(az ad signed-in-user show --query id -o tsv) RG=$(az group show --name rg-campux-lab --query id -o tsv) az role assignment create --assignee "$ME" --role Reader --scope "$RG"
What just happened: you granted access at the resource-group scope only. That same command with --role Owner --scope a subscription is the over-broad grant the class warned about — scope is half the decision.Assign the built-in Allowed locations policy (a deny effect) to the group, permitting only West Europe:
DEF=$(az policy definition list \ --query "[?displayName=='Allowed locations'].name | [0]" -o tsv) az policy assignment create --name campux-allowed-locs \ --policy "$DEF" --scope "$RG" \ --params '{ "listOfAllowedLocations": { "value": ["westeurope"] } }'On screen: looking the definition up by display name avoids hard-coding a fragile GUID. The assignment attaches the rule to this scope; it inherits downward from here.Now try to create something in a disallowed region and watch it be refused:
az storage account create --name campuxlab$RANDOM \ --resource-group rg-campux-lab --location eastus --sku Standard_LRS
The lesson: the request is rejected with a policy error — and it would be rejected even if you held Owner, because RBAC said you may act while Policy said the result may not exist. Both must say yes. Re-run it with --location westeurope and it succeeds.Tear down:
az group delete --name rg-campux-lab --yes --no-wait
Assign a role and a policy by hand
The portal names these two systems on two different blades, which is itself the lesson: access lives under Access control (IAM), governance under Policy. Use a throwaway resource group.
Go to portal.azure.com, then create a resource group: search Resource groups in the top bar, + Create, name it rg-campux-lab, and create it.
Open the group and select Access control (IAM) → + Add → Add role assignment.On screen: a three-step flow — Role, then Members, then Review — which is the class's "principal + role + scope" made literal. The scope is fixed: it is this resource group, because that is where you opened IAM.
Choose the Reader role, click Next, assign it to yourself as the member, and review + assign.On screen: under the Role tab you can see Contributor and Owner too. Reader can look, Contributor can build, Owner can also hand out access — the one power the class told you separates the top two.
Now the other guard: in the top search bar type Policy, open it, choose Assignments → Assign policy.On screen: Policy is a different service entirely from IAM — the portal itself is telling you "who may act" and "what may exist" are separate questions.
Set Scope to your resource group, pick the policy definition Allowed locations, and on the Parameters tab choose only West Europe. Review + create.On screen: the Allowed locations definition carries a deny effect — you are not auditing, you are forbidding. From now on a create outside West Europe in this group is blocked for everyone, Owner included.
Tear down: open rg-campux-lab and choose Delete resource group (the assignment goes with it).
Portal wording drifts; if a label here does not match your screen, the anchors are Access control (IAM) for roles and the Policy service for assignments.
Read who-can-act and what-is-compliant
Open the two blades that answer the two questions and read them as the pair they are.
On any resource group, open Access control (IAM) and select the Role assignments tab.On screen: every principal, its role, and the scope it was granted at — the whole "who may act" picture in one list. Inherited assignments are marked as coming from a parent scope.
Still in IAM, open Check access and look up your own account.On screen: Azure resolves exactly what you can do here and why — the answer to "how did this identity get that permission", which is the first question of any access incident.
Open the Policy service and select Compliance.On screen: each assignment with a compliant / non-compliant count. This is where an audit-effect policy tells you how bad things are before you switch it to deny — the safe rollout from the class.
Showing enforcement, not intentions
An auditor is coming, and the question will be "who can do what, and what stops the wrong thing?" You do not scramble. RBAC already scopes access to the least each role needs, and an Azure Policy denies resources in the wrong region or without tags. You show enforcement, not intentions — the difference between "we ask people not to" and "the platform will not let them."
Examination
Four drills, then two situations. The situations have no marking scheme — write your answer before you reveal the reasoning, or the exercise is worthless. Nothing is stored; this is between you and the page.
B. Permissions inherit down the descent from Figure 4, so a role at a subscription reaches everything below it — and inheritance is live, so resources created next year are covered automatically. C is the tempting near-miss: access is not a snapshot frozen at assignment time. This is exactly why assigning high "to be safe" is dangerous — you are not granting access to what exists, you are granting it to everything that ever will.
B. Managing access is precisely the power Contributor lacks — the one cell that separates it from Owner. To grant roles you need Owner or the narrower User Access Administrator. D is wrong because access can be delegated at any scope by someone holding the right role there; it is not reserved to a single super-admin. This boundary is a feature: it lets people build without letting them quietly widen who can reach the system.
The three-part assignment, Policy governing what regardless of who, and audit recording without blocking. The two false statements are the ones that cause real incidents: believing Owner beats a deny policy (it never does — different questions, both must pass) and believing RBAC and Policy are one system. They are independent guards, and a resource is created only when RBAC says the actor may and Policy says the result may exist. Miss that and you will design governance that a role assignment can quietly defeat.
ACCESS PLAN — Campux
1. Platform leads: Owner at the management group (2 people).
2. Developers: Contributor on the non-prod subscription.
3. Auditor: Reader on the prod subscription.
4. CI deployment identity: Owner on the prod subscription,
so deployments never fail on a permission error.
Line four. Two errors compounded: the wrong role at the wrong scope. A deployment pipeline needs to create and manage resources, which is Contributor, not Owner — it never needs to grant access to others, the one extra power Owner carries. And it should be scoped to the specific resource groups it deploys into, not the whole production subscription. "So deployments never fail on permissions" is convenience buying a maximal blast radius.
Consider the consequence. A compromised CI identity — a leaked credential, a poisoned build — now holds total control of production and the ability to hand that control to new identities, covering its tracks. Scoped Contributor would have let the same pipeline do the same deployments while containing exactly this disaster. The fix costs nothing and prevents the worst day of the year.
Two things are wrong with "Owner, clean up later": the role and the word "later". The contractor needs to build, which is Contributor, not Owner — they never need to grant access. And standing access that outlives its purpose is how estates fill with forgotten permissions; "later" is the cleanup that never gets prioritised until an audit or a breach forces it.
Scope it and time-box it. Grant Contributor at the specific resource group the contractor works in, not the whole subscription — the least privilege at the lowest scope that lets them do the job. That alone turns a subscription-wide risk into a contained one.
Then make expiry automatic, not a promise. Use just-in-time assignment through Privileged Identity Management: the contractor becomes eligible for the role and activates it when needed, against an approval and a time limit, and it lapses on its own. The access ends when the project does whether or not anyone remembers — which is the whole point, because no one will. This is the landing page's "You Decide" contractor scenario, and this is the decision.
Correct the premise first: RBAC is not the only guard. Owner answers "may this person act," and yes, it lets them create resources. It says nothing about "may this resource exist in this region" — that is Azure Policy's question, and it is the one nobody has answered yet. The developer is not exploiting a loophole; the fire code simply has not been posted. This is the RBAC-versus-Policy distinction made concrete.
Roll out with audit before deny. Do not slam a deny policy on live infrastructure — start the allowed-regions policy in audit effect, which flags the out-of-region resources without breaking anything, and gives you an exact inventory of what already violates it and needs migrating or exempting. Governance that begins with deny on day one tends to break something and lose the room.
Then switch to deny, and it binds everyone. Once the existing resources are dealt with, flip the effect to deny at the management group. From then on no one creates in a forbidden region — not the developer, not you, not an Owner — because policy stops the result regardless of the role. The behaviour changes structurally, not by asking people to be careful.
Five things worth carrying out of this class
- Authentication proves who you are; authorization decides what you may do. RBAC is authorization; Entra ID does the authentication.
- A role assignment is a principal, a role, and a scope. It inherits down the hierarchy, so grant the lowest scope that works.
- Contributor builds anything but grants nothing. That one missing power is what separates it from Owner — reserve Owner ruthlessly.
- RBAC governs who may act; Policy governs what may exist. An Owner cannot override a deny policy — both guards must say yes.
- Every click is a debt. Governance you cannot reproduce is a rumour; roll out enforcement with audit before deny.
- Azure has dozens of built-in roles beyond these three — many scoped to a single service, like Storage Blob Data Contributor or Key Vault Secrets User — and you can define custom roles when none fits. Reach for a narrow built-in role before a broad one, and for a custom role before Owner; the specificity is the security. Owner, Contributor and Reader are simply the three you meet first and most. ↩
- There is one honest asterisk: policy governs the Azure control plane — the creation and configuration of resources — not what happens inside a resource, such as the rows in a database or the files in a storage container. Those are guarded by their own data-plane permissions. Do not oversell policy as protecting everything; it protects the shape of your estate, which is a great deal, but not its contents. ↩
- Azure Policy has more effects than the three shown — append, modify, auditIfNotExists, denyAction, manual and disabled among them. Audit, deny and deployIfNotExists are the ones that carry most real governance and the ones an exam expects on sight; meet the rest when a specific need sends you to the documentation. ↩