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.

This lesson builds a repeatable design method around Azure role-based access control (Azure RBAC), role assignment scope, Azure attribute-based access control (Azure ABAC) conditions, managed identities, and Microsoft Entra Privileged Identity Management (PIM). The goal is not to memorize every built-in role. It is to translate business duties into the smallest durable permission boundary and to explain why nearby controls—Azure Policy, resource locks, Conditional Access, and network rules—solve different problems.

Learning objectives

After this lesson, you should be able to:

1. Separate authentication, authorization, governance, and network-access requirements.
2. Construct an Azure RBAC role assignment from a security principal, role definition, and scope.
3. Choose a built-in role before designing a custom role, and distinguish control-plane Actions from data-plane DataActions.
4. Select the narrowest practical scope while accounting for inheritance and operational scale.
5. Add ABAC conditions only when a supported attribute-based restriction is required.
6. Use PIM for just-in-time administrative access and managed identities for workload authorization.
7. Validate the effective-access path and diagnose common 403 failures.

The decision frame: identify the control plane

An architecture question usually contains several security requirements. Classify each before choosing a product.

Conditional Access also belongs to the authentication/session side: it evaluates signals such as user risk, device state, location, and requested application before issuing or maintaining access. A resource lock prevents deletion or modification even by otherwise authorized principals, but it is not a replacement for least-privilege roles. Azure Policy evaluates resource state and deployment operations; it does not grant a user permission to read or update a resource.

Azure RBAC: principal, role, and scope

Azure RBAC is Azure Resource Manager's authorization system. A role assignment joins three elements:

• Security principal—the who. A user, group, service principal, or managed identity.
• Role definition—the allowed operations. Usually a built-in role; sometimes a custom JSON definition.
• Scope—the where. Management group, subscription, resource group, or individual resource.

The assignment applies at its scope and inherits down the resource hierarchy. A group assigned Reader at a subscription can read resource groups and resources in that subscription. An additional narrow role at one resource adds permissions; RBAC permissions are generally additive. Deny assignments can override allowed actions, but normal administrators do not author arbitrary deny assignments as a substitute for role design.

Text equivalent: select the principal type, prefer a built-in role, select scope, add a supported condition only when needed, make privileged human access eligible, and validate effective permissions.

Control-plane and data-plane permissions

A role definition can carry two permission families:

• Actions and NotActions describe Azure Resource Manager operations, such as reading a storage account configuration or restarting a virtual machine.
• DataActions and NotDataActions describe operations against data inside a service, such as reading blob contents or secrets.

This distinction explains a classic failure: Reader can view a storage account in the portal but cannot read blob data. Contributor can configure the account but does not automatically receive every data-plane permission. Add a data role such as Storage Blob Data Reader when the duty is to read blobs. For Key Vault, use the service's RBAC data roles when the vault is configured for Azure RBAC; a control-plane contributor should not automatically read secrets.

Built-in roles before custom roles

Built-in roles receive Microsoft-maintained updates and make audits easier. Begin with a task-specific built-in role. Use a custom role when no built-in role expresses the required operation set without material excess privilege.

A custom role includes allowed and excluded management and data actions plus AssignableScopes. NotActions is not a deny rule; it subtracts actions from that role definition. Another role assignment may still grant the same operation. Keep custom roles stable and duty-oriented—Network Peering Operator is more maintainable than a role named after one employee or project sprint.

Scope and inheritance

The narrowest possible scope is not always the narrowest practical scope. Assigning the same role separately to 800 resources creates drift and consumes role assignments. A resource-group assignment can be safer when all resources share one lifecycle and duty boundary. A subscription assignment may be appropriate for a central monitoring team that must read every current and future resource, but it is too broad for an application operator responsible for one workload.

Use groups for human access. Assigning roles directly to dozens of users increases review effort and makes joiner/mover/leaver processes fragile. Put users in a duty-based group, assign the group once, and govern membership. For applications, assign the managed identity rather than a developer's account or a long-lived client secret.

Deterministic infrastructure as code

Role assignments should be reproducible. In Bicep, generate a deterministic assignment name from the scope, principal, and role. Deploying the same template should converge on the same row rather than create duplicates.

New identities and role assignments can take time to propagate. Supplying principalType helps deployment behavior for newly created service principals. A retryable validation step is safer than assuming an immediate data-plane request will succeed.

ABAC conditions: narrow an assignment with attributes

Azure ABAC extends Azure RBAC with role assignment conditions. A condition evaluates supported attributes from the principal, resource, request, or environment and filters permissions granted by the assignment. It does not create an explicit deny, and it cannot turn an unrelated role into a universal policy language.

The most mature scenarios concern Azure Storage blob and queue data actions. For example, a broad storage data role can be limited to blobs with a particular index tag or to a path/container constraint. Current Microsoft documentation must control which actions and attributes are supported; do not assume every Azure service accepts RBAC conditions.

Use ABAC when a stable business attribute can replace many near-identical assignments. Do not use it when a few clear resource-group scopes are simpler, when the service/action is unsupported, or when tags are not governed reliably.

PIM: remove standing administrator access

PIM for Azure resources can make an assignment eligible rather than permanently active. The user activates it when needed, subject to controls such as MFA, justification, approval, activation duration, and notification. The resulting access is time-bounded and auditable.

Use eligible assignments for human administrative duties such as subscription ownership or access administration. Do not put workload identities through a human activation flow. Workloads require durable runtime authorization, normally through managed identity and a narrowly scoped role.

PIM and ABAC can be combined: PIM controls when the privileged assignment becomes active; an RBAC condition controls which supported resources or data it can reach while active.

Managed identities and workload authorization

A system-assigned managed identity shares the lifecycle of one Azure resource. A user-assigned managed identity is a separate resource that can be attached to multiple workloads and survive their replacement. Choose system-assigned identity for simple one-resource ownership. Choose user-assigned identity when several resources require the same identity, when preauthorization must exist before compute deployment, or when workload replacement must preserve identity.

Managed identity removes application-managed credentials, but it does not grant access by itself. The identity still needs an RBAC assignment on the target resource. The application obtains a token for the target resource and the service evaluates that identity's permissions.

Worked scenario: platform operations without permanent ownership

Contoso has 40 subscriptions under a Production management group. A central platform team must restart virtual machines and view monitoring data in every production subscription. Only two security leads may grant access, and they should have that capability for at most one hour after approval. A deployment service writes artifacts to one storage container. It must not receive storage-account management access.

Recommended design:

1. Create Platform-VM-Operators and assign task-specific VM operation and monitoring roles at the Production management-group scope. The assignment inherits to current and future subscriptions.
2. Avoid Contributor if the task roles cover restart and monitoring duties. Do not assign Owner merely for convenience.
3. Make the two security leads eligible for User Access Administrator or the least-privileged access-management role through PIM, with approval, MFA, justification, and a one-hour duration.
4. Give the deployment service a managed identity and assign Storage Blob Data Contributor at the target container scope. Do not use a storage account key and do not grant storage account Contributor for data writes.
5. If the container contains several governed data classes and the supported attributes express the rule, add an RBAC condition. Otherwise split the scope into separate containers.

Troubleshooting effective access

When a valid identity receives 403, walk the evaluation path:

1. Confirm the token represents the expected tenant, principal, and audience.
2. Identify whether the denied operation is control plane or data plane.
3. List direct and group role assignments at the resource and every ancestor scope.
4. Inspect Actions/DataActions, exclusions, and conditions for the requested operation.
5. Confirm a PIM-eligible role was activated and has not expired.
6. Look for deny assignments and service-specific authorization modes.
7. Account for propagation delay, token caching, and stale group membership.
8. Check network access separately if the result is a timeout rather than an authorization response.

Common exam traps

• Contributor can manage access. False. Contributor manages resources but cannot generally create role assignments.
• Reader can read service data. Not necessarily. Reader is primarily a control-plane role.
• NotActions is a deny. False. It subtracts permissions from one role definition.
• Policy grants authorization. False. Policy governs resource configuration and compliance.
• A managed identity automatically has permissions. False. It supplies an identity; RBAC supplies authorization.
• ABAC works identically across every Azure service. False. Verify supported actions and attributes.
• PIM is for application runtime access. False. It is primarily for governed human privilege activation.
• The resource scope is always best. Not if it produces hundreds of fragile assignments; use the narrowest durable boundary.

Retrieval checkpoint

Summary

Design Azure resource authorization by translating a duty into principal, allowed operations, scope, and optional conditions. Prefer groups for people, managed identities for workloads, built-in roles for common duties, and the narrowest maintainable scope. Distinguish management operations from data access, use PIM to remove standing human privilege, and use ABAC only for supported attribute-based restrictions. Validate the complete effective-access path rather than treating every security failure as an authentication problem.

Sources and freshness

Reviewed 2026-08-02. Scope follows the April 17, 2026 AZ-305 study guide. Current behavior is grounded in Microsoft's Azure RBAC documentation, Azure ABAC conditions overview, managed identities overview, and PIM for Azure resource roles. The attached Exam Ref supplies historical teaching context; current Microsoft documentation controls supported features and limits.