2.12 Azure RBAC, Zero Trust, and Defense in Depth
Key Takeaways
- Azure RBAC (Role-Based Access Control) is the authorization layer built on Azure Resource Manager: it decides who can do what on which resources.
- A role assignment binds three things: a security principal (who), a role definition (what permissions), and a scope (where) — management group, subscription, resource group, or resource.
- Built-in roles to memorize: Owner (full + grant access), Contributor (full but cannot grant access), Reader (view only), and User Access Administrator (manage access only).
- Zero Trust assumes breach and rests on three pillars: verify explicitly, use least-privilege access, and assume breach.
- Defense in Depth uses layered controls with data at the center and physical security as the outermost layer; RBAC permissions are additive and inherited down the hierarchy.
Quick Answer: RBAC is authorization — it grants permissions on Azure resources via role assignments (Owner, Contributor, Reader, User Access Administrator). Zero Trust = verify explicitly, least privilege, assume breach. Defense in Depth = layered controls with data at the center and physical security on the outside.
Azure Role-Based Access Control (RBAC)
Azure RBAC is the authorization system built on Azure Resource Manager (ARM). After Entra ID authenticates a user, RBAC decides what that user may do on a given resource. Every role assignment combines three parts:
| Component | Meaning | Example |
|---|---|---|
| Security principal | Who is being granted access | User, group, service principal, or managed identity |
| Role definition | The collection of allowed actions | Contributor, Reader, custom role |
| Scope | Where the access applies | Management group, subscription, resource group, resource |
The Four Built-In Roles to Memorize
| Role | Can manage resources? | Can grant access to others? |
|---|---|---|
| Owner | Yes (full) | Yes |
| Contributor | Yes (full) | No |
| Reader | No (view only) | No |
| User Access Administrator | No | Yes (manages role assignments only) |
The classic AZ-900 distinction: Owner = Contributor + the ability to assign roles. A user who must deploy and manage resources but should not hand out permissions gets Contributor, not Owner.
Scope, Inheritance, and Additive Permissions
RBAC follows the resource hierarchy, and assignments inherit downward:
- Management group → applies to all child subscriptions
- Subscription → applies to all resource groups and resources within
- Resource group → applies to all resources inside it
- Resource → applies only to that single resource
Permissions are additive (cumulative), not subtractive. If a user holds Reader at the subscription and Contributor on one resource group, they can manage that group while only viewing everything else. Roles never cancel out — to remove access you remove the assignment.
RBAC vs. Azure Policy (a frequent trap)
| Azure RBAC | Azure Policy | |
|---|---|---|
| Controls | Who can perform actions | What configurations are allowed |
| Example | "User A can create VMs" | "VMs must be Standard_D-series in West US" |
| Acts on | Identities and permissions | Resource properties and compliance |
RBAC answers "who," Azure Policy answers "what is compliant." They are complementary, not interchangeable.
Zero Trust
Zero Trust discards the old "trusted internal network" assumption. Nothing — no user, device, or network location — is trusted by default; every request is authenticated, authorized, and encrypted. Three guiding principles:
| Principle | What it means |
|---|---|
| Verify explicitly | Authenticate and authorize on all signals (identity, device, location, risk) every time |
| Use least-privilege access | Limit users with just-in-time (JIT) and just-enough-access (JEA) |
| Assume breach | Segment the network, minimize blast radius, encrypt end-to-end, monitor with analytics |
Azure delivers Zero Trust through Entra ID + Conditional Access (identity), NSGs and Private Link (network segmentation), Microsoft Defender for Cloud (posture), and Microsoft Sentinel (detection).
Defense in Depth
Defense in Depth stacks independent controls so that breaching one layer does not expose the asset. Picture concentric rings with data at the bullseye:
| Layer (outer → inner) | Purpose | Azure controls |
|---|---|---|
| 1. Physical | Datacenter access (Microsoft's responsibility) | Fences, guards, biometrics |
| 2. Identity & access | Authenticate and authorize | Entra ID, MFA, Conditional Access |
| 3. Perimeter | Block volumetric and edge attacks | DDoS Protection, Azure Firewall |
| 4. Network | Limit lateral movement | NSGs, VNet segmentation, Private Link |
| 5. Compute | Harden hosts | Azure Bastion, patching, endpoint protection |
| 6. Application | Ship secure code | WAF, secure SDLC, vulnerability scanning |
| 7. Data | Protect the asset itself | Encryption at rest/in transit, Key Vault, RBAC |
On the Exam: Data is at the center; physical security is the outermost layer. Memorize those two anchors — they are reliably tested.
Principle of Least Privilege
Grant the minimum access needed, and no more. In Azure:
- Assign Reader when a user only needs visibility, never Contributor "just in case."
- Use Privileged Identity Management (PIM) for time-bound, approval-gated admin roles (requires Entra ID P2).
- Use just-in-time (JIT) VM access to open management ports only when needed.
- Run periodic access reviews to revoke stale assignments.
Least privilege directly enforces the Zero Trust "use least-privilege access" principle — the two concepts reinforce each other on the exam.
Worked Scenario: Assigning Access Correctly
Consider a help-desk analyst who must restart virtual machines in one resource group but should never delete resources or grant access to anyone. The temptation is to assign Owner at the subscription, but that violates least privilege catastrophically. The correct approach: assign a narrowly scoped role (Contributor on just that resource group, or an even tighter built-in role such as Virtual Machine Contributor) so the analyst can manage VMs there and nowhere else, with no ability to assign roles. If the elevated access is needed only occasionally, wrap it in PIM so the role is activated on demand, time-boxed, and logged.
RBAC and Resource Locks Are Different
A frequent mix-up: resource locks are not RBAC. A lock (CanNotDelete or ReadOnly) applies to a scope regardless of the user's role — even an Owner is blocked from deleting a CanNotDelete-locked resource until the lock is removed. RBAC governs identity-based permissions; locks add a guardrail against accidental change. Both can apply at once.
Why It Matters for AZ-900
Security and governance carry meaningful weight on the AZ-900 exam (about 40-60 questions, 700/1000 to pass). Examiners love three reliable patterns: (1) the Owner vs. Contributor distinction (grant access vs. not), (2) additive, inherited RBAC permissions, and (3) the data-at-center / physical-at-edge anchors of Defense in Depth.
Quick Recall Checklist
- Role assignment = principal + role + scope.
- Owner can assign roles; Contributor cannot; Reader is view-only.
- Permissions are additive and inherit downward through the hierarchy.
- Zero Trust = verify explicitly, least privilege, assume breach.
- Defense in Depth: data center-most, physical outer-most, seven layers total.
Which built-in Azure RBAC role grants full management of resources but explicitly cannot assign roles to other users?
A user has the Reader role at the subscription scope and the Contributor role on one resource group. What are their effective permissions?
In the Microsoft Defense in Depth model, which statement is correct?
Which Azure capability controls WHO can perform actions, as opposed to WHAT resource configurations are permitted?