Examkin

System-Assigned and User-Assigned Managed Identities

36 questions

All types36Multiple choice17Multiple select9Ordering10
Question 1Question →

You are developing a C# ASP.NET Core web application hosted on an Azure App Service. The App Service is already configured with a system-assigned managed identity to access an Azure SQL Database. You need to configure the App Service to access secrets in an Azure Key Vault. The Key Vault uses Azure Role-Based Access Control (Azure RBAC) for its data plane authorization. To minimize the security blast radius, you must use a user-assigned managed identity for Key Vault access. You must implement the solution using the Azure.Identity SDK and the DefaultAzureCredential class without modifying the initialization parameters of DefaultAzureCredential in your application code. Which sequence of steps should you perform to successfully retrieve the secrets?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence of steps starts with creating the user-assigned managed identity, followed by assigning the Key Vault Secrets User RBAC role to the identity, associating the identity with the App Service, configuring the AZURE_CLIENT_ID app setting with the identity's client ID, and finally deploying the application code that instantiates the SecretClient using DefaultAzureCredential.
The correct sequence ensures that the user-assigned managed identity is first created to obtain its Client ID and Principal ID. Then, the identity is granted the Key Vault Secrets User role on the Key Vault. Next, the identity is linked to the App Service. After linking, the AZURE_CLIENT_ID app setting must be configured on the App Service to ensure that DefaultAzureCredential selects the user-assigned identity instead of the system-assigned identity. Finally, the application code is deployed, using DefaultAzureCredential to retrieve the secrets.

Step-by-Step Solution

1
Provision the user-assigned managed identity.
A Microsoft Entra ID security principal is created, returning a unique Client ID and Principal ID.
The identity must exist before any configuration or permission assignment can refer to it.
2
Assign the Key Vault Secrets User RBAC role to the identity.
The identity is authorized to read secrets from the Key Vault.
Since the Key Vault uses Azure RBAC, the identity requires data plane permissions before code execution.
3
Associate the identity with the App Service.
The App Service is configured to host the user-assigned managed identity.
This allows the App Service's identity endpoint to authenticate requests on behalf of this identity.
4
Configure the AZURE_CLIENT_ID app setting.
The AZURE_CLIENT_ID environment variable is populated on the host container.
Since the App Service has both system-assigned and user-assigned identities, DefaultAzureCredential requires the AZURE_CLIENT_ID environment variable to select the correct user-assigned identity.
5
Instantiate SecretClient with DefaultAzureCredential and deploy the code.
The application successfully authenticates and retrieves the secrets.
The code relies on all previous configuration steps to successfully acquire a token and query the Key Vault.

Key Concept

Configuring user-assigned managed identities alongside system-assigned managed identities using DefaultAzureCredential and Azure RBAC in Azure App Service.
Estimated Time:3m 0s
Question 2Question →

You are developing a web application that will be hosted on an Azure App Service. The application must securely retrieve database connection strings from an Azure Key Vault. You decide to use a managed identity to authenticate to the Key Vault. The identity must be dedicated to this specific App Service instance, and its lifecycle must be tied directly to the App Service so that deleting the App Service automatically deletes the identity. Which identity type should you implement?

Show answer & explanation

Answer: A system-assigned managed identity

Answer

A system-assigned managed identity
A system-assigned managed identity is directly associated with a single Azure resource instance. Enabling it creates an identity in Azure Active Directory (Microsoft Entra ID) that is tied to that resource's lifecycle. When the App Service is deleted, the identity is automatically removed by Azure, fulfilling the scenario's lifecycle requirement without manual management.

Step-by-Step Solution

1
Analyze the lifecycle requirement
The identity's lifecycle must match the App Service lifecycle, deleting when the App Service is deleted.
This requirement determines whether a system-assigned or user-assigned identity is appropriate, as system-assigned identities share their lifecycle with the host resource.
2
Evaluate identity characteristics
System-assigned identities are automatically deleted when the parent resource is deleted. User-assigned identities exist as independent Azure resources and must be manually deleted.
Selecting the system-assigned option satisfies the automatic cleanup and exclusive access requirements.

Key Concept

Managed Identity Lifecycle Boundaries
Question 3Question →

You are designing a deployment architecture for a set of five independent Azure App Service web apps. Each web app must access a shared Azure Key Vault to retrieve common application settings. Each web app is managed and scaled independently, and some may be deleted or recreated during routine updates. You need to configure a managed identity solution that minimizes administrative overhead for granting Key Vault permissions and ensures that the identity credentials persist even if individual web apps are deleted.

Which managed identity configuration should you implement to meet these requirements?

Show answer & explanation

Answer: A single user-assigned managed identity assigned to all five App Services, with that identity granted the necessary access permissions on the Key Vault.

Answer

A single user-assigned managed identity assigned to all five App Services, with that identity granted the necessary access permissions on the Key Vault.
Using a single user-assigned managed identity is the optimal choice because it exists as a standalone Azure resource. It can be shared across multiple Azure App Services, allowing you to configure a single access control rule (RBAC role or Key Vault access policy) on the Key Vault. Additionally, its lifecycle is independent of the App Services; deleting or recreating the web apps does not delete the user-assigned identity, avoiding the need to reconfigure Key Vault permissions.

Step-by-Step Solution

1
Analyze resource sharing and lifecycle requirements.
The identity must support sharing across five App Services to minimize administrative overhead and survive the deletion and recreation of the individual App Service instances.
Identifying these parameters determines whether a system-assigned or user-assigned identity is appropriate.
2
Compare managed identity lifecycles and sharing features.
User-assigned managed identities are standalone resources that can be shared, while system-assigned identities are tied 1-to-1 to a single resource instance's lifecycle.
Selecting a user-assigned managed identity satisfies the independent lifecycle and cross-resource sharing requirements.
3
Determine the required access policy configuration.
Grant Key Vault access explicitly to the selected user-assigned managed identity.
Security credentials provided by managed identities do not have access by default, and access must be explicitly granted on the target resource.

Key Concept

Architectural and lifecycle differences between system-assigned and user-assigned managed identities.
Estimated Time:1m 30s
Question 4Question →

You need to configure an Azure App Service web app to retrieve secrets from an Azure Key Vault by using a user-assigned managed identity. Which sequence of steps should you perform? To answer, arrange the actions in the correct order.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence of steps is: first, create the user-assigned managed identity; second, associate the user-assigned managed identity with the Azure App Service web app; third, assign the role or access policy to the identity on the Key Vault; and fourth, configure the application code to authenticate using the client ID of the user-assigned managed identity.
To successfully authenticate an App Service using a user-assigned managed identity, you must first provision the identity resource. Once created, it must be linked to the web app so the runtime environment can access its credentials. You then grant the identity permissions on the target Key Vault via role-based access control or access policies. Finally, since multiple user-assigned identities can exist on a resource, you must explicitly supply the client ID in your code configuration (e.g., using DefaultAzureCredentialOptions) to specify which identity to use.

Step-by-Step Solution

1
Create the user-assigned managed identity.
A standalone Azure identity resource is provisioned with its own client ID.
Since user-assigned identities exist independently of resources, they must be created before they can be configured or assigned.
2
Associate the identity with the App Service web app.
The App Service web app is configured to use the user-assigned identity.
This allows the host environment of the App Service to present the identity's credentials when requesting tokens.
3
Configure permissions on the Key Vault for the identity.
The identity is authorized to access Key Vault secrets.
By default, identities have no access to Azure resources; authorization must be explicitly granted.
4
Update the web app application code.
The code successfully authenticates and retrieves secrets.
Because multiple user-assigned identities can be associated with a single resource, the code must specify which user-assigned identity to use by providing its client ID to the credential class.

Key Concept

Provisioning, assigning, and authorizing a user-assigned managed identity to access Azure resources.
Estimated Time:1m 0s
Question 5Question →

You are developing a web application that will be hosted on Azure App Service. The application must retrieve secrets from an Azure Key Vault. You decide to use a user-assigned managed identity for authentication. The application code uses the DefaultAzureCredential class from the Azure.Identity library.

You need to configure the Azure resources and the web application to enable secure access.

Which four actions should you perform in sequence? To answer, move the appropriate actions from the list of actions to the answer area and arrange them in the correct order.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

Create a user-assigned managed identity, assign the user-assigned managed identity to the App Service web app, assign the Key Vault Secrets User role to the user-assigned managed identity's service principal, and add the AZURE_CLIENT_ID application setting containing the Client ID of the user-assigned managed identity to the App Service.
To use a user-assigned managed identity with Azure App Service and access Azure Key Vault via the Azure SDK's DefaultAzureCredential, you must first create the identity as an independent Azure resource. Then, you associate the identity with the App Service web app so the hosting environment is aware of it. Next, you assign the necessary RBAC role (Key Vault Secrets User) to the identity's principal ID on the Key Vault. Finally, you set the AZURE_CLIENT_ID application setting on the web app to specify the Client ID of the user-assigned managed identity, which ensures that DefaultAzureCredential selects the correct user-assigned identity for token requests.

Step-by-Step Solution

1
Create a user-assigned managed identity.
A standalone identity resource is provisioned in Azure with its own Client ID and Principal ID.
The identity must exist in Azure before it can be assigned to the web app or granted permissions.
2
Assign the user-assigned managed identity to the App Service web app.
The App Service web app is associated with the user-assigned managed identity.
This configuration allows the App Service infrastructure to obtain tokens on behalf of the identity.
3
Assign the Key Vault Secrets User role to the user-assigned managed identity's service principal.
The identity's service principal is authorized to retrieve secrets from the Key Vault.
The identity must have appropriate RBAC permissions to access the target resource.
4
Add the AZURE_CLIENT_ID application setting containing the Client ID of the user-assigned managed identity to the App Service.
The environment variable AZURE_CLIENT_ID is set in the App Service execution context.
DefaultAzureCredential uses this environment variable to resolve which user-assigned identity to use when multiple identities or a system identity could be present.

Key Concept

Provisioning and configuring a user-assigned managed identity for Azure App Service and Key Vault
Question 6Question →

An enterprise ASP.NET Core application is hosted on an Azure Virtual Machine. The virtual machine has been assigned two user-assigned managed identities: IdentityA (authorized to read secrets from Azure Key Vault) and IdentityB (authorized to write to Azure Storage). To retrieve secrets, the application uses the following C# code:

csharp
var client = new SecretClient(
new Uri("https://myvault.vault.azure.net/"),
new DefaultAzureCredential()
);

When execution occurs on the virtual machine, authentication fails with a CredentialUnavailableException.

Which action must you perform to resolve the authentication failure?

Show answer & explanation

Answer: Configure the DefaultAzureCredential to target IdentityA by passing DefaultAzureCredentialOptions with the ManagedIdentityClientId property set to the client ID of IdentityA.

Answer

Configure the DefaultAzureCredential to target IdentityA by passing DefaultAzureCredentialOptions with the ManagedIdentityClientId property set to the client ID of IdentityA.
The correct action is to configure the DefaultAzureCredential to target IdentityA by passing DefaultAzureCredentialOptions with the ManagedIdentityClientId property set to the client ID of IdentityA. When multiple user-assigned managed identities are assigned to a single Azure resource, the IMDS endpoint requires the client ID to resolve the ambiguity and issue the correct token.

Step-by-Step Solution

1
Analyze the exception context and resource configuration.
The virtual machine is configured with multiple user-assigned managed identities (IdentityA and IdentityB) but the application uses DefaultAzureCredential with default options.
When multiple user-assigned managed identities are assigned to a single resource, the Instance Metadata Service (IMDS) endpoint cannot automatically determine which identity to use.
2
Determine the required client-side configuration for the Azure.Identity SDK.
Identify that ManagedIdentityClientId must be set in DefaultAzureCredentialOptions to specify the target user-assigned identity.
Specifying the client ID tells DefaultAzureCredential to pass the client ID parameter to the IMDS token request, resolving the identity ambiguity.
3
Update the client initialization code.
Initialize SecretClient using the configured DefaultAzureCredential.
This allows the application to successfully authenticate and retrieve secrets from the Key Vault using the permissions of IdentityA.

Key Concept

Handling multiple user-assigned managed identities with DefaultAzureCredential in the Azure SDK
Question 7Question →

You are developing an ASP.NET Core web application hosted on Azure App Service that retrieves database connection strings from Azure Key Vault. The application uses the DefaultAzureCredential class from the Azure.Identity library to authenticate. To meet security requirements, the managed identity must be exclusive to this App Service instance, and its lifecycle must be bound directly to the App Service. You run the command 'az webapp identity assign --name MyWebApp --resource-group MyResourceGroup' to configure the App Service. However, when the web application starts up and attempts to retrieve a secret, a credential retrieval error occurs. Which of the following actions should you perform to resolve this issue?

Show answer & explanation

Answer: Assign the Key Vault Secrets User role to the App Service's system-assigned managed identity at the Key Vault scope.

Answer

Assign the Key Vault Secrets User role to the App Service's system-assigned managed identity at the Key Vault scope.
The correct action is to assign the Key Vault Secrets User role to the App Service's system-assigned managed identity at the Key Vault scope. Running the Azure CLI command enables the system-assigned managed identity on the App Service. However, to access the Key Vault secrets, the identity must be explicitly authorized. The Key Vault Secrets User role provides the necessary data-plane permissions for reading secrets. Using a system-assigned identity satisfies the requirement that the identity's lifecycle is bound directly to the resource.

Step-by-Step Solution

1
Analyze the identity requirements
The requirement states that the identity must be exclusive and its lifecycle bound directly to the App Service, which specifies a system-assigned managed identity.
This helps identify if the command run ('az webapp identity assign') correctly enabled the system-assigned managed identity, which it did.
2
Diagnose the error cause
The identity exists on the App Service but cannot read secrets from the Key Vault, indicating a missing data-plane permission (RBAC role or Key Vault access policy).
Enabling the identity on the host resource only registers it in Microsoft Entra ID; it does not grant permissions to other Azure resources automatically.
3
Determine the correct authorization level
Assign the Key Vault Secrets User role (or equivalent access policy) to the system-assigned managed identity at the Key Vault scope.
This grants the application permission to read secrets (data-plane access) while keeping the lifecycle bound to the App Service.

Key Concept

Authorizing a system-assigned managed identity to access Azure Key Vault secrets using Role-Based Access Control (RBAC).
Question 8Question →

You are configuring security for an Azure Function App that needs to read files from an Azure Storage account. You want to use a managed identity to authenticate. You must determine the characteristics of system-assigned and user-assigned managed identities to choose the best option.

Which of the following statements about these managed identity types are correct? (Select TWO)

Select all that apply

Show answer & explanation

Answer: A system-assigned managed identity is automatically deleted when the associated Azure resource is deleted.; A user-assigned managed identity is created as a standalone Azure resource and its lifecycle is independent of the resources it is assigned to.

Answer

A system-assigned managed identity is automatically deleted when the associated Azure resource is deleted, and a user-assigned managed identity is created as a standalone Azure resource whose lifecycle is independent of the resources it is assigned to.
The correct statements correctly describe the lifecycle boundaries. A system-assigned managed identity is enabled directly on a resource, and deleting that resource automatically deletes the identity. Conversely, a user-assigned managed identity is created as an independent resource in Azure, meaning its lifecycle is separate and it remains in existence even if all resources utilizing it are deleted.

Step-by-Step Solution

1
Analyze the lifecycle characteristics of a system-assigned managed identity.
Confirm that system-assigned identities are tied to the resource lifecycle and deleted when the resource is deleted.
This is a fundamental property of system-assigned managed identities.
2
Analyze the lifecycle and sharing characteristics of a user-assigned managed identity.
Confirm that user-assigned identities are standalone resources, have independent lifecycles, and can be assigned to multiple resources.
This distinguishes user-assigned identities from system-assigned ones.
3
Identify the two correct statements that match these verified characteristics.
The statement about automatic deletion of system-assigned identities and the statement about user-assigned identities being standalone resources with independent lifecycles are selected.
These statements correctly state the properties of managed identities without introducing misconceptions.

Key Concept

Understanding the differences in lifecycle, resource sharing, and configuration properties between system-assigned and user-assigned managed identities in Azure.
Question 9Question →

You are deploying a single Azure App Service web app that needs to retrieve database credentials securely. You want to enable a managed identity for the web app to access Azure Key Vault. The identity must share the lifecycle of the App Service resource, meaning that if the App Service is deleted, the identity is automatically cleaned up. Which identity type or configuration should you implement for the App Service?

Show answer & explanation

Answer: A system-assigned managed identity

Answer

A system-assigned managed identity
A system-assigned managed identity is enabled directly on an Azure resource (such as an App Service). Its lifecycle is bound directly to that resource; when the host resource is deleted, Azure automatically deletes the identity in Microsoft Entra ID. This avoids leaving orphaned identity resources behind and simplifies lifecycle management.

Step-by-Step Solution

1
Analyze the requirements for the identity lifecycle.
The identity must be tied directly to the lifecycle of the App Service and deleted automatically if the App Service is deleted.
This requirement determines whether a system-assigned or user-assigned identity is appropriate.
2
Compare system-assigned and user-assigned managed identity lifecycles.
System-assigned identities are tied to the host resource's lifecycle, while user-assigned identities are standalone resources with independent lifecycles.
System-assigned identities satisfy the requirement of automatic cleanup upon resource deletion.
3
Select the correct configuration option.
Enable a system-assigned managed identity on the App Service.
This aligns exactly with the design goal of automatic lifecycle cleanup.

Key Concept

Managed Identity Lifecycle Management
Question 10Question →

You are designing the security architecture for a C# web application deployed to two distinct Azure App Service instances in different regions (East US and West US) to support active-active high availability. Both App Service instances must retrieve database connection strings from a shared Azure Key Vault and connect to a shared Azure SQL Database without storing credentials in code or configuration files.

The design must satisfy the following security and operational constraints:
- Minimize administrative overhead by avoiding the creation of separate database users and Key Vault access policies/RBAC roles for each regional App Service instance.
- Ensure that if one of the App Service instances is deleted, the identity used to authenticate to the Key Vault and Azure SQL Database remains intact and functional for the remaining instance.
- The application code must use the C# Azure.Identity SDK and instantiate DefaultAzureCredential to authenticate to both services.

Which configuration and code setup should you implement to meet these requirements?

Show answer & explanation

Answer: Create one user-assigned managed identity. In the App Service ARM templates, set the identity.type property to UserAssigned and configure the identity's resource ID in the userAssignedIdentities property. Configure the AZURE_CLIENT_ID application setting on both App Services with the client ID of the user-assigned managed identity, and instantiate DefaultAzureCredential in C# code.

Answer

Create one user-assigned managed identity, configure the App Service ARM templates to use the UserAssigned identity type mapping the resource ID, set the AZURE_CLIENT_ID environment variable on the App Services, and instantiate DefaultAzureCredential in C# code.
The correct option configures a user-assigned managed identity, which operates independently of individual App Service lifecycles and can be shared across regions to minimize permissions management overhead. It correctly sets the identity type to UserAssigned in ARM and configures the AZURE_CLIENT_ID environment variable, which enables DefaultAzureCredential to resolve the identity successfully at runtime.

Step-by-Step Solution

1
Analyze the identity lifecycle and sharing requirements.
A user-assigned managed identity (UAMI) is chosen because it exists as an independent Azure resource and can be assigned to multiple App Service instances, avoiding duplicated database users and policies.
System-assigned identities are tied to a single resource's lifecycle and cannot be shared across multiple resources.
2
Determine the correct ARM template configuration.
Set the identity.type property to UserAssigned and reference the identity's resource ID within the userAssignedIdentities property block.
Setting the type to SystemAssigned or using the principal ID in the configuration block is invalid configuration syntax for user-assigned identities.
3
Configure the App Service environment and C# code.
Add the AZURE_CLIENT_ID application setting containing the client ID of the user-assigned identity to both App Services, and initialize DefaultAzureCredential in C#.
Without the client ID specified via the AZURE_CLIENT_ID environment variable, DefaultAzureCredential will not be able to identify which user-assigned identity to use when requesting tokens.

Key Concept

Selecting and configuring user-assigned managed identities for multi-resource sharing, independent lifecycles, and resolution with DefaultAzureCredential.
Question 11Question →

An organization requires a web application running on Azure App Service to query an Azure SQL Database. The security policy mandates the use of a user-assigned managed identity to eliminate hardcoded credentials. You must perform the configuration steps using the Azure CLI and SQL commands, and configure the .NET application code to connect securely. Which sequence of steps must you perform to provision, configure, and authenticate the application using the user-assigned managed identity?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins with creating the user-assigned managed identity using the CLI. Next, assign this identity to the Azure App Service web app. After that, create a contained user for the identity within the Azure SQL Database and grant the database reader role. Then, configure the App Service app settings by adding the client ID of the user-assigned identity to the client ID environment variable. Finally, write application code using the default Azure credential to connect to the database.
The correct sequence flows logically from infrastructure provisioning to application deployment. The identity must be created first before it can be assigned to the web app or authorized in the SQL Database. The app settings must be updated to reference the client ID before the application code is executed, allowing the default Azure credential to correctly resolve the user-assigned identity at runtime.

Step-by-Step Solution

1
Run `az identity create` to provision the user-assigned managed identity.
A user-assigned managed identity is created in Microsoft Entra ID.
You cannot associate an identity or authorize it in other services until it exists.
2
Run `az webapp identity assign` to link the identity to the App Service web app.
The App Service is configured to use the user-assigned managed identity.
This allows the App Service infrastructure to acquire tokens on behalf of the user-assigned identity.
3
Run SQL DDL commands to create a contained user from the external provider.
The identity is authorized inside the target SQL database.
Managed identities authenticate against Microsoft Entra ID, and SQL Database must map this identity to a contained user to authorize access.
4
Set the `AZURE_CLIENT_ID` application setting on the App Service.
The application runtime environment exposes the client ID to the credential libraries.
Unlike system-assigned identities, user-assigned identities require specifying the client ID. The default Azure credential checks this environment variable to know which user-assigned identity to select.
5
Initialize `DefaultAzureCredential` and establish the database connection.
The application successfully connects to the SQL database using passwordless authentication.
The credential library automatically picks up the client ID environment variable and requests a token for Azure SQL Database from the local endpoint.

Key Concept

Configuring a user-assigned managed identity for App Service to access Azure SQL Database requires identity creation, resource association, target system authorization, runtime client ID configuration, and default SDK credential usage.
Question 12Question →

An administrator deletes an Azure App Service instance that was configured to access an Azure Key Vault. The App Service used a system-assigned managed identity for authentication. What happens to the associated managed identity in Microsoft Entra ID after the App Service is deleted?

Show answer & explanation

Answer: The managed identity is automatically deleted from Microsoft Entra ID.

Answer

The managed identity is automatically deleted from Microsoft Entra ID.
A system-assigned managed identity is enabled directly on an Azure resource instance. Its lifecycle is tied to that resource. Therefore, when the App Service instance is deleted, the identity is automatically cleaned up and deleted from Microsoft Entra ID.

Step-by-Step Solution

1
Identify the type of managed identity configuration being used in the scenario.
The App Service is configured with a system-assigned managed identity.
Managed identity lifecycle characteristics depend on whether the identity is system-assigned or user-assigned.
2
Determine the lifecycle behavior of a system-assigned managed identity upon host resource deletion.
A system-assigned managed identity is tied directly to the lifespan of the Azure resource that hosts it.
Unlike user-assigned identities, system-assigned identities cannot exist independently of their parent resource.
3
Conclude the status of the identity in Microsoft Entra ID.
The identity is automatically deleted from Microsoft Entra ID when the host App Service is deleted.
This cleanup occurs automatically to prevent orphaned identities.

Key Concept

The lifecycle of a system-assigned managed identity is strictly tied to the Azure resource on which it is enabled, meaning it is deleted automatically when the resource is deleted.
Estimated Time:45s
Question 13Question →

You are deploying a C# ASP.NET Core web application to an Azure App Service. The application must retrieve secrets from two distinct Azure Key Vaults:

1. `kv-finance`: Contains highly sensitive financial credentials and must only be accessible by this specific App Service instance. Access must be automatically revoked if the App Service is deleted.
2. `kv-shared`: Contains shared configuration data and is accessed by multiple App Service instances across the resource group.

You have created a user-assigned managed identity named `id-shared` for shared resource access. You need to configure the identities and implement the authentication code using the `Azure.Identity` SDK and `DefaultAzureCredential` class.

Which two configuration steps should you implement to satisfy the requirements? (Select two.)

Select all that apply

Show answer & explanation

Answer: Configure the identity property of the App Service in your ARM template with a type of SystemAssigned, UserAssigned and list the resource ID of id-shared under userAssignedIdentities.; For accessing kv-shared, instantiate the SecretClient using: new SecretClient(new Uri("https://kv-shared.vault.azure.net/"), new DefaultAzureCredential(new DefaultAzureCredentialOptions { ManagedIdentityClientId = "<user-assigned-client-id>" }));

Answer

Configure the App Service identity property in the ARM template using the type 'SystemAssigned, UserAssigned' while listing the resource ID of the user-assigned identity, and instantiate the client for the shared Key Vault by passing DefaultAzureCredentialOptions with the user-assigned identity's client ID.
To satisfy the requirements, the App Service needs to be provisioned with both system-assigned and user-assigned managed identities, which requires setting the ARM identity type to 'SystemAssigned, UserAssigned' and linking the user-assigned identity. In the application code, the default behavior of DefaultAzureCredential is to attempt authentication via the system-assigned managed identity first. To target the user-assigned identity for the shared Key Vault, the client ID of the user-assigned identity must be explicitly configured using DefaultAzureCredentialOptions.

Step-by-Step Solution

1
Determine the lifecycle requirements for both Key Vaults.
The finance Key Vault requires a system-assigned managed identity since its access must be revoked automatically upon resource deletion. The shared Key Vault requires a user-assigned managed identity to facilitate shared access across multiple instances.
This aligns identity selection with resource lifecycle boundaries.
2
Define the identity configuration in the ARM template.
Configure the App Service resource with identity type 'SystemAssigned, UserAssigned' and reference the user-assigned identity's resource ID in the userAssignedIdentities block.
This enables both system-assigned and user-assigned managed identities on the App Service instance.
3
Configure the .NET code for the database-specific Key Vault (kv-finance).
Instantiate the client using 'new DefaultAzureCredential()'.
By default, when no client ID is explicitly provided, DefaultAzureCredential attempts to use the system-assigned managed identity.
4
Configure the .NET code for the shared Key Vault (kv-shared).
Instantiate the client using 'new DefaultAzureCredential(new DefaultAzureCredentialOptions { ManagedIdentityClientId = "<client-id>" })'.
Specifying the client ID targets the user-assigned managed identity, ensuring it does not default to the system-assigned managed identity.

Key Concept

Configuring co-existing system-assigned and user-assigned managed identities and resolving client identities programmatically using DefaultAzureCredential.
Question 14Question →

You are developing an ASP.NET Core web application that will be hosted on two Azure App Service instances: web-app-primary and web-app-secondary. Both web apps must retrieve database connection strings from a shared Azure Key Vault named kv-shared. You decide to use a user-assigned managed identity named id-app-reader to access the Key Vault, ensuring that the identity's lifecycle is independent of the App Service instances. The application code uses the following C# code to authenticate:

csharp
var client = new SecretClient(new Uri("https://kv-shared.vault.azure.net/"), new DefaultAzureCredential());

To implement this security architecture, you assign id-app-reader to both App Service instances and configure the Key Vault access policy. Which of the following configuration steps must you also perform on each App Service instance to ensure that the application successfully authenticates?

Show answer & explanation

Answer: Add an Application Setting named AZURE_CLIENT_ID and set its value to the Client ID of the id-app-reader identity.

Answer

Add an Application Setting named AZURE_CLIENT_ID and set its value to the Client ID of the id-app-reader identity.
The correct action is to add an Application Setting named AZURE_CLIENT_ID and set its value to the Client ID of the id-app-reader identity. When an application uses DefaultAzureCredential and needs to authenticate with a user-assigned managed identity, it reads the AZURE_CLIENT_ID environment variable (which is populated via Application Settings in Azure App Service) to determine which identity to use. The Azure.Identity library expects the Client ID (App ID) of the identity.

Step-by-Step Solution

1
Assign the user-assigned managed identity to both Azure App Service instances.
The identity is linked to the App Service host environment, making it available for token requests.
This establishes the identity configuration at the Azure resource level.
2
Configure the Azure Key Vault access policies or Azure RBAC role assignments for the user-assigned managed identity.
The identity has the necessary permissions (e.g., Get/List Secrets) on the Key Vault.
This authorizes the identity to perform actions on the target resource.
3
Define the AZURE_CLIENT_ID Application Setting on each App Service instance pointing to the Client ID of the user-assigned managed identity.
DefaultAzureCredential reads this setting and uses it to specify the correct client ID during token acquisition.
When multiple identities are present or a user-assigned identity is used, DefaultAzureCredential requires the Client ID to differentiate and request tokens for the target identity.

Key Concept

Configuring DefaultAzureCredential for User-Assigned Managed Identities in Azure App Service
Question 15Question →

You are deploying a set of Azure Virtual Machines (VMs) that need to read configuration files from a shared Azure Storage account. To simplify access control, you want to create a managed identity as a standalone Azure resource that is shared across all the VMs and persists even if all the VMs are deleted. Which value should you specify for the type property in the identity section of the VM's Azure Resource Manager (ARM) template?

Show answer & explanation

Answer: UserAssigned

Answer

The correct property value is UserAssigned.
Setting the identity type to UserAssigned is correct because a user-assigned managed identity is created as a standalone Azure resource. This design allows it to be shared across multiple virtual machines in a scale set and ensures that the identity persists even if individual virtual machines are deleted or scaled down.

Step-by-Step Solution

1
Analyze the requirements to identify if the managed identity needs to be shared across multiple resources and if its lifecycle should be independent of them.
The identity must be shared across multiple virtual machines and persist independently of their lifecycle, indicating that a user-assigned managed identity is required.
System-assigned identities are tied to a single resource's lifecycle and cannot be shared.
2
Identify the corresponding identity type value used in the Azure Resource Manager (ARM) template.
The type value for a user-assigned managed identity is UserAssigned.
This property configures the virtual machine resource to use the specified user-assigned identity resource.

Key Concept

Choosing between system-assigned and user-assigned managed identities based on lifecycle and sharing requirements.
Question 16Question →

You are deploying a web application to Azure App Service using an Azure Resource Manager (ARM) template. The application must retrieve database connection strings from Azure Key Vault. Security requirements specify that the managed identity used by the application must be decoupled from the App Service's lifecycle so it can be shared with an Azure Function in the future, and it must not be deleted if the App Service is removed. Which two of the following configuration steps must you perform to implement this security architecture? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Set the identity property type to UserAssigned in the App Service ARM template, and define the identity under the userAssignedIdentities dictionary.; Run the az role assignment create Azure CLI command to assign the 'Key Vault Secrets User' role to the principal ID of the user-assigned identity at the Key Vault scope.

Answer

To implement this architecture, you must set the identity type to UserAssigned in the App Service resource definition and use Azure CLI to assign the Key Vault Secrets User role to the identity's principal ID.
Configuring a user-assigned managed identity allows the security context to exist independently of the App Service resource, which is required for sharing with the Azure Function and surviving deletion of the App Service. Assigning the Key Vault Secrets User role to the identity's principal ID grants the required permissions without managing secrets.

Step-by-Step Solution

1
Define the managed identity type in the ARM template.
Set the type property to UserAssigned and configure the identity under the userAssignedIdentities dictionary.
This decouples the identity's lifecycle from the App Service, ensuring it is not deleted when the App Service is removed and allowing it to be shared with other resources.
2
Assign RBAC permissions to the identity.
Execute az role assignment create to grant the 'Key Vault Secrets User' role to the identity's principal ID at the Key Vault scope.
This authorizes the identity to retrieve secrets from the Key Vault, fulfilling the application's requirement to access database connection strings.

Key Concept

Selecting and configuring the correct type of managed identity based on resource sharing and lifecycle requirements.
Estimated Time:1m 30s
Question 17Question →

An organization is deploying a C# .NET 8 application to an Azure App Service. The application must perform the following tasks:

1. Retrieve configuration secrets from an Azure Key Vault. The Key Vault is shared across several independent applications, and the credentials used to access it must persist even if this App Service instance is deleted.
2. Read messages from an Azure Service Bus queue. The credentials used for the queue must be exclusively tied to this App Service instance's lifecycle and automatically cleaned up if the App Service is deleted.

The application uses the `Azure.Identity` library and `DefaultAzureCredential` to connect to Azure resources.

Which two actions should you perform to implement this configuration?

Select all that apply

Show answer & explanation

Answer: Enable a system-assigned managed identity on the App Service, assign it the Azure Service Bus Data Receiver role on the Service Bus queue, and instantiate the Service Bus client using a default DefaultAzureCredential instance.; Create a user-assigned managed identity, assign it the Key Vault Secrets User role on the Key Vault, associate it with the App Service, and instantiate the Key Vault client using a DefaultAzureCredential instance initialized with DefaultAzureCredentialOptions containing the identity's client ID.

Answer

To implement this configuration, you should enable a system-assigned managed identity on the App Service for the Service Bus queue, assigning it the Azure Service Bus Data Receiver role and instantiating the Service Bus client using a default DefaultAzureCredential instance. Additionally, you should create a user-assigned managed identity for the Key Vault, assigning it the Key Vault Secrets User role, associating it with the App Service, and instantiating the Key Vault client by passing DefaultAzureCredentialOptions containing the identity's client ID to DefaultAzureCredential.
The correct solution uses a system-assigned managed identity for the Service Bus queue because the identity's lifecycle must be linked to the App Service's lifecycle. It uses a user-assigned managed identity for the Key Vault because the credentials must persist independently of the App Service. When both managed identities are enabled on the App Service, DefaultAzureCredential will default to the system-assigned identity unless explicitly configured. Thus, the Service Bus client can use the default credential parameterless constructor, while the Key Vault client must specify the user-assigned identity's client ID via DefaultAzureCredentialOptions.

Step-by-Step Solution

1
Analyze the identity lifecycle requirements for the shared Key Vault and the exclusive Service Bus queue.
Determine that the Key Vault requires a user-assigned managed identity because the credentials must persist independently of the App Service. Determine that the Service Bus queue requires a system-assigned managed identity because the credentials must be tied to the App Service's lifecycle.
System-assigned identities are tied to the host resource's lifecycle, whereas user-assigned identities exist as independent Azure resources.
2
Determine the appropriate RBAC roles for each resource.
Grant the Key Vault Secrets User role to the user-assigned managed identity on the Key Vault. Grant the Azure Service Bus Data Receiver role to the system-assigned managed identity on the Service Bus queue.
This grants the minimum required permissions to perform the operations securely.
3
Configure the Azure.Identity SDK in code to support both identities.
Instantiate the Service Bus client with a parameterless DefaultAzureCredential. Instantiate the Key Vault client with a DefaultAzureCredential configured with DefaultAzureCredentialOptions containing the user-assigned identity's client ID.
When both system-assigned and user-assigned identities are present, DefaultAzureCredential defaults to using the system-assigned identity. To use the user-assigned identity, its client ID must be explicitly provided in the options.

Key Concept

Selecting and configuring system-assigned and user-assigned managed identities based on resource lifecycle, sharing requirements, and multi-identity SDK configuration.
Question 18Question →

You are developing a C# ASP.NET Core web application deployed to Azure App Service. The application is deployed as two regional instances: app-us-east and app-us-west. Both instances must retrieve shared secrets from a central Azure Key Vault named kv-shared. Additionally, app-us-east must write data to a regional Azure Storage account named sa-east-logs, while app-us-west must write data to sa-west-logs. To configure the managed identities, you perform the following steps:

1. Create a single user-assigned managed identity named uami-shared and assign it to both App Services, granting it Get and List secrets permissions on kv-shared.
2. Enable a system-assigned managed identity on both app-us-east and app-us-west, and grant each regional identity Contributor access to its corresponding regional storage account (sa-east-logs or sa-west-logs).

In your C# code, you instantiate the SDK clients as follows:

csharp
// Accessing the shared Key Vault
var kvClient = new SecretClient(
new Uri("https://kv-shared.vault.azure.net/"),
new DefaultAzureCredential()
);

// Accessing the regional storage account
var blobClient = new BlobServiceClient(
new Uri("https://sa-east-logs.blob.core.windows.net/"),
new DefaultAzureCredential()
);

What is the authentication outcome when the app-us-east instance attempts to run this code and connect to both services?

Show answer & explanation

Answer: The application successfully connects to the regional storage account, but fails to authenticate to the shared Key Vault because DefaultAzureCredential defaults to the system-assigned managed identity when both identity types are enabled, causing token requests without a specified client ID to use the system-assigned identity.

Answer

The application successfully connects to the regional storage account, but fails to authenticate to the shared Key Vault because DefaultAzureCredential defaults to the system-assigned managed identity when both identity types are enabled, causing token requests without a specified client ID to use the system-assigned identity.
The correct option is correct because when an Azure App Service has both a system-assigned managed identity and a user-assigned managed identity, the metadata service defaults to issuing tokens for the system-assigned managed identity. Because DefaultAzureCredential is initialized without parameters, it requests a default token, which will represent the system-assigned identity. Consequently, the call to the regional storage account succeeds (authorized for the system-assigned identity), while the call to the shared Key Vault fails (authorized only for the user-assigned identity). To fix this, DefaultAzureCredential must be configured with DefaultAzureCredentialOptions specifying the ManagedIdentityClientId for the user-assigned identity.

Step-by-Step Solution

1
Determine the identities assigned to the App Service host.
The host app-us-east has both a system-assigned managed identity (with permissions to sa-east-logs) and a user-assigned managed identity (uami-shared with permissions to kv-shared).
This establishes the authorization scope for each identity type on the resource.
2
Analyze how DefaultAzureCredential resolves tokens when multiple managed identities are present.
Without specifying a client ID, DefaultAzureCredential calls the IMDS token endpoint without parameters, which causes Azure to default to using the system-assigned managed identity.
This identifies which security principal's token is returned during execution.
3
Evaluate the authentication outcome for each service request.
The token for the system-assigned identity successfully accesses sa-east-logs (due to Contributor RBAC) but fails to access kv-shared (as only uami-shared has permissions there).
This determines the final success/failure behavior of the C# code.

Key Concept

Understanding the default resolution behavior of DefaultAzureCredential and the Azure Instance Metadata Service (IMDS) when both system-assigned and user-assigned managed identities are assigned to a single resource.
Question 19Question →

You are developing a web application hosted on an Azure App Service. The application must retrieve database connection strings securely from an Azure Key Vault using a system-assigned managed identity.

Which three actions should you perform in sequence to configure this security access? To answer, drag the appropriate actions from the list of actions to the answer area and arrange them in the correct order.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

First, enable the system-assigned managed identity on the Azure App Service instance. Next, assign the Key Vault Secrets User role to the App Service's managed identity at the Key Vault scope. Finally, configure the web application code to authenticate using the DefaultAzureCredential class and retrieve the secret.
To grant an App Service access to Key Vault via managed identity: 1) Enable the system-assigned identity on the App Service, creating the principal. 2) Grant that principal permissions via Key Vault Secrets User role assignment. 3) Configure application code using DefaultAzureCredential to automatically pick up the identity environment and authorize calls.

Step-by-Step Solution

1
Enable the system-assigned managed identity on the Azure App Service.
Azure creates a service principal in Microsoft Entra ID linked directly to the lifecycle of the App Service.
Before permissions can be granted or authentication can happen, the managed identity must be enabled to generate its identity principal.
2
Assign the Key Vault Secrets User role to the managed identity.
The identity is authorized to read secrets from the Key Vault.
Having an identity is not enough; the resource owner must grant it the necessary Role-Based Access Control (RBAC) permissions to access the secrets.
3
Update application code to use DefaultAzureCredential.
The application successfully retrieves secrets at runtime without hardcoded credentials.
DefaultAzureCredential automatically detects the system-assigned managed identity in the App Service environment and uses it to request tokens.

Key Concept

Configuring a system-assigned managed identity to access Azure Key Vault securely.
Question 20Question →

You are developing an ASP.NET Core web application that will be hosted on an Azure App Service. The application must securely read blobs from an Azure Storage container. You decide to use a user-assigned managed identity to handle authentication.

Which sequence of steps should you perform to provision, configure, and utilize the user-assigned managed identity to access the storage container?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence is to first create the user-assigned managed identity, then associate it with the Azure App Service instance, then assign the Storage Blob Data Reader RBAC role to the identity at the storage container scope, and finally instantiate the DefaultAzureCredential class in the application code by passing the Client ID of the identity to the constructor options.
The correct sequence begins with provisioning the user-assigned managed identity. Once created, the identity is linked to the App Service hosting environment. Next, the identity is granted the Storage Blob Data Reader role to authorize access. Finally, the application code initiates authentication using DefaultAzureCredential configured with the identity's Client ID.

Step-by-Step Solution

1
Create the user-assigned managed identity resource.
A standalone user-assigned managed identity resource is created with its own Client ID and Principal ID.
The identity must exist in Microsoft Entra ID before it can be associated with hosts or granted access permissions.
2
Associate the user-assigned managed identity with the App Service.
The identity is linked to the App Service host instance, permitting it to request tokens for this identity.
The hosting platform must be aware of the identity to expose its credentials through the local metadata endpoint.
3
Create an RBAC role assignment for the identity on the Storage account.
The identity is granted the Storage Blob Data Reader role at the container or storage account scope.
The identity needs explicit authorization to perform data plane operations on the Azure Storage resource.
4
Configure the application code to use the identity client ID.
The application code uses DefaultAzureCredential with the specific Client ID to request a token and read blobs.
Without the client ID, DefaultAzureCredential will default to a system-assigned managed identity and fail since only a user-assigned identity is associated.

Key Concept

Provisioning and configuring a user-assigned managed identity for Azure App Service authorization
Page 1 / 2Next