Skip to lesson

MicrosoftMicrosoft Certified: Multi-Agent AI Solutions Expert2026-100 Prerequisites

Separate credentials from Azure access grants

Completed by the knowledge check

Learning objective

Apply Microsoft Entra ID, DefaultAzureCredential, managed identities, and Azure RBAC basics.

Core idea

Authentication establishes which principal makes a request. Authorization determines what that principal can do to the target resource. Microsoft Entra ID supplies identity and access tokens; Azure role-based access control (Azure RBAC) grants permissions through role assignments. Obtaining a token is necessary for an Entra-authenticated call, but it does not prove that the requested operation is allowed.

For an architect preparing for AI-500, keep three records explicit: the credential source, the resulting principal, and the permission granted at the target. DefaultAzureCredential helps obtain credentials across environments. It does not create a managed identity or assign a role. See 0.6 for delegated authority and 1.2.3 for Foundry agent identity lifecycle; this lesson supplies the underlying Azure mechanics.

How it works

Identify the security principal

Microsoft Entra ID represents users and application identities. Azure RBAC can assign roles to users, groups, service principals, and managed identities. A developer’s interactive identity and a deployed application’s identity are distinct principals even when both execute the same code.

For Blob Storage, the application requests an OAuth 2.0 access token and passes it with its request. The Blob service then checks the principal’s data permissions. Keep the target service explicit: successful authentication to one service is not a grant to another service or to every operation in the subscription.

When troubleshooting a request, identify the principal that actually acquired the token. Do not infer it from the developer who deployed the application. A local call might use a developer account, while its deployed counterpart uses a managed identity with a narrower assignment. That difference often explains why identical application logic produces different access outcomes.

Understand the credential chain

In Python’s Azure Identity library, DefaultAzureCredential is a preconfigured chain. It tries credential sources in a documented order. EnvironmentCredential can authenticate an application service principal configured through environment variables. WorkloadIdentityCredential and ManagedIdentityCredential support their respective deployed identity mechanisms. Developer-tool credentials include AzureCliCredential, which uses the account authenticated through az login.

This ordering matters. Environment-based application credentials appear before managed identity and developer-tool credentials. If a machine contains configured service-principal credentials, do not assume that signing in to Azure CLI makes the CLI account the active principal. Inspect the chain and configuration rather than repeatedly assigning roles to the account you expected it to choose.

Customize the Python chain with supported constructor arguments. For example, exclude_environment_credential=True removes environment credentials, while managed_identity_client_id selects a user-assigned managed identity. InteractiveBrowserCredential is excluded by default; exclude_interactive_browser_credential=False enables it. These names describe Python behavior and should not be copied into another language’s SDK without checking its API.

The Python chain also supports AZURE_TOKEN_CREDENTIALS=prod to exclude developer-tool credentials and AZURE_TOKEN_CREDENTIALS=dev to exclude deployed-service credentials in azure-identity 1.23.0 or later. Selecting one credential by name requires 1.24.0 or later. These version qualifiers are part of the configuration contract, not optional trivia.

Choose an explicit ManagedIdentityCredential when production should use only that source. A broad development chain offers convenience, but a deliberate production credential source makes the identity easier to explain and diagnose. None of these options grants the selected principal access to the target.

Choose the managed identity lifecycle

A system-assigned managed identity belongs to one supported Azure resource. Enabling it creates a service principal tied to that resource’s lifecycle. Deleting the resource deletes the identity. Only that resource can use its system-assigned identity to request tokens.

A user-assigned managed identity is a standalone Azure resource with an independent lifecycle. You can attach it to multiple supported Azure resources. That separation lets you authorize an identity before creating or replacing compute, but sharing it also gives those workloads a shared permission set.

Microsoft recommends user-assigned managed identities for Microsoft services. They fit preauthorization during provisioning and frequent compute replacement when permissions should stay consistent. Choose system-assigned identity when the workload should have an identity that disappears with its host. Choose user-assigned identity when compute replacement should preserve the intended identity and permissions. If two workers need different data access, do not attach the same identity merely to reduce provisioning steps.

Managed identities avoid application-managed credentials for token acquisition on supported hosts. They still require authorization on downstream services that support Entra authentication. Enabling identity on the caller and assigning a role on the target are separate operations.

Build the role assignment correctly

An Azure RBAC role assignment combines a security principal, role definition, and scope. The role lists permitted actions; the scope limits where they apply. The hierarchy includes management group, subscription, resource group, and resource. Assignments at broader scopes are inherited by child resources.

For Blob access, use the data role that matches the operation. Storage Blob Data Reader grants read-only access. Storage Blob Data Contributor grants read, write, and delete access. Blob roles can be scoped to an individual container when that is the required dataset.

Management access is different. Contributor and Storage Account Contributor can manage storage resources but do not directly grant Blob data access through Entra ID. Roles that include Microsoft.Storage/storageAccounts/listKeys/action can enable access through account keys, which is a different authorization path. Do not mistake the ability to retrieve a key for an Entra data permission.

Azure RBAC role assignments are additive, but an applicable deny assignment blocks access. Assigning the built-in Reader role at a narrow scope does not cancel a broad Contributor assignment the principal already inherits. Evaluate the combined role assignments and applicable deny assignments before concluding that your narrow role enforces least privilege.

Key distinctions and trade-offs

Credential versus principal: A credential object acquires tokens. The principal is the identity represented by those tokens. Changing credential configuration can change the principal without changing business code.

Identity lifecycle versus permission scope: System-assigned and user-assigned choices determine identity ownership and reuse. Role assignments determine access. Neither identity type is inherently read-only.

Control plane versus data plane: Managing an account and reading its contents are different operations. Select the documented data role instead of increasing management permissions until the application works.

Architecture / decision scenario

A developer runs a document reader locally after az login. The Python client uses DefaultAzureCredential, and the developer has Storage Blob Data Reader on the test container. Before deployment, the team verifies that environment credentials do not unexpectedly select another principal.

In Azure, the worker attaches a user-assigned managed identity so compute replacement preserves its identity. Production selects that identity through ManagedIdentityCredential. The deployment assigns Storage Blob Data Reader to the identity at the production container, rather than copying the developer’s subscription-wide management permissions.

A separate report writer receives its own identity and Storage Blob Data Contributor on an output container. If the reader cannot download a blob, the team checks the selected principal and data assignment rather than granting Contributor. It also reviews inherited assignments: a narrow container role cannot subtract broader access already granted elsewhere.

Common exam traps

  • Treating DefaultAzureCredential as a role-assignment mechanism.
  • Assuming local Azure CLI identity and deployed managed identity are the same principal.
  • Assuming a managed identity is authorized because it exists.
  • Treating user-assigned identity as belonging to one host’s lifecycle.
  • Using a storage management role as an Entra Blob data role.
  • Expecting a narrow role assignment to override a broader grant, or ignoring an applicable deny assignment.

What to remember

Choose the credential source, confirm the principal, and assign the exact role at the required scope. Managed identity removes credential handling from the application; it does not remove authorization design. A working token and an allowed data operation are separate facts.

Knowledge check

References