Articles

Azure Managed Identity Interview Questions: Token Audiences, Permissions, and Local Development

Prepare for Azure managed identity interviews with credential selection, token audiences, Blob data permissions, and local-to-production diagnosis.

A Python export worker reads a blob successfully on a developer's laptop. After deployment to Azure, the same code returns 403. Managed identity is enabled, and the resource has a Contributor role. What should you check next?

Start by asking which identity actually authenticated in each environment. Then separate the token's intended audience, the target service's data permissions, and the network path. “Managed identity enabled” answers only part of that investigation.

The strongest Azure Managed Identity interview answers follow a specific request from credential selection to business operation. They explain why a valid token can still be unsuitable for the requested resource and why a successful local run may exercise a different principal entirely.

Evidence boundary: Microsoft documentation supports the official behavior linked below. The export-worker case and diagnostic tables are original preparation scenarios, not candidate reports or tests run in an Azure subscription. SDK details here use Python examples; check the corresponding library and hosting documentation for another language or Azure service.

For an early design exercise, use Design an Azure IoT feature. Identify the identity used by each hosted component before assigning any permissions.

What does managed identity remove, and what remains your responsibility?

Official fact: Managed identities let supported Azure workloads obtain Microsoft Entra tokens without developers managing the underlying credentials. They still need authorization to the downstream service. System-assigned identities follow their host resource's lifecycle; user-assigned identities are separate resources that can be attached to multiple hosts. See the managed identity overview.

That removes a secret-management burden, not the need for access design. You still decide which workload may use an identity, what the identity may access, and which operations are appropriate.

In the original export-worker case, name the required operation precisely: read one export container in a particular storage account. Do not begin with subscription-wide management access just because the worker runs in that subscription.

Choose identity lifecycle deliberately. A user-assigned identity can retain its permission relationships while compute instances are replaced. Sharing it across unrelated workloads also shares its authority and complicates attribution. A system-assigned identity provides a tighter host relationship, but replacing the resource can require new authorization setup.

The interview tradeoff is operational continuity versus separation of authority. Explain which workloads belong to the same trust boundary and who owns changes to the shared identity.

Which identifier selects the identity, and which identifies the principal?

A managed identity has several identifiers serving different APIs. Its client ID, service-principal object ID, and Azure resource ID are not interchangeable strings. Use the identifier required by the SDK or role-assignment operation, and record the relationship in deployment metadata.

Official fact: Python's ManagedIdentityCredential defaults to a system-assigned identity; its client_id option selects a user-assigned identity. Other supported selection forms depend on the hosting environment. See ManagedIdentityCredential.

For the export worker, an illustrative production credential is:

from azure.identity import ManagedIdentityCredential
from azure.storage.blob import BlobServiceClient

credential = ManagedIdentityCredential(
    client_id="<user-assigned-identity-client-id>"
)
client = BlobServiceClient(
    account_url="https://<account>.blob.core.windows.net",
    credential=credential,
)

The placeholders are configuration, not secrets to invent. This snippet shows identity selection and client construction; it is not a complete application or a test executed for this article. The storage client requests the appropriate token through the credential.

If several identities are attached to a host, explicit selection makes the intended principal reviewable. A role assignment granted to Identity A cannot fix an application that is acquiring a token as Identity B.

What is the difference between token audience and permission scope?

Official fact: In the managed identity VM token endpoint, the requested resource identifies the target resource and appears in the token's audience claim. SDKs expose their own scope-oriented token APIs. See acquiring tokens on a VM.

A token intended for Azure Resource Manager is not a general-purpose pass for every data service. Ask which endpoint receives the token and which audience that service expects. Avoid copying the audience from an unrelated management-plane example into a Blob data request.

Keep two uses of “scope” separate. The OAuth scope requested during token acquisition concerns the target API and token request. An Azure RBAC assignment scope determines where a role's permissions apply, such as a subscription, resource group, storage account, or container. A correct token request does not create the role assignment.

For the original export worker, imagine the principal is correct but the request uses a management token against the Blob endpoint. Increasing a Blob role will not make that token's intended audience correct. Conversely, requesting the right audience does not grant the principal permission to read the container.

If diagnostics require inspecting token metadata, do so through an approved local or service diagnostic workflow. Do not paste a bearer token into an unrelated online decoder or log its full value. Record the selected credential type, intended principal reference, audience, expiry information, and service error correlation safely.

Why can Contributor still fail to read blob data?

Official fact: Azure management roles such as Contributor do not themselves grant Blob data access through Microsoft Entra authorization. Data roles such as Storage Blob Data Reader address that operation. Some management permissions can expose account keys through a separate authorization path, which is a different security consideration. See authorizing Blob access with Entra ID.

For the export worker, inspect the role definition and assignment scope on the actual principal. A data-reader assignment on another storage account or container does not satisfy the intended request. A management role with a reassuring name does not establish the missing data permission.

Describe the minimum necessary grant in terms of business action. If the worker reads exports, explain why write and delete privileges are unnecessary. Then include negative tests for those operations in a safe test environment.

Do not solve the case by switching to a storage account key merely because it makes the request succeed. That would change the authentication and authorization model rather than demonstrate that the intended managed identity setup works. Compare the two mechanisms only if the design explicitly requires that tradeoff.

How can local development hide the actual production problem?

Official fact: DefaultAzureCredential is a chain of credential sources intended to support different environments and developer tools. Its behavior can be customized. See Python credential chains.

A laptop may authenticate using the developer's Azure CLI session, while the hosted application uses managed identity. Identical application code does not imply identical privileges. An environment credential can also alter which principal a chain selects.

Official fact: Microsoft documents using developer accounts for local authentication and granting those accounts appropriate access. See local development with developer accounts.

Build the original comparison matrix before changing permissions:

Dimension	Local run to inspect	Hosted run to inspect
Credential source	CLI, IDE, environment, or explicit credential	Selected managed identity or another configured source
Principal	Developer or application identity	Intended workload service principal
Target	Account, endpoint, container, operation	The same intended resource and operation
Authorization	Developer's effective grants	Workload identity's effective grants
Network	Laptop resolver and route	Hosted resolver, private endpoint, and route

A useful local environment gives developers enough access to exercise the application without silently relying on broad personal administrator rights. In production, prefer a deliberate credential configuration and observable selection behavior appropriate to the host.

Mocked tests can verify how code responds to token or service failures, but they cannot prove that Azure attached the right identity or propagated the right role. Keep those tests separate from a deployment smoke test using the real hosted principal.

How do you distinguish token failure, authorization failure, and networking?

Use the exact failing operation, endpoint, service error code, request ID, and timing. A bare 401 or 403 is a useful clue, but it is not a complete diagnosis across every Azure service and access path.

This original decision table keeps the next check focused:

Observation	Leading check	Change to avoid making prematurely
Credential unavailable on the host	Identity attachment and supported hosting configuration	Granting broader data permissions
Token acquired for an unexpected principal	Credential selection and identity identifiers	Adding roles to an unused identity
Token audience does not fit target API	Requested resource or SDK client configuration	Rewriting network rules
Correct identity and audience, access denied	Data action and assignment scope, then service-specific error	Granting subscription-wide ownership
Name resolves differently in Azure	DNS and intended endpoint path	Treating token refresh as a network repair
Timeout before service response	Reachability and endpoint configuration	Assuming a role assignment will restore TCP

Official fact: Azure Storage private endpoints use private network connectivity while preserving the usual authorization mechanisms. Clients normally use the standard storage hostname, with DNS directing traffic to the private endpoint. Creating a private endpoint does not automatically disable public access. See Storage private endpoints.

The implication is practical: managed identity does not bypass a storage network restriction, and private connectivity does not grant data authorization. Prove both for the deployed export worker.

What should you say about propagation, token caching, and revocation?

Official fact: Microsoft documents caching-related delays when managed identity group or role membership changes affect issued tokens. It recommends considering direct identity permissions when those membership delays are unsuitable. See managed identity best practices.

Do not promise that restarting the process immediately refreshes every authorization decision. Also do not use “eventual propagation” to excuse an incorrect principal, audience, or scope. Verify the intended configuration first, then apply the service's documented propagation expectations.

For an incident, preserve the assignment change time, identity, scope, and observed error. Define a bounded recheck rather than repeatedly adding and removing permissions. Multiple simultaneous edits destroy the evidence needed to identify which change mattered.

Revocation deserves its own design discussion. If a workload is compromised, consider the host, identity attachment, effective grants, issued credentials, and downstream service controls. Removing one assignment is not a universal guarantee that every cached or already authorized activity stops at that instant.

Official fact: On an Azure VM, code running on the VM can request tokens for identities available there; Microsoft identifies the resource as the security boundary. See VM token guidance. Assigning an identity therefore makes host isolation and code execution privileges part of the access review.

Practice with an explicit success and denial contract

The verified questions below cover adjacent Azure, OAuth, access-control, and storage reasoning. Only the first is explicitly Azure-focused; the follow-ups make their relevance clear without inventing candidate reports about managed identity.

Interview question	Managed identity follow-up
Design an Azure IoT feature	Assign separate hosted identities and downstream operations.
Design an access control system (RBAC + resource-based)	Separate principal, data action, and assignment scope.
Build an OAuth-based data migration client	Explain why a token's audience matters to the destination API.
Design access control and heartbeat systems	Explain credential lifetime and revocation limits.
Design a production file storage service	Verify read success and unnecessary write denial independently.

Continue with Design an Azure IoT feature. Rehearse the export-worker failure using a wrong principal, then a wrong audience, then a missing data role. Name the evidence that distinguishes each case and the smallest justified correction.