There are hundreds of built-in Azure roles, but three cover most of what you do — and the difference between two of them is the single most common access mistake in the cloud. Here is the model, and the trap.
Azure Owner vs Contributor: an Owner has full access including the right to grant access and assign roles to other people, while a Contributor can create, manage, and delete every resource except assigning roles or changing who has access. That single capability — role assignment — is the only difference between the two. Everything below is that idea, drawn out.
Azure role-based access control (RBAC) is how you answer "who can do what, where." It sounds like it should require a spreadsheet, but the everyday reality runs on three fundamental roles: Owner, Contributor, and Reader. Learn exactly what separates them and you can grant access confidently — and stop handing out Owner because you were not sure.
The short answer: Contributor can do everything Owner can — create, change, and delete every resource in scope — except one thing: assign roles to other people. That single capability is the only difference. Reader can view everything and change nothing.
The three roles, in Microsoft's own words
| Role | What it grants | Can assign roles? |
|---|---|---|
| Owner | Full access to manage all resources | Yes — and can manage others' access |
| Contributor | Full access to manage all resources | No |
| Reader | View all resources; make no changes | No |
| User Access Administrator | Manage access only — assign roles, but not the resources themselves | Yes — access only |
Microsoft's definitions are precise. Owner "grants full access to manage all resources, including the ability to assign roles in Azure RBAC." Contributor "grants full access to manage all resources, but does not allow you to assign roles." Reader lets you "view all resources, but does not allow you to make any changes." Two of those descriptions are almost identical — and that near-identical pair is where the trap lives.
The three built-in roles nest: Owner ⊃ Contributor ⊃ Reader. Reader can look; Contributor can also create and change resources but cannot hand out access; Owner can do everything Contributor can and also grant access to others. Give the innermost role that still lets the person do their job.
The one difference that matters
Owner and Contributor can both do essentially everything to the resources — create, change, delete VMs, databases, networks, all of it. The single distinction is access management. Owner can grant and revoke other people's access; Contributor cannot. Contributor can build the entire environment but cannot hand out a single role.
That gap is the whole point, and it is the security control people accidentally throw away. If a team needs to deploy and manage workloads, they need Contributor — not Owner. Giving them Owner "to be safe" hands them the power to grant themselves and anyone else more access, quietly, forever. The instinct that Owner is the helpful, generous choice is exactly backwards: Owner is the role you give almost no one.
Contributor builds everything and grants nothing. That gap is a feature, not a limitation.
The role for "manage access, nothing else": What if someone genuinely needs to manage access but should not touch the resources? That is a specific built-in role — User Access Administrator — which grants role assignment and nothing more. Splitting "who can change things" from "who can grant access" is how mature organizations avoid Owner sprawl. If your only tool is Owner, you cannot make that split.
Scope: where the role applies
A role is only half of a role assignment; the other half is scope — the level at which it applies. You assign a role at a management group, a subscription, a resource group, or a single resource, and it inherits downward: Reader at the subscription means Reader on every resource group and resource inside it. This is why you think about scope as carefully as role. "Contributor on this one resource group" is a tight, sensible grant; "Owner on the subscription" is handing someone the keys to everything beneath it.
The principle underneath: least privilege
All of this serves one idea — give each identity the least access it needs to do its job, at the smallest scope that works. Concretely:
- Someone who only needs to look — auditors, dashboards, on-call read access — gets Reader.
- Someone who builds and operates workloads gets Contributor, scoped to the resource groups they own.
- Owner is reserved for the few who must also manage access — and even then, prefer scoping it as narrowly as the job allows.
Get comfortable saying "Contributor on that resource group, not Owner on the subscription" and you are speaking the language of every security review. The three roles are simple; the discipline is choosing the smallest one that still lets the work happen — and remembering that the gap between Contributor and Owner is a wall you put up on purpose.
Questions people also ask
What is the difference between Azure Owner and Contributor?
Both can create, change, and delete every resource in scope. The only difference is access management: Owner can assign roles to other people, Contributor cannot. If a person only needs to build and operate workloads, Contributor covers it — Owner adds nothing except the power to grant access.
Can a Contributor assign roles in Azure?
No. Contributor grants full access to manage resources but explicitly excludes role assignment. To hand out access to others, an identity needs Owner, User Access Administrator, or the newer Role Based Access Control Administrator role instead.
What can a Reader do in Azure?
View. A Reader assigned at a subscription can see every resource group and resource beneath it — configuration, metadata, monitoring data — but cannot create, change, or delete anything, and cannot assign roles. It is the right fit for auditors and on-call visibility.
Does Owner include Contributor permissions?
Yes. Owner is Contributor plus one thing: the ability to assign roles in Azure RBAC. There is no resource-management action Contributor can take that Owner cannot; the roles differ only in whether access management is included.
Do Azure RBAC roles inherit down through scope?
Yes. Assign a role at a management group, subscription, or resource group and it applies to everything beneath that scope. Reader at the subscription means Reader on every resource group and resource inside it, which is why picking the smallest correct scope matters as much as picking the smallest correct role.
Further reading — the Microsoft docs
This is the model. Class 8 — RBAC & Azure Policy takes you hands-on: assign roles at the right scope, watch them inherit down, and pair RBAC with policy so the wrong thing is not just discouraged but denied.
This article was originally published on CAMPUX, a free Azure cloud-engineering bootcamp.
Top comments (0)