This post is a part of the "SC-500: Implementing End-to-End Security Controls for Cloud and AI Workloads" Exam Prep Hub.
This topic falls under these sections:
Manage identity, access, and governance (20–25%)
   --> Secure access to resources by using Microsoft Entra ID
      --> Implement and configure managed identities for Azure resources

Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 4 practice tests with 30 questions each available from the hub's main page below the exam topics section.

Overview

Applications and services running in Azure frequently need to authenticate to other Azure resources. For example:

• An Azure Function needs to read secrets from Azure Key Vault.
• An Azure VM needs to read files from Azure Storage.
• An App Service needs to access Azure SQL Database.
• An Azure Kubernetes workload needs to access Azure resources.
• An Azure application needs to call another service protected by Microsoft Entra ID.

A traditional approach would be to create an application identity and store a credential such as a password, client secret, certificate, or access key in the application configuration.

This creates a security problem: the application now has a credential that must be protected, rotated, monitored, and potentially revoked.

Managed identities for Azure resources provide a way for supported Azure resources to authenticate to Microsoft Entra-protected resources without developers having to manage credentials in application code.

A managed identity is represented in Microsoft Entra ID by a service principal, and Azure manages the underlying credentials. Applications can obtain Microsoft Entra access tokens using the managed identity and then use those tokens to access supported Azure services.

What Is a Managed Identity?

A managed identity is an identity created and managed by Azure that an Azure resource can use to authenticate to other services.

The major benefit is secretless authentication.

Instead of:

Application
    ↓
Client ID + Client Secret
    ↓
Microsoft Entra ID
    ↓
Access Token
    ↓
Azure Resource

a managed identity allows:

Azure Resource
    ↓
Managed Identity
    ↓
Microsoft Entra ID
    ↓
Access Token
    ↓
Azure Resource

The application does not need to store or rotate a client secret.

Managed identities can be used to authenticate to Azure services that support Microsoft Entra authentication. Examples include Azure Storage, Azure Key Vault, Azure SQL, and other Azure services.

Important distinction

A managed identity handles authentication, but it does not automatically grant access to resources.

For example, suppose an Azure VM has a managed identity.

That does not automatically mean the VM can read an Azure Storage account.

You must still authorize the identity.

A common pattern is:

1. Enable or assign the managed identity.
2. Identify the managed identity’s service principal.
3. Assign an appropriate Azure RBAC role to the identity on the target resource.
4. The application obtains an access token through the managed identity.
5. The application uses the token to access the target service.

This distinction between authentication and authorization is extremely important for SC-500.

The Two Types of Managed Identities

Azure provides two types:

1. System-assigned managed identity
2. User-assigned managed identity

Understanding the differences between them is one of the most important areas to know for the exam.

System-Assigned Managed Identity

A system-assigned managed identity is created directly on an Azure resource.

For example:

Azure VM
   |
   └── System-assigned managed identity

Azure creates the identity when you enable the feature on the resource.

The identity’s lifecycle is tied to the resource.

Key characteristics

A system-assigned identity:

• Is associated with a specific Azure resource.
• Can only be associated with that resource.
• Is created when you enable managed identity on the resource.
• Is automatically deleted when the resource is deleted.
• Is useful when the identity should have the same lifecycle as the resource.

For example:

Create VM
   ↓
Enable system-assigned identity
   ↓
Azure creates identity
   ↓
Grant identity access to Key Vault

If the VM is later deleted:

Delete VM
   ↓
System-assigned identity is deleted

This automatic lifecycle management can reduce the possibility of orphaned identities.

When Should You Use a System-Assigned Identity?

System-assigned identities are particularly appropriate when the identity belongs exclusively to one resource.

For example:

A company has one Azure Function App that needs access to one Key Vault. The identity should be removed when the Function App is deleted.

A system-assigned identity is a natural choice.

Another useful scenario is when you want permissions to disappear with the workload.

For example:

Application
     |
     └── System identity
             |
             └── Key Vault access

Deleting the application also deletes its identity.

Exam clue

If a question emphasizes:

• “identity should have the same lifecycle as the resource”
• “identity should be deleted when the resource is deleted”
• “one resource”
• “unique identity per resource”

think:

System-assigned managed identity.

User-Assigned Managed Identity

A user-assigned managed identity is a standalone Azure resource.

Instead of being created automatically as part of another Azure resource, you create the identity separately.

For example:

User-assigned managed identity
          |
          +---- VM 1
          |
          +---- VM 2
          |
          +---- Function App

The same identity can be associated with multiple supported Azure resources.

Its lifecycle is independent of the resources that use it.

When Should You Use a User-Assigned Identity?

User-assigned identities are particularly useful when:

• Multiple resources need the same permissions.
• The identity needs to exist before the resource is deployed.
• Resources are frequently created and deleted.
• You want to manage the identity separately from the resources.
• You want to reuse an identity across multiple Azure resources.

For example, suppose an organization has 20 application servers that all need to read the same Key Vault.

You could create 20 system-assigned identities:

VM 1 → Identity 1 → Key Vault
VM 2 → Identity 2 → Key Vault
VM 3 → Identity 3 → Key Vault
...
VM 20 → Identity 20 → Key Vault

This potentially requires many identity-specific role assignments.

Alternatively, you could create one user-assigned identity:

                    ┌── VM 1
                    |
User-assigned       ├── VM 2
managed identity ───┼── VM 3
                    |
                    └── VM 20
                         |
                         ↓
                     Key Vault

The identity can receive the necessary permissions and then be assigned to the appropriate resources. Microsoft specifically identifies shared-resource scenarios as a strong use case for user-assigned identities.

System-Assigned vs. User-Assigned

The exam shortcut

Think:

System = resource-owned

User = independently managed and reusable

User-Assigned Identity Lifecycle

One of the biggest differences is lifecycle management.

Consider:

User-assigned identity
        |
        +---- VM 1
        +---- VM 2
        +---- VM 3

If VM 1 is deleted:

VM 1 → Deleted
VM 2 → Still using identity
VM 3 → Still using identity
Identity → Still exists

Even if every resource using the identity is eventually deleted, the user-assigned identity itself isn’t automatically deleted.

It must be explicitly managed and deleted when no longer required.

This is an important difference from system-assigned identities.

Managed Identities and Microsoft Entra ID

Managed identities are integrated with Microsoft Entra ID.

Conceptually, the process works like this:

Azure Resource
      |
      | Requests token
      ↓
Managed Identity
      |
      ↓
Microsoft Entra ID
      |
      | Issues access token
      ↓
Application
      |
      | Presents token
      ↓
Target Azure Resource

The managed identity provides the identity used to obtain the Microsoft Entra access token.

The target service then evaluates whether that identity is authorized to perform the requested operation.

Managed identities are implemented through a special type of service principal in Microsoft Entra ID.

Authentication vs. Authorization

This distinction deserves special attention.

Authentication

Authentication answers:

Who are you?

Managed identity provides the application’s identity to Microsoft Entra ID.

Authorization

Authorization answers:

What are you allowed to do?

Azure RBAC or another supported authorization mechanism determines what that identity can access.

For example:

VM
 |
 | Managed identity
 ↓
Microsoft Entra ID
 |
 | "This is VM's identity"
 ↓
Azure Storage
 |
 | RBAC evaluation
 ↓
Storage Blob Data Reader
 |
 ↓
Access granted

Simply enabling a managed identity does not grant it broad access.

Managed Identity and Azure RBAC

Azure RBAC is commonly used to authorize managed identities.

Suppose a Function App needs to read blobs.

You might assign:

Storage Blob Data Reader

to the Function App’s managed identity at the appropriate scope.

The scope could be:

• Management group
• Subscription
• Resource group
• Storage account
• Container, where supported by the authorization model

The principle of least privilege should be applied.

If the application only needs to read blobs, don’t give it:

Storage Blob Data Owner

when a reader role is sufficient.

Principle of Least Privilege

Managed identities should receive only the permissions they actually require.

For example, imagine an application needs to retrieve secrets from Key Vault.

A poor design would be:

Managed Identity
      ↓
Broad subscription-level permissions

A better design is:

Managed Identity
      ↓
Only required Key Vault permissions
      ↓
Specific Key Vault

Microsoft recommends following least privilege when granting permissions to managed identities.

SC-500 exam mindset

When multiple solutions work, prefer the one that:

• Gives the identity fewer permissions.
• Uses the narrowest practical scope.
• Avoids unnecessary secrets.
• Minimizes the identity’s blast radius.

Managed Identity Permissions vs. Permissions to Assign an Identity

There is another important distinction.

There are permissions required to use an identity and permissions required to assign/manage an identity.

For example, assigning a user-assigned managed identity to an Azure resource requires appropriate permissions on both the resource and the identity.

Microsoft documents the Managed Identity Operator role as containing the action needed to assign a user-assigned managed identity to a resource. The Managed Identity Contributor role is used for managing user-assigned identities themselves, such as creating and deleting them.

This can produce exam questions where you must distinguish between:

• Creating a user-assigned identity
• Assigning an identity to a resource
• Giving the identity access to another resource

These are different operations.

Managed Identity Roles to Know

For exam purposes, understand the general purpose of these roles:

Managed Identity Contributor

Used to manage user-assigned managed identities.

Think:

Create/manage the identity itself.

Managed Identity Operator

Used to assign a user-assigned managed identity to supported Azure resources.

Think:

Attach/use the identity on a resource.

Owner / User Access Administrator

Appropriate permissions are required to create or manage Azure RBAC role assignments for the identity on target resources.

Important distinction

Don’t confuse:

Managed Identity Contributor

with:

permissions granted TO the managed identity.

The first concerns management of the identity resource.

The second concerns what the identity can access.

System-Assigned Identity Example

Suppose you have:

• Azure VM named AppVM01
• Azure Storage account named appstorage
• Application running on the VM needs to read blobs.

A possible design is:

Step 1 — Enable system-assigned identity

AppVM01
   |
   └── System-assigned managed identity

Step 2 — Grant access

Assign the appropriate Storage Blob data role to the VM’s managed identity.

For example:

AppVM01 managed identity
          ↓
Storage Blob Data Reader
          ↓
appstorage

Step 3 — Application obtains token

The application uses Azure identity functionality to obtain a Microsoft Entra access token.

Step 4 — Application accesses storage

The token is presented to Azure Storage.

No storage account key needs to be embedded in the application.

User-Assigned Identity Example

Suppose a company has:

• Three Azure Functions
• Two App Services
• Several workloads that all need access to the same Key Vault

Create:

SharedAppIdentity

Then assign it to the required resources:

                 ┌── Function 1
                 |
SharedAppIdentity├── Function 2
                 |
                 ├── Function 3
                 |
                 └── App Service
                         |
                         ↓
                     Key Vault

The identity can be given the minimum required permissions on Key Vault.

This can simplify administration when multiple resources need the same access pattern.

Why Managed Identities Are More Secure Than Stored Secrets

Consider an application that stores a client secret:

Application Configuration
        |
        └── Client Secret

That secret might eventually appear in:

• Configuration files
• Environment variables
• Deployment pipelines
• Source control
• Container images
• Logs
• Developer machines

The secret must also be:

• Rotated
• Protected
• Revoked when compromised
• Monitored

Managed identities eliminate much of this credential-management burden because Azure manages the identity credentials.

This is often described as passwordless or secretless authentication.

Managed Identity Does Not Mean “No Authorization Configuration”

A common exam trap is:

“Enable a managed identity and the application automatically has access to all Azure resources.”

False.

Managed identity provides the identity.

You still need to grant appropriate permissions.

For example:

Managed Identity
       |
       | Authentication
       ↓
Microsoft Entra ID
       |
       | Authorization
       ↓
Azure RBAC
       |
       ↓
Target Resource

Using Managed Identities in Application Code

Azure SDKs can simplify managed identity authentication.

For example, applications using the Azure Identity libraries can use DefaultAzureCredential.

Conceptually:

Application
    ↓
DefaultAzureCredential
    ↓
Managed Identity
    ↓
Microsoft Entra ID
    ↓
Access Token

The application doesn’t need to contain a client secret.

Microsoft recommends managed identities for service-to-service authentication between Azure resources when the services are in the same Microsoft Entra tenant.

Managed Identity Client ID and Principal ID

User-assigned managed identities have identifiers that can be important when configuring applications and permissions.

Two particularly important identifiers are:

Client ID

The client ID identifies the managed identity for token acquisition scenarios.

Principal ID

The principal ID identifies the identity’s service principal in Microsoft Entra ID and is commonly used when assigning permissions.

Microsoft specifically recommends recording the clientId and principalId when creating a user-assigned managed identity.

Exam tip

Don’t automatically assume:

Client ID = Principal ID

They are different identifiers with different purposes.

Managed Identities and Deployment

User-assigned identities can be especially useful in infrastructure-as-code deployments.

For example:

Create managed identity
          ↓
Assign RBAC permissions
          ↓
Deploy application
          ↓
Assign identity to application

Because the user-assigned identity exists independently, it can be created and authorized before the application resource exists.

This can be valuable when the application needs access to another resource during provisioning. Microsoft specifically identifies pre-authorization before resource deployment as a user-assigned identity scenario.

Multiple Managed Identities

Some Azure resources support having:

• One system-assigned identity
• One or more user-assigned identities

This provides additional flexibility.

For example:

                    ┌── User Identity A
                    │       ↓
Azure Application ──┼── User Identity B
                    │       ↓
                    └── System Identity

Different identities can have different permissions.

This can help separate access requirements and reduce the need to give one identity excessive permissions.

Security Considerations

Managed identities significantly reduce credential-management risk, but they are not automatically secure simply because they are “managed.”

The identity itself can become a security boundary.

If an attacker compromises a workload that has a highly privileged managed identity, the attacker may be able to use that identity’s permissions.

Therefore:

Use least privilege

Grant only the permissions required.

Minimize sharing

Don’t use one identity across unrelated applications merely because it is convenient.

Control identity assignment

Only authorized administrators should be able to attach powerful user-assigned identities to workloads.

Monitor permissions

Regularly review role assignments and remove unnecessary access.

Protect the workload

Managed identity doesn’t protect a compromised application. If an attacker can execute code inside a workload, the identity available to that workload may potentially be abused.

Token and Permission-Change Considerations

An advanced point that can appear in security scenarios concerns changes to managed identity permissions.

Managed identity tokens can be cached by the underlying infrastructure. Microsoft notes that authorization changes involving group or role membership can take several hours to take effect because of token caching.

Therefore, don’t assume that removing a role assignment or changing group membership necessarily causes an immediate loss of access.

This is particularly important when designing incident-response procedures.

Choosing Between System-Assigned and User-Assigned

A useful decision framework is:

Choose system-assigned when:

• One resource needs the identity.
• The identity should have the same lifecycle as the resource.
• The identity should be automatically deleted with the resource.
• You want a unique identity for the resource.

Choose user-assigned when:

• Multiple resources need the same identity.
• The identity needs an independent lifecycle.
• The identity needs to exist before the workload.
• Resources are frequently recreated but permissions should remain consistent.
• You want to manage identity creation separately from resource creation.

Microsoft currently recommends user-assigned managed identities for many scenarios, while system-assigned identities remain appropriate when a unique, resource-bound identity is desired.

Exam-Focused Comparison

Key SC-500 Takeaways

Before moving on, make sure you can answer these questions confidently:

1. What problem do managed identities solve?

They provide Azure-managed identities that allow workloads to authenticate to supported services without storing credentials in application code.

2. What are the two types?

System-assigned and user-assigned.

3. What is the most important lifecycle difference?

System-assigned identities follow the lifecycle of their Azure resource.

User-assigned identities have an independent lifecycle.

4. Which identity can be shared?

User-assigned.

5. Does enabling managed identity automatically grant access?

No.

You still need to authorize the identity.

6. What authorization mechanism is commonly used?

Azure RBAC.

7. Which identity should you consider when several resources need the same permissions?

User-assigned managed identity.

8. Which identity is best when the identity should disappear with the resource?

System-assigned managed identity.

9. What is the security advantage over client secrets?

Azure manages the credentials, reducing the need for applications and developers to store and rotate secrets.

10. What principle should govern permissions?

Least privilege.

Practice Exam Questions

Question 1

An Azure Function needs to access an Azure Storage account. The organization wants to eliminate the need to store credentials in the Function App configuration.

Which solution should you implement?

A. Enable a system-assigned managed identity on the Function App and grant it the required Azure RBAC role on the Storage account.

B. Store the Storage account access key in the Function App application settings.

C. Create a shared administrator account and use its password from the Function App.

D. Store a client secret in the Function App source code.

Answer: A

Explanation

A system-assigned managed identity allows the Function App to authenticate without storing credentials. The identity must then be granted the appropriate authorization on the Storage account.

The other options introduce credentials that must be protected and managed.

Question 2

An organization has 25 Azure VMs. All 25 VMs need identical permissions to access an Azure Key Vault. The organization wants to minimize the number of identity-specific role assignments.

Which solution should you recommend?

A. Create a separate system-assigned managed identity for every VM and assign identical permissions to each identity.

B. Create a single service account and distribute its password to all VMs.

C. Create a user-assigned managed identity, grant it the required permissions, and assign it to the VMs.

D. Store the Key Vault secrets in each VM’s local configuration.

Answer: C

Explanation

A user-assigned managed identity can be associated with multiple supported Azure resources. Granting permissions to the shared identity can reduce administrative overhead when multiple resources intentionally require the same access.

The other options either increase management overhead or introduce credential-storage risks.

Question 3

A security administrator requires that an application’s identity be automatically deleted when the Azure resource hosting the application is deleted.

Which type of managed identity should be used?

A. User-assigned managed identity

B. Microsoft Entra user account

C. Service principal with a client secret

D. System-assigned managed identity

Answer: D

Explanation

A system-assigned managed identity has the same lifecycle as its associated Azure resource. When the resource is deleted, the system-assigned identity is also deleted.

A user-assigned identity has an independent lifecycle.

Question 4

A user-assigned managed identity named AppIdentity has been created. An administrator wants to assign AppIdentity to an Azure VM. The administrator does not need to create or delete the identity.

Which type of permission is specifically relevant to assigning the identity to the VM?

A. Managed Identity Operator

B. Managed Identity Contributor

C. Storage Blob Data Owner

D. Key Vault Administrator

Answer: A

Explanation

The Managed Identity Operator role contains the permission needed to assign a user-assigned managed identity to a supported Azure resource. Managed Identity Contributor is associated with managing the user-assigned identity itself.

The storage and Key Vault roles are unrelated to assigning the identity.

Question 5

An application running on an Azure VM has a managed identity. The identity has no RBAC permissions on an Azure Storage account.

What is the most likely result when the application attempts to access data in the Storage account?

A. The managed identity automatically receives Storage Contributor permissions.

B. Azure creates a client secret for the application.

C. The VM automatically receives subscription-level access.

D. The application can authenticate as the VM, but access to the Storage account is denied because the identity has not been authorized.

Explanation

Managed identity provides an identity for authentication. It does not automatically provide authorization to Azure resources.

The identity must receive appropriate permissions, such as an applicable Azure RBAC role.

Answer: D

Question 6

An organization frequently deletes and recreates application instances. Each new instance needs exactly the same permissions to access several Azure resources. The organization wants the identity and its permissions to remain independent of individual application instances.

Which approach is most appropriate?

A. Use a system-assigned managed identity for every application instance.

B. Use a user-assigned managed identity and associate it with the application instances.

C. Store a client secret in each application instance.

D. Use a shared Microsoft Entra user account.

Answer: B

Explanation

A user-assigned managed identity has an independent lifecycle and can be assigned to multiple resources. It is therefore well suited to workloads that are recreated while the identity and its permissions should remain consistent.

Question 7

A security team wants an Azure application to access only the specific Key Vault it requires. The application does not need to manage Key Vaults or access other Azure resources.

Which security principle should guide the RBAC configuration?

A. Principle of least privilege

B. Maximum availability

C. Administrative delegation

D. Credential sharing

Explanation

The application should receive only the permissions necessary to perform its function and preferably at the narrowest appropriate scope.

Answer: A

Question 8

A developer asks why managed identities are preferred over storing a client secret in an application’s configuration.

Which statement best explains the security benefit?

A. Managed identities automatically grant Contributor access to Azure resources.

B. Managed identities eliminate the need for Microsoft Entra ID.

C. Managed identities allow Azure to manage the workload’s identity credentials, reducing the need for applications to store and rotate secrets.

D. Managed identities make authorization unnecessary.

Answer: C

Explanation

Managed identities provide Azure-managed credentials and allow applications to obtain Microsoft Entra tokens without embedding client secrets or other credentials in application code.

They do not eliminate Microsoft Entra ID or authorization.

Question 9

An administrator creates a user-assigned managed identity and wants to configure permissions for that identity to access an Azure resource.

Which identifier is commonly used to identify the identity’s service principal when assigning permissions?

A. Tenant ID

B. Principal ID

C. Subscription ID

D. Resource group ID

Answer: B

Explanation

The principal ID identifies the managed identity’s service principal and is commonly used when configuring permissions. The client ID is another important identifier and is commonly used by applications when identifying the managed identity for token acquisition.

Question 10

A company is designing a new Azure application. The application will run across several Azure resources, and all instances need the same identity and permissions. The identity must also be created and authorized before the application resources are deployed.

Which solution should the security engineer recommend?

A. A separate system-assigned managed identity for each resource

B. A Microsoft Entra user account

C. A service principal with a client secret stored in Azure App Configuration

D. A user-assigned managed identity created and authorized before the application resources are deployed

Answer: D

Explanation

A user-assigned managed identity is an independent Azure resource. It can be created, assigned permissions, and then associated with multiple supported Azure resources. This makes it particularly useful when an identity needs to exist before the workloads that will use it are deployed.

Final Exam Memory Aid

A useful way to remember the entire topic is:

System = Single + Same lifecycle
User = Universal/reusable + Unique lifecycle

And remember the three-step security model:

1. Identity → Who is the workload?
Managed Identity

2. Authentication → Prove the identity
Microsoft Entra ID / access token

3. Authorization → What can it do?
Azure RBAC / appropriate resource permissions

If you understand those three layers—and especially the differences between system-assigned and user-assigned managed identities—you’ll be well positioned for the scenario-based questions covering this SC-500 topic.

Go to the SC-500 Exam Prep Hub main page