# System-assigned managed identity

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/system-assigned-managed-identity

## Quick definition

A system-assigned managed identity is a special kind of identity that Azure gives to a resource like a virtual machine or app. This identity can be used to access other Azure services securely without needing to store passwords or keys. The identity is automatically created and deleted with the resource. It helps developers avoid the risk of hardcoding secrets into code.

## Simple meaning

Think of a system-assigned managed identity as a built-in employee badge for a specific Azure resource, such as a virtual machine or an app. When you create that resource, Azure automatically gives it a unique badge, which is tied to that resource alone. The badge allows the resource to prove who it is to other services, like Azure Key Vault or Azure SQL Database, without ever needing to show a password or a secret key. This is a huge advantage because passwords can be stolen or leaked. In the old way, developers would have to embed connection strings or API keys in configuration files, which was risky. With a system-assigned managed identity, the identity is managed entirely by Azure. You never see or handle the credentials. If you delete the resource, the badge is revoked and destroyed. There is no manual cleanup needed. This makes the security much simpler and reduces the chance of human error. It is like having a temporary pass for a contractor; when the job is done, the pass is automatically invalidated. The identity can be used for authentication to any service that supports Azure Active Directory, which is most Azure services. The resource uses this identity to get a token from Azure AD, then presents that token to the target service to prove it is allowed to access the resource. This token has a short lifespan, so even if it is intercepted, it is useless very quickly. The whole process happens automatically in the background, so the application code only needs to request the token. There is no need to rotate keys or manage certificates. This makes system-assigned managed identities a cornerstone of secure cloud architecture for Azure users.

## Technical definition

A system-assigned managed identity is a service principal of a specific type that is created in Azure Active Directory and is tied exclusively to the lifecycle of an Azure resource. When you enable a system-assigned managed identity on a resource such as a virtual machine, Azure App Service, Azure Functions, or Azure Logic Apps, Azure automatically provisions a service principal in the Azure AD tenant that is associated with the subscription. The service principal is given the same name as the resource. This identity can be assigned roles in Azure RBAC to grant permissions to other resources. The identity is authenticated using certificates that are managed by the Azure platform. The private key never leaves the Azure infrastructure, and the certificates are automatically rotated. The resource communicates with the Azure Instance Metadata Service (IMDS) at a non-routable IP address 169.254.169.254 to obtain an access token for the target service. The token is a signed JSON Web Token (JWT) that contains claims about the identity and the audience. The resource then uses this token as a bearer token in the Authorization header of an HTTP request to the target service. The target service validates the token using the Azure AD public key and the signing keys. This entire flow relies on the OAuth 2.0 protocol. Because the identity is tied to a single resource, it cannot be shared across resources. This makes it ideal for scenarios where a resource needs to access another service with a one-to-one relationship. The system-assigned identity is automatically deleted when the parent resource is deleted, which eliminates orphaned identities. This is in contrast to user-assigned managed identities, which are created as standalone resources and can be assigned to multiple resources. The system-assigned identity is also represented as an object in Azure AD, and you can see it in the enterprise applications list after it is created. However, it cannot be directly managed or deleted independently because its lifecycle is tied to the resource. Under the hood, Azure uses a secure channel to provision the certificate and configure the IMDS endpoint. The certificate is stored in the Azure fabric and is not exposed to the user. The token request to IMDS must include the API version, the resource URI (the audience), and optionally a client ID. For system-assigned managed identity, the client ID is automatically resolved. In exam contexts, knowing that the token is obtained from IMDS and that the identity is tied to the resource lifecycle is critical.

## Real-life example

Imagine you work in a large office building and you need to access a secure supply closet to get printer paper. In the old system, you needed to remember a combination code and type it into a keypad every time. The code was written on a sticky note under your keyboard, and sometimes the code was changed and you didn't know. One day, the sticky note fell off, and anyone could have used it. This is like putting a password in your code or a configuration file. Now, the building installs a new system: each employee gets a unique, electronic ID badge that is automatically linked to their employment. When you walk up to the supply closet door, you tap your badge. The door checks with the central security system, sees that you are still employed, and if you have the right permissions, it unlocks. If you leave the company, your badge is deactivated automatically. You never had to remember a code, and no one could steal your badge because it was always in your pocket. This is exactly how a system-assigned managed identity works. The virtual machine or app is the employee, and the Azure resource it needs to access, like a storage account or a key vault, is the supply closet. The badge is the system-assigned managed identity. When the VM wants to access the storage account, it taps its badge by asking the Azure Instance Metadata Service for a token. The IMDS checks the identity and issues a special time-limited pass, which is the token. The VM presents this token to the storage account. The storage account verifies the token with Azure AD, and if it's valid, access is granted. When the VM is turned off or deleted, the identity badge is automatically destroyed. No one can reuse it. This prevents the security headache of managing passwords and rotating keys.

## Why it matters

System-assigned managed identities matter in practical IT because they solve one of the biggest security problems in cloud computing: credential management. Every day, IT professionals struggle with keeping secrets safe. Hardcoded passwords get leaked. Service principal secrets expire. Certificates need renewal. Managed identities eliminate all of that for a specific resource. When you deploy an application that needs to read from a database or write to a storage account, you no longer need to store a connection string in an app setting or a vault. The application can simply request a token at runtime. This reduces the attack surface significantly. If a developer accidentally commits code to a public repository, there is no secret in the code to be discovered. The automatic rotation of the underlying certificate means that even if some part of the identity infrastructure were compromised, the token is short-lived and the certificate changes frequently. For operations teams, this means less time spent on managing secrets and fewer automated tasks for key rotation. It also ensures that when resources are decommissioned, their identities are cleaned up automatically, which prevents the accumulation of orphaned service principals that can become security holes. In multi-tenant environments, it is crucial that identities are tightly scoped. System-assigned identity gives you that isolation. It is also a requirement for many security compliance frameworks. For example, if you are audited for SOC 2 or ISO 27001, using managed identities demonstrates that you are following best practices for access control. In practice, you will see system-assigned managed identities used in Azure Functions that process data from an event hub and write to a database, or in virtual machines that need to download secrets from Key Vault at startup. Azure also uses system-assigned identities internally for many platform services, which is why it is a fundamental concept to understand.

## Why it matters in exams

For IT certification exams, particularly those related to Microsoft Azure such as AZ-900, AZ-104, AZ-204, AZ-305, and SC-900, understanding system-assigned managed identities is crucial. In the AZ-900 Azure Fundamentals exam, this topic appears under the security, responsibility, and trust section, specifically around identity services. You will be expected to know the difference between a managed identity and a service principal, and when to use a system-assigned versus a user-assigned identity. In the AZ-104 Administrator exam, managed identities appear in the context of securing access to resources. You may be asked to configure a system-assigned managed identity for a virtual machine and grant it access to a storage account. Questions might ask what happens when the VM is deleted. In the AZ-204 Developing Solutions for Azure exam, you will need to know how to obtain an access token programmatically using the Azure.Identity SDK and how to authenticate to services like Azure SQL Database or Key Vault. The exam often includes scenario-based questions where you must choose between system-assigned and user-assigned identities based on whether the identity needs to be shared across multiple resources. In the AZ-305 Designing Microsoft Azure Infrastructure Solutions exam, you will design solutions that use managed identities as a best practice for identity and access management. The SC-900 Security, Compliance, and Identity exam also covers managed identities as part of identity fundamentals. Exam question types typically include multiple-choice, drag-and-drop, and case studies. You may be given a scenario where an application needs to access a storage account without storing a key, and you need to recommend enabling a system-assigned managed identity. Another common question asks what happens to the identity when the resource is deleted. The correct answer is that the identity is automatically deleted. A trap option might say that the identity remains in Azure AD until manually removed. Knowing the lifecycle tie-in is essential. You might be asked about the source of the token. The answer is the Azure Instance Metadata Service (IMDS) endpoint at 169.254.169.254. Not knowing this could cost you points. The exams also test the difference between managed identities and service principals, and when to use an app registration versus a managed identity. In all cases, the correct answer hinges on understanding that system-assigned identity is tied to a single resource and has no separate lifecycle.

## How it appears in exam questions

System-assigned managed identities appear in exam questions in several patterns. The first pattern is scenario-based. You might read about a company that deploys a virtual machine to process payroll data. The application on the VM needs to access an Azure Key Vault to retrieve a database connection string. The developers want to avoid storing credentials in code. The question asks what you should enable on the virtual machine. The answer is a system-assigned managed identity. Then a follow-up question might ask which Azure service is used to obtain the token. The answer is Azure Instance Metadata Service. Another common pattern is troubleshooting. You are told that an application running on Azure App Service fails to authenticate to Azure SQL Database after you enable a system-assigned managed identity and grant it the appropriate role. The question asks what might be missing. The correct answer might be that the connection string in the application is still using SQL authentication instead of Azure AD authentication. Or that the application code is not requesting a token. Another pattern is configuration. You are asked to write a script that assigns a system-assigned managed identity to an existing virtual machine. You need to know the correct Azure PowerShell command or Azure CLI command. For example, for Azure CLI it is 'az vm identity assign --resource-group MyResourceGroup --name MyVm'. A drag-and-drop question might ask you to order the steps: enable managed identity on the resource, assign RBAC role to the identity, request token in code, use token to call target service. A comparison question might list both system-assigned and user-assigned managed identities and ask you to select the correct properties for each. For example, which one is tied to the resource lifecycle? System-assigned. Which one can be assigned to multiple resources? User-assigned. Which one is automatically deleted when the resource is deleted? System-assigned. Some questions test the scope. For instance, you have a virtual machine and a storage account in different regions and different subscriptions. Can a system-assigned managed identity on the VM access the storage account? Yes, as long as the identity has RBAC permissions on the storage account, because identities are within an Azure AD tenant, not a subscription. This is a common trick. Also, you may see questions about the token audience. The resource ID of the target service must be provided when requesting the token. For Azure Storage, the audience is 'https://storage.azure.com'. For Key Vault, it is 'https://vault.azure.net'. Knowing the correct audience for different services is sometimes tested. Finally, an exam question might present a hybrid scenario where an on-premises application needs to use a managed identity. This is not possible directly because managed identities are for Azure resources only. The correct solution would be to use Azure Arc or Azure AD Application Proxy with a service principal. Recognizing these boundaries is important.

## Example scenario

Imagine a company called CloudSales that runs a customer order processing application on an Azure virtual machine. The application needs to write order logs to an Azure Storage account and read customer data from an Azure SQL Database. Currently, the developers have stored the storage account key and the SQL database password in the application's configuration file. The security team is worried that if the virtual machine is compromised, the attacker will steal these credentials. The IT manager decides to use a system-assigned managed identity to eliminate these hardcoded secrets. The steps are as follows. First, the administrator enables the system-assigned managed identity on the virtual machine using the Azure portal or CLI. This takes a few seconds and does not require any downtime. Azure creates a service principal in Azure AD with the same name as the VM. Next, the administrator grants the managed identity the 'Storage Blob Data Contributor' role on the storage account and the 'SQL DB Contributor' role on the SQL database. This is done through Azure RBAC. Now, the developer modifies the application code. Instead of using the storage account key, the code uses the Azure Identity SDK to request a token for the storage audience from the Azure Instance Metadata Service. The SDK handles the protocol and the token request. The token is used as a bearer token in the HTTP requests to the storage account. For the SQL database, the application uses a connection string that specifies 'Active Directory Managed Identity' and then requests a token for the SQL audience. The SQL server validates the token. The application never sees the actual credentials. One day, the virtual machine must be decommissioned because the company upgrades to a newer version. The administrator deletes the VM. The system-assigned managed identity is automatically deleted from Azure AD as well. There are no orphaned secrets or identities to clean up. This scenario shows how system-assigned managed identities provide secure, automatic, and lifecycle-tied authentication for Azure resources.

## Common mistakes

- **Mistake:** Thinking that a system-assigned managed identity can be used by multiple resources at the same time.
  - Why it is wrong: A system-assigned managed identity is exclusively tied to the lifecycle of a single Azure resource. It cannot be shared across multiple virtual machines or app services. For shared scenarios, a user-assigned managed identity is necessary.
  - Fix: If you need the same identity on multiple resources, create a user-assigned managed identity and assign it to each resource.
- **Mistake:** Believing that the managed identity credentials are visible in the Azure portal or can be exported.
  - Why it is wrong: The underlying certificate or secret of a system-assigned managed identity is managed entirely by Azure and is never exposed to the user. You cannot view or copy the secret. The identity is meant to be used only through token requests.
  - Fix: Do not look for a secret to copy. Instead, grant the identity RBAC permissions and use the Azure Identity SDK to request tokens in your code.
- **Mistake:** Assuming that enabling a system-assigned managed identity automatically grants it permissions to access resources.
  - Why it is wrong: Enabling the identity only creates the identity in Azure AD. It does not grant any permissions. You must manually assign Azure RBAC roles to the identity for each target resource it needs to access.
  - Fix: After enabling the identity, go to the target resource's access control (IAM) and assign a role that includes the managed identity as a principal.
- **Mistake:** Confusing the IMDS endpoint with the Azure AD token endpoint.
  - Why it is wrong: The Azure Instance Metadata Service (IMDS) is the endpoint that virtual machines and other resources use to get tokens for managed identities. It is at a non-routable IP address 169.254.169.254. The Azure AD token endpoint is a different public endpoint used by other types of authentication.
  - Fix: For managed identities on Azure VMs, the token request must be sent to the IMDS endpoint, not to login.microsoftonline.com.

## Exam trap

{"trap":"A question says: 'You enable a system-assigned managed identity on a virtual machine. You then delete the virtual machine. What happens to the managed identity in Azure AD?' The trap offers an option: 'The managed identity continues to exist in Azure AD until it is manually deleted.'","why_learners_choose_it":"Learners may think that because managed identities are objects in Azure AD, they persist after the resource is deleted, similar to user-created service principals or app registrations.","how_to_avoid_it":"Remember that a system-assigned managed identity is tightly coupled to the lifecycle of its parent resource. When the parent is deleted, Azure automatically cleans up the identity. There is no manual deletion needed. The identity is destroyed with the resource."}

## Commonly confused with

- **System-assigned managed identity vs User-assigned managed identity:** A user-assigned managed identity is created as a standalone Azure resource and has its own lifecycle independent of any resource. It can be assigned to multiple Azure resources, while a system-assigned managed identity is tied to only one resource and is deleted when that resource is deleted. (Example: If you have 10 virtual machines that all need to access the same Key Vault, use a single user-assigned managed identity and assign it to all 10 VMs. If each VM has unique access needs, use system-assigned identities per VM.)
- **System-assigned managed identity vs Service principal:** A service principal is an identity created manually for an application registration in Azure AD, typically used for server-to-server or client-to-server authentication. It requires manual secret management. A system-assigned managed identity is also a type of service principal, but it is automatically managed by Azure and tied to a resource's lifecycle. (Example: For a third-party application running outside Azure that needs to authenticate, you would create a service principal. For an Azure VM that needs to access a storage account, you would use a system-assigned managed identity.)
- **System-assigned managed identity vs Azure AD application registration:** An Azure AD application registration is an object that defines an application's identity and authentication behavior. It can have multiple secrets and certificates. A system-assigned managed identity is a simpler, resource-specific identity that does not require any manual registration or secret creation. (Example: If you build a custom web API that will be called by other applications, you register it as an app registration. If you have an Azure Function that only needs to authenticate to Azure SQL, you enable a system-assigned managed identity on the Function instead.)

## Step-by-step breakdown

1. **Enable managed identity on the resource** — You use the Azure portal, CLI, or PowerShell to turn on the system-assigned managed identity on a resource like a virtual machine, App Service, or Logic App. Azure immediately creates a service principal in Azure AD for that resource.
2. **Grant permissions to the identity** — You navigate to the target resource (e.g., a storage account or Key Vault) and assign an Azure RBAC role to the managed identity. This defines what the identity can do on that resource, such as read blobs or get secrets.
3. **Application requests a token from IMDS** — When the application on the resource needs to authenticate, it sends an HTTP request to the Azure Instance Metadata Service at 169.254.169.254/metadata/identity/oauth2/token with the API version and the resource URI of the target service.
4. **Azure validates and returns a token** — The IMDS communicates with Azure AD and checks that the resource has a valid managed identity. It then returns a signed JWT access token that is valid for a set period (usually 1 hour).
5. **Application presents the token to the target service** — The application includes the token as a bearer token in the Authorization header of an HTTP request to the target Azure service (e.g., Azure Storage, Key Vault, SQL Database).
6. **Target service validates the token** — The target service verifies the token signature using Azure AD's public key, checks the claims (audience, issuer, expiration), and if valid, allows access for the requested operation.
7. **Identity is automatically deleted when the resource is removed** — When you delete the parent resource, Azure automatically deletes the corresponding managed identity from Azure AD, ensuring no orphaned identities remain.

## Practical mini-lesson

In a real-world Azure environment, system-assigned managed identities are a fundamental tool for building secure cloud applications. As a cloud professional, you need to understand not only how to enable them, but also how to integrate them into the application code. Let's walk through a practical example: securing a connection between an Azure Function and an Azure Cosmos DB database. First, you create the Function App in Azure. In the 'Identity' blade, you set the system-assigned managed identity status to 'On'. Azure immediately creates the service principal. Next, you go to your Cosmos DB account, open the 'Access control (IAM)' blade, and add a role assignment. You choose the built-in 'Cosmos DB Built-in Data Contributor' role, and then select the managed identity by searching for the Function App's name. You assign this role. Now, in the function code, you will use the Azure Identity SDK. For C#, you can create a 'DefaultAzureCredential' instance, which automatically uses the managed identity when running in Azure. You then use that credential to authenticate to the Cosmos DB SDK. You do not need to provide any connection string or key. The SDK requests a token from the IMDS endpoint, gets it, and uses it for authentication. A common issue occurs when developers forget to include the required NuGet package 'Azure.Identity' and 'Microsoft.Azure.Cosmos'. Another issue is that the Function App might not have outbound connectivity to the IMDS endpoint, though this is rare. If you are testing locally, the 'DefaultAzureCredential' will fall back to other credential sources like your local Azure CLI login, which is fine for development. For production, you must ensure the function is deployed to Azure so the managed identity can be used. Another practical aspect is that the managed identity can also be used to authenticate to Key Vault. This is a classic pattern: the application uses its managed identity to get a secret from Key Vault, and then uses that secret to connect to a third-party database. This eliminates storing secrets even temporarily in environment variables. Always remember that the identity must be assigned roles. If the function fails with an authentication error, check the role assignments first. Also, note that system-assigned identities are specific to a region when used with certain services? No, the identity is in Azure AD and is accessible from any region. Finally, monitoring and auditing: you can track the token requests in Azure AD sign-in logs. This helps you understand which resources are using the managed identity and whether they are being used appropriately.

## Memory tip

System-assigned equals single resource lifecycle: created and deleted with the resource. Think 'one resource, one identity, automatic.'

## FAQ

**Can I use a system-assigned managed identity for an on-premises application?**

No, a system-assigned managed identity is only available for Azure resources. For on-premises applications, you would use a service principal or Azure Arc to extend managed identities to hybrid environments.

**How do I grant permissions to a system-assigned managed identity?**

You assign Azure RBAC roles to the managed identity on the target resource. Go to the target resource's Access control (IAM) blade and add a role assignment, selecting the managed identity as the principal.

**Can a system-assigned managed identity be used across different Azure subscriptions?**

Yes, as long as the subscriptions are in the same Azure AD tenant. The managed identity is an Azure AD object, and RBAC permissions can be granted across subscriptions within the same tenant.

**What happens if I enable a system-assigned managed identity on a virtual machine that already has a user-assigned managed identity?**

Both identities can coexist. The virtual machine will have two identities, and the application can request tokens for either one by specifying the appropriate client ID in the token request.

**What is the token lifetime for a system-assigned managed identity?**

The access token is typically valid for 1 hour (configurable by Azure). The token is non-renewable; the application must request a new token from IMDS once it expires.

**Is a system-assigned managed identity free?**

Yes, there is no additional charge for using managed identities. They are a feature of Azure Active Directory and included with your Azure subscription.

**Does the application code need to be modified to use a system-assigned managed identity?**

Yes, the application must use a compatible SDK (like Azure.Identity) to request tokens and use them for authentication. Older applications that rely on connection strings or keys need code changes.

## Summary

System-assigned managed identity is a powerful and secure way for Azure resources to authenticate to other Azure services without managing credentials. It is automatically created by Azure when you enable it on a resource, and it is automatically deleted when the resource is removed. This identity is tied to a single resource, making it ideal for scenarios where each resource has its own identity requirements. In practice, it simplifies development and operations by eliminating the need to store, rotate, and protect secrets. For IT certification exams, you must understand the lifecycle, the token acquisition process through the Azure Instance Metadata Service, the difference from user-assigned identities and service principals, and the need for explicit RBAC role assignments. Common exam traps include thinking the identity persists after resource deletion or that enabling the identity automatically grants permissions. The bottom line for any IT professional is that adopting system-assigned managed identities is a security best practice that reduces risk and aligns with modern cloud-native design principles. On the exam, look for scenarios where an Azure resource must access another Azure service without hardcoded secrets, and remember that the solution is often to enable a system-assigned managed identity.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/system-assigned-managed-identity