2.1.6. Managed Identities for Azure Resources
💡 First Principle: Any credential stored in code or configuration is a credential that can leak — in a repo, a config file, a log. A managed identity removes that risk category entirely by letting an Azure resource authenticate to Entra ID without any credential a developer ever has to see, store, or rotate.
System-assigned managed identities are tied to the lifecycle of a single resource (created and deleted with it) — simple, but not reusable elsewhere. User-assigned managed identities exist as standalone resources that can be attached to multiple Azure resources at once and outlive any single resource's lifecycle — useful when several resources need the same identity and permission set.
| Type | Lifecycle | Reusable Across Resources? |
|---|---|---|
| System-assigned | Tied to the resource; deleted when the resource is deleted | No — one-to-one |
| User-assigned | Independent Azure resource; managed separately | Yes — one-to-many |
⚠️ Exam Trap: "Almost every connection string in a scenario question is a wrong-answer signal." If a described architecture has an Azure Function connecting to Key Vault or Storage using a stored connection string or access key, the more secure — and usually correct — answer is to replace it with a managed identity and Azure RBAC, not to just "rotate the key more often."
Reflection Question: Two Azure Functions and a Logic App all need the same read access to a shared Key Vault. Would a system-assigned or user-assigned managed identity fit that requirement better, and why?
