9.2 Create, Assign & Use Managed Identities

Managed identities in operational depth

Section 9.1 chose managed identity as the default for many Azure workloads. Section 9.2 is the how: create, assign, grant data access, and understand what “no credentials to manage” really means on SC-300.

A managed identity is an Entra service principal that Azure provisions and rotates. Your resource gets an identity; Azure RBAC (and similar) decide what that identity can do. Code asks Azure for a token; Azure hands back an access token for a resource audience such as Key Vault or Storage.

Practice scenarios: /practice/azure-sc-300. Guide home: /study-guides/azure-sc-300.

System-assigned versus user-assigned

Exam cue: if the stem says the identity must remain when a VM is rebuilt, or must be shared by several web apps, choose user-assigned. If the stem says a single Logic App needs its own identity that should disappear with the app, system-assigned is enough.

Both types appear in Microsoft Entra ID as service principals (enterprise applications / managed identities views). You still manage authorization the same way: role assignments on target resources.

Create a system-assigned managed identity

High-level admin steps (UI labels evolve; exam cares about the model):

1. Open the Azure resource (for example Virtual machine, App Service, Function App, Azure Automation account).
2. Open Identity (or equivalent).
3. Under System assigned, set Status to On, save.
4. Azure creates an Entra identity tied to that resource and shows an Object (principal) ID.
5. Use that principal when assigning Azure roles on targets.

CLI conceptual pattern (know the intent, not trivia flags):

• Enable system-assigned identity on the resource.
• Note principalId.
• role assignment create for that principal on the scope of Storage, Key Vault, SQL, etc.

ARM/Bicep/Terraform can set identity: { type: 'SystemAssigned' } so identity is part of infrastructure as code—a common enterprise pattern SC-300 recognizes as good operations hygiene.

Create and assign a user-assigned managed identity

1. Create a user-assigned managed identity in a resource group (name, region).
2. Note its client ID, principal ID, and resource ID.
3. On each compute resource, open Identity > User assigned > Add, select the managed identity.
4. Grant Azure RBAC on target resources to the user-assigned principal (once), not once per app unless scopes differ.
5. In application configuration, when multiple identities exist on one host, specify which user-assigned identity to use (client ID) so token requests are unambiguous.

Multiple identities on one resource: an App Service can have system-assigned and several user-assigned identities. Default token requests may use system-assigned; libraries accept a managed identity client ID for user-assigned selection. Misconfiguration here is a frequent “token works in portal test but app gets 401” troubleshooting story.

Use managed identity to access Azure resources

Token acquisition (conceptual)

Supported Azure hosts expose a local endpoint (for VMs, the Instance Metadata Service at a link-local address) that issues access tokens for the managed identity after Azure validates the caller is that resource. Application code typically uses Azure Identity SDK classes such as DefaultAzureCredential / ManagedIdentityCredential rather than raw HTTP, but SC-300 wants the security model:

1. No client secret in appsettings.json for the MI itself.
2. Token is short-lived; Azure rotates underlying credentials.
3. Token audience must match the target API (for example Key Vault, Storage, Arm).

Azure RBAC on the target

Authentication (who you are) is the managed identity. Authorization is still required:

Classic exam trap: assigning Reader on the Storage account resource allows seeing the account in Azure Resource Manager but does not grant permission to read blob bytes. Data-plane roles are required for many Storage and Key Vault scenarios.

Key Vault pattern (high yield)

1. Enable MI on App Service / Function / VM.
2. On Key Vault, enable Azure RBAC authorization (modern) or access policies (legacy).
3. Assign Key Vault Secrets User (or narrower custom role) to the MI principal at vault or secret scope.
4. App uses Azure SDK with managed identity to call GetSecret.
5. Network rules / private endpoints may still block access even with correct RBAC—identity and network are both required in locked-down designs.

Storage pattern (high yield)

1. Enable MI on the compute resource.
2. Assign Storage Blob Data Contributor (or Reader) to the MI on the storage account or container scope.
3. Use Azure.Storage libraries with token credential from managed identity.
4. Avoid connection strings with account keys when Entra auth is available—keys are secrets you must rotate and protect; MI removes that class of secret for Azure-native access.

“No credential management” — what it does and does not mean

Does mean:

• You do not create a client secret for the managed identity.
• You do not put MI passwords in Key Vault (there is no MI password for you to store).
• Azure handles credential issuance and rotation for the identity.

Does not mean:

• You skip RBAC—without roles, tokens still fail authorization.
• Third-party APIs stop needing their API keys—store those in Key Vault and let MI read Key Vault.
• Every language host auto-authenticates without code changes—you still use SDKs/endpoints correctly.
• Compromise is impossible—if an attacker runs code on the resource, they can request tokens as the MI. Harden the host, use least privilege, and monitor.

Administration, governance, and troubleshooting cues

Where to look in portals:

• Azure resource Identity blade — enable/assign.
• Subscriptions / resource groups / resources → Access control (IAM) — role assignments for the MI.
• Microsoft Entra admin center — enterprise applications / managed identities list for the service principal object.
• Sign-in logs filtered to service principal / managed identity activity when diagnosing auth failures.

Common failure modes:

Infrastructure as code tip: when using system-assigned, role assignments often depend on the principal ID emitted after deployment—order modules so identity exists before RBAC. User-assigned can be created in a platform landing zone first, simplifying app team deployments.

SC-300 scenario drill

• “Enable the web app to read secrets without storing secrets in config” → system- or user-assigned MI + Key Vault Secrets User.
• “Rebuild VMs monthly but keep the same role assignments” → user-assigned MI attached to each new VM.
• “Developer wants to paste a client secret into Function app settings for Azure SQL” → prefer MI + Entra auth to SQL instead.
• “Security asks who can create user-assigned identities” → control with Azure RBAC on the subscription/resource group (Managed Identity Contributor patterns) and landing-zone policy.

Master create/assign/use, then move to service principal fundamentals for non-Azure and app-registration-centric workloads in section 9.3. Enterprise apps and app registrations expand further in the next chapter of /study-guides/azure-sc-300.