Least-Privilege Identity Strategy: Managed Identities and PIM

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Use managed identities for Azure resources instead of service principals with secrets

  Why this is correct

  Managed identities for Azure resources eliminate the need to store, rotate, or protect service principal secrets because Azure automatically binds the identity to the resource and rotates credentials. You can assign a granular RBAC role, such as Storage Blob Data Reader at a specific resource scope, so the identity cannot exceed its intended permissions. This directly supports least privilege by removing long-lived credential management and enforcing scoped access without human intervention.

• ✗

  Assign the Contributor role at the subscription scope to allow flexibility

  Why it's wrong here

  Assigning Contributor at the subscription scope is the antithesis of least privilege because Contributor permits full management of all resources and resource groups in that subscription, excluding only role assignments. This broad scope would allow a workload or user to modify every virtual machine, storage account, or network configuration, even those unrelated to its function. Least privilege demands a role narrowly scoped to the specific resource group or resource, such as Virtual Machine Contributor on just the target virtual machines, rather than a subscription-wide catch-all.

• ✗

  Use storage account keys for access to blob data

  Why it's wrong here

  Storage account keys are master keys that grant full control over the entire storage account, including all blob containers, tables, queues, and files, regardless of any RBAC assignment. Using these keys for blob access bypasses Microsoft Entra ID identity-based authorization and makes it impossible to grant read-only or container-level permissions to a single consumer. Least privilege for blob data is achieved by using Microsoft Entra ID with a data-plane role like Storage Blob Data Reader, which limits access to the specific containers and operations needed.

• ✓

  Enable Privileged Identity Management (PIM) for just-in-time role assignments

  Why this is correct

  Privileged Identity Management (PIM) enforces just-in-time activation where an eligible user or workload must actively request elevation to a high-privilege role for a limited, time-bound window, and this activation can require approval and produces audit logs. This eliminates permanent standing access to administrative roles such as Contributor or User Access Administrator, reducing the attack surface and ensuring privilege exists only when explicitly needed. PIM is a core component of a least-privilege strategy because it minimizes both the duration and the exposure of elevated permissions.

• ✗

  Use a single service principal for all applications

  Why it's wrong here

  Using a single service principal for all applications creates a shared identity whose effective permissions are the union of every application's requirements, meaning each app inherits more access than it needs. This violates least privilege because any compromise of the one principal would expose all applications and resources, and auditing which app performed which action becomes nearly impossible. Best practice is to create a separate managed identity or service principal per application and assign each only the minimum RBAC role scoped to its exact resource needs.

Go deeper

Related to this question