What is Azure Managed Identity and Why Should You Care?

What You'll Learn

• What managed identity is and why it exists
• How managed identity eliminates credential storage in code
• The difference between system-assigned and user-assigned identities
• Common mistakes developers make when implementing managed identity

Prerequisites

• An Azure free account (you can create one at azure.microsoft.com)
• Basic understanding of Azure resources like virtual machines and app services
• Familiarity with the concept of authentication and credentials

The Problem: Credentials in Code

Every application needs to access other services. Your web app needs to read from a database. Your function needs to upload files to storage. Your VM needs to pull secrets from a vault.

The traditional way to do this is with credentials - usernames, passwords, connection strings, API keys. And developers often store these directly in code or configuration files.

This creates a security nightmare.

Think of it this way: Storing credentials in code is like writing your house key combination on a sticky note and leaving it on your front door. Anyone who sees your code (or your repository, or your build logs) has access to everything those credentials unlock.

Even if you move credentials to environment variables or configuration files, you still have the same problem. You're just moving the sticky note from the door to under the doormat. The credentials still exist somewhere, and someone has to manage them. Rotate them, secure them, track who has access to them.

This is where managed identity changes everything.

What Managed Identity Actually Does

Managed identity is Azure's solution to the credential problem. Instead of using passwords or keys to authenticate your application, Azure gives your resource its own identity, like an employee badge.

Here's the key concept: Your Azure resource proves who it is just by existing in Azure. No passwords. No keys. No secrets to manage.

The analogy: Instead of giving everyone a copy of the master key (a shared password), each person gets their own employee badge (managed identity) that only opens the doors they need. The badge is tied to the person. When they leave the company, the badge stops working automatically. No one needs to remember to change locks or collect keys.

When you enable managed identity on a resource like a virtual machine or app service, Azure creates a service principal in Microsoft Entra ID (formerly Azure Active Directory). This service principal represents that resource. You then grant that service principal permission to access other Azure resources.

The authentication happens automatically. Your code running on that VM or app service can request a token, and Azure provides it without requiring any credentials in your code. Your application uses that token to access Key Vault, Storage, SQL Database, or any other Azure service that supports managed identity.

No passwords. No connection strings. No credentials stored anywhere.

System-Assigned vs. User-Assigned

Azure offers two types of managed identities, and the difference matters.

System-Assigned Managed Identity

A system-assigned identity is tied to a single Azure resource. When you enable it, Azure creates an identity for that specific VM, app service, or function. When you delete the resource, Azure automatically deletes the identity.

Think of it as: A badge tied to one specific employee. When that employee leaves, the badge is destroyed.

Use system-assigned when:

• You have a single resource that needs access to other services
• You want Azure to manage the identity lifecycle automatically
• Your workload is simple and doesn't need to share identities across resources

User-Assigned Managed Identity

A user-assigned identity is a standalone Azure resource you create independently. You can assign it to multiple VMs, app services, or other resources. The identity continues to exist even if you delete the resources using it.

Think of it as: A shared team badge. Multiple people can use the same badge to access the same set of doors. If one person leaves, the badge still works for everyone else.

Use user-assigned when:

• Multiple resources need the same set of permissions
• You want to manage identity lifecycle independently from your compute resources
• You're using infrastructure-as-code and want to separate identity creation from resource deployment

Microsoft recommends user-assigned identities as the preferred type for most scenarios because they give you more flexibility and control.

How It Works with Key Vault

Key Vault is one of the most common use cases for managed identity. Instead of storing secrets in your application configuration, you store them in Key Vault and grant your managed identity permission to read them.

Here's what happens behind the scenes:

1. You enable managed identity on your app service
2. You assign that identity an RBAC role (like "Key Vault Secrets User") on your Key Vault
3. Your application code requests a secret from Key Vault
4. Azure provides a token to your application automatically (no credentials needed)
5. Key Vault verifies the token and returns the secret

Your code never touches a password. Azure handles the entire authentication process.

The hands-on lab walks you through building this exact scenario step by step. You'll create a Key Vault, enable managed identity, assign permissions, and see it work in a real environment.

Common Mistakes

As you start working with managed identity, watch out for these three common mistakes:

1. Using Connection Strings When Managed Identity Is Available

Many Azure SDKs support managed identity natively. You don't need a connection string anymore. If you're still using DefaultAzureCredential in your code but passing in a connection string, you're doing it wrong. Let the SDK discover the managed identity automatically.

2. Enabling Managed Identity But Forgetting RBAC Roles

Enabling managed identity on a resource doesn't give it any permissions. You must explicitly assign RBAC roles. If your app can't access Key Vault after enabling managed identity, check your role assignments first.

Common roles you'll use:

• Key Vault Secrets User - read secrets from Key Vault
• Storage Blob Data Contributor - read/write blobs in Storage
• Reader - view Azure resources (does not grant data access)

3. Not Understanding the Difference Between System and User-Assigned

If you create a user-assigned identity but assign a system-assigned identity to your resource, they won't work together. Pick one type per resource and stick with it. Most production systems use user-assigned identities for flexibility.

What's Next

You now understand what managed identity is, why it exists, and when to use each type. The next step is to practice building it yourself.

Start with the following lab:

After that, explore RBAC (Role-Based Access Control) in more depth. Understanding Azure roles and scope is critical to securing your cloud resources properly.

This concept maps directly to the AZ-104 (Azure Administrator) exam objectives under "Manage identities and governance in Azure." If you're preparing for certification, this is foundational knowledge you'll see on the exam.