Quick Note — Recommend a Solution for Authorizing Access to Azure Resources
AZ-305 › Unit 1 › Design authentication and authorization solutions › Recommend a solution for authorizing access to Azure resources
Quick Note — Recommend a Solution for Authorizing Access to Azure Resources
Authentication establishes who or what is making a request. Authorization decides what that identity may do, to which resource, and under which conditions. AZ-305 scenarios often blur those two decisions: a user signs in successfully through Microsoft Entra ID but receives 403 Forbidden from Azure Resource Manager or from a storage data endpoint. The architect must then select the correct authorization control rather than adding another authentication factor.
Retrieval target
- Recommend a Solution for Authorizing Access to Azure Resources
- Closed-book recall
- 5 minutes
- Open the full lesson after a miss
Decision anchors
| Prompt | Compact answer |
|---|---|
Azure RBAC | An authorization fabric built over Azure Resource Manager. Decides whether a security principal is allowed to perform a control-plane (ARM) or data-plane action on an Azure resource. Three pillars: security principal + role definition + scope, glued together by a role assignment. |
Security principal (RBAC) | The 'who' in Azure RBAC. Four kinds: user, group, service principal (app), and managed identity. Anything that can hold an RBAC role assignment is a security principal — including the application service principal that backs an app registration and the managed identity attached to an Azure resource. |
Role definition | A named bundle of permissions. Each role lists actions (ARM control-plane allowed), notActions (subtracted), dataActions (data-plane allowed, e.g., blob read), and notDataActions. Roles can be broad (Owner, Contributor, Reader) or narrow (Storage Blob Data Reader, Key Vault Administrator). |
Role assignment | The glue between principal, role, and scope: security principal × role definition × scope. Grants the principal the role's permissions at the chosen scope and everything below it. A principal can hold many role assignments; effective permissions are the union of all assignments, minus any deny assignments. |
Read the answers once, then cover the right-hand column and reconstruct each one from the prompt. A useful answer names the requirement, the recommended control or service boundary, and the nearest alternative it rejects. If you can only recognize the answer after seeing it, retrieval is not yet secure.
Ninety-second explanation
Without notes, explain:
- What requirement signals this learning objective rather than a neighbouring one?
- Which two solution families are most likely to be compared?
- Which hard constraint eliminates the strongest distractor?
- What identity, network, data, or failure boundary must appear in the design?
- Which operational test would prove the recommendation works?
Then compare your explanation with the full lesson. Record the missing decision rule—not merely the missed product name—in your error log.
When to open the full lesson
Open the curriculum-linked lesson when you cannot explain a comparison, when a scenario depends on a numeric limit or SKU feature, or when the service is on a retirement path. Use current Microsoft Learn documentation for availability, limits, pricing, naming, and migration milestones; the quick note is intentionally compact.
Source and freshness
Derived from the linked AZ-305 lesson and retrieval deck, grounded in both attached course sources. Reviewed 2026-08-02. Current Microsoft documentation controls changing product contracts.