3.3 Authorization for Azure Resources

Why Azure RBAC Design Matters

Every Azure resource — from a management group down to a single storage blob container — is protected by the same authorization system: Azure role-based access control (Azure RBAC). Because RBAC is universal, AZ-305 tests it more heavily than almost any other single mechanism in the identity domain, and it appears embedded inside data storage, networking, and business-continuity scenarios as well as standalone governance questions. An architect who cannot correctly reason about scope inheritance or the difference between a built-in and a custom role will get scenario questions wrong even when the "headline" topic is something else, like Key Vault or Cosmos DB.

Core RBAC Vocabulary

• Security principal — the identity being granted access: a user, group, service principal (app identity), or managed identity.
• Role definition — a collection of permissions (what can be done): a list of allowed and denied actions.
• Scope — where the permissions apply: management group, subscription, resource group, or a specific resource.
• Role assignment — the binding of a security principal + role definition + scope. Access exists only where all three are attached together.

Built-In Roles You Must Know

Scope Hierarchy and Inheritance

Azure RBAC scope forms a hierarchy: management group → subscription → resource group → resource. A role assignment made at a higher scope is inherited by everything beneath it. Assigning Reader at the management group level, for example, grants read access to every subscription, resource group, and resource nested under that management group — a design choice that saves dozens of individual assignments but also means a mistake at a high scope has a wide blast radius. AZ-305 scenarios frequently test whether you assign at the lowest scope that satisfies the requirement (least privilege) rather than defaulting to subscription-wide grants for convenience.

Custom Roles

When no built-in role matches a requirement precisely, Azure RBAC supports custom roles, defined with this structure:

{
  "Name": "VM Operator (No Delete)",
  "Actions": [
    "Microsoft.Compute/virtualMachines/start/action",
    "Microsoft.Compute/virtualMachines/restart/action",
    "Microsoft.Compute/virtualMachines/read"
  ],
  "NotActions": [],
  "DataActions": [],
  "NotDataActions": [],
  "AssignableScopes": [
    "/subscriptions/{subscription-id}"
  ]
}

• Actions — management-plane operations the role allows (e.g., start/restart a VM).
• NotActions — carve-outs subtracted from Actions (useful for taking a broad built-in-like role and removing one sensitive permission).
• DataActions / NotDataActions — data-plane operations, such as reading blobs inside a storage account or reading secrets inside a Key Vault, which are governed separately from management-plane actions.
• AssignableScopes — which management groups, subscriptions, or resource groups the custom role is allowed to be assigned within.

A common exam scenario: "Operations staff should be able to restart virtual machines to resolve incidents but must never be able to delete them." A built-in role either grants too much (Contributor can delete) or too little (Reader cannot restart) — the correct recommendation is a custom role scoped to start/action and restart/action only.

Deny Assignments

Deny assignments work like role assignments but block actions instead of granting them, and — unlike custom roles — they cannot be authored directly by most administrators. Azure creates deny assignments automatically in specific system scenarios, such as protecting resources deployed through Azure Blueprints or Azure Managed Applications, so that even a subscription Owner cannot accidentally modify a protected resource. Recognize deny assignments as a system-generated protection mechanism, not a tool you design directly.

Exam Scenario

A design requires that a finance team's read-only reporting dashboard service principal can read cost and usage data across the entire tenant, while a separate DevOps service principal can only modify resources inside a single resource group used for a specific application. The correct design assigns Reader to the finance service principal at the management group scope (broad, read-only, minimal risk) and Contributor to the DevOps service principal at the resource group scope (narrow, write access, contained blast radius) — two different scopes chosen deliberately to match each principal's actual need, not a single subscription-wide assignment for both.

Common Traps

• Confusing Azure RBAC (who can do what to a resource) with Azure Policy (what configurations are allowed to exist) — Policy enforcement is covered in Chapter 4; RBAC is strictly about access, not compliance rules.
• Assigning Owner when Contributor plus a narrower access-management role would satisfy least privilege.
• Forgetting that DataActions are separate from Actions — a role with full management-plane Actions on a storage account still cannot read blob data unless DataActions explicitly grant it (or Azure RBAC is enabled as the storage account's data-plane authorization mode).
• Assuming a role assignment at a resource automatically limits inherited higher-scope assignments — inheritance flows down only; it does not get revoked by a narrower assignment below it (you would need a deny assignment or narrower custom role instead).