Examkin

Implement Azure Security

203 questions

All types203Multiple choice102Multiple select71Ordering30
Question 181Question →

When implementing authentication and authorization in Microsoft Entra ID, developers must understand the relationships between different identity objects. Which two of the following statements correctly describe the characteristics or roles of application objects and service principals?

Select all that apply

Show answer & explanation

Answer: The application object serves as the global definition of the application and remains in the tenant where the application was registered.; A service principal is the local representation of the application object in a specific tenant and is used to define access policies and permissions.

Answer

The correct statements are that the application object serves as the global definition of the application and remains in the tenant where the application was registered, and a service principal is the local representation of the application object in a specific tenant used to define access policies and permissions.
The statement about the application object serving as the global definition in the home tenant is correct because the application object defines the application's configuration globally. The statement about the service principal being the local instance is correct because the service principal acts as the security identity (instance) in each tenant to enforce access policies.

Step-by-Step Solution

1
Analyze the relationship between application objects and service principals.
Identify that the application object is the global definition of the app, while the service principal is the concrete local instance (identity) created in a tenant to manage access.
This establishes the fundamental distinction between application objects and service principals in Microsoft Entra ID.
2
Evaluate the statements regarding managed identities.
Determine that managed identities (system-assigned or user-assigned) are restricted to Azure resources and cannot be assigned to on-premises applications, nor are they automatically created during standard application registration.
This rules out incorrect options that confuse service principals with managed identities.

Key Concept

The relationship and differences between application objects, service principals, and managed identities in Microsoft Entra ID.
Question 182Question →

You are developing a custom script that runs on an on-premises server to automate resource provisioning in Azure. The script must authenticate programmatically with Microsoft Entra ID using a dedicated service principal associated with an application registration. Which of the following credential types can be configured directly on the application registration to enable this authentication? (Select TWO)

Select all that apply

Show answer & explanation

Answer: A client secret (symmetric key) created under the Certificates & secrets settings; An uploaded public certificate (asymmetric key) under the Certificates & secrets settings

Answer

A client secret (symmetric key) created under the Certificates & secrets settings and an uploaded public certificate (asymmetric key) under the Certificates & secrets settings.
Microsoft Entra ID application registrations support two credential types for authenticating a service principal: client secrets (symmetric keys) and certificates (asymmetric keys). Client secrets act as passwords, while certificates allow using cryptography by uploading a public key (.cer, .pem, etc.), which is more secure for production daemon applications or scripts.

Step-by-Step Solution

1
Identify the authentication requirements for the on-premises automation script using a Microsoft Entra ID application registration.
The script requires credentials to authenticate as a service principal.
On-premises resources cannot use Azure-managed identities directly and must use standard credentials associated with the app registration.
2
Evaluate the valid credential options available under the application registration settings in Microsoft Entra ID.
Microsoft Entra ID allows configuring either client secrets (symmetric keys) or uploading public certificates (asymmetric keys).
These are the two primary mechanisms to authenticate an application registration's service principal.
3
Select the correct options based on the evaluation.
Client secrets and public certificates are the correct choices.
Managed identities and Shared Access Signatures are distinct Azure features that do not serve as direct credentials on an application registration.

Key Concept

Microsoft Entra application registrations support two primary types of credentials for service principal authentication: client secrets and certificates.
Question 183Question →

You are developing an ASP.NET Core web application that will authenticate users using the Microsoft Identity Platform and then call a downstream web API. You need to configure Microsoft Entra ID and the application to enable this confidential client authentication scenario. Which two configuration steps are required? (Select two.)

Select all that apply

Show answer & explanation

Answer: Configure the Redirect URI in the Microsoft Entra ID app registration to match the application's sign-in callback endpoint.; Generate a client secret or upload a certificate in the Microsoft Entra ID app registration for the application to authenticate itself.

Answer

To configure a web application that authenticates users and calls a downstream web API (confidential client flow), you must configure the Redirect URI in the Microsoft Entra ID app registration and generate a client secret or certificate in the app registration to allow the confidential client to authenticate during token exchange.
For a web application that authenticates users and calls a downstream web API (confidential client), you must configure: 1) the Redirect URI so the user agent is returned to the correct endpoint after authentication, and 2) a client secret or certificate to authenticate the web app when it exchanges the authorization code for an access token. The options specifying Redirect URI configuration and generating a client secret/certificate are correct.

Step-by-Step Solution

1
Create an application registration in the Microsoft Entra admin center.
The application obtains a client ID and tenant ID required for configuring the MSAL client.
This establishes the identity of the web application in Microsoft Entra ID.
2
Add a Redirect URI of type 'Web' matching the local application URL (e.g., https://localhost:5001/signin-oidc).
Microsoft Entra ID is allowed to send the authorization code to the specified application endpoint.
Redirect URIs prevent tokens from being redirected to unauthorized endpoints.
3
Generate a client secret under the Certificates & Secrets blade of the registration.
The web app can use this secret credential to prove its identity during code exchange.
Confidential client applications must authenticate themselves when requesting access tokens using the authorization code flow.

Key Concept

Confidential Client Application configuration in Microsoft Identity Platform authentication
Estimated Time:1m 0s
Question 184Question →

An organization is deploying a C# background service that runs on an on-premises Windows server. The service must periodically query Microsoft Graph using its own credentials, authenticated by a client certificate. Which MSAL.NET builder class must you use to instantiate the client application?

Show answer & explanation

Answer: ConfidentialClientApplicationBuilder

Answer

ConfidentialClientApplicationBuilder
The correct answer is ConfidentialClientApplicationBuilder because daemon applications running on secure servers can maintain client credentials securely. In MSAL.NET, these applications are instantiated using the ConfidentialClientApplicationBuilder class.

Step-by-Step Solution

1
Analyze the application requirements.
The application is a background service (daemon) running on-premises and needs to authenticate using its own credentials (client certificate) without user intervention.
Identifying the client application type determines the correct MSAL.NET class to use.
2
Determine the client type classification.
Since the app runs on a secure server and can maintain the confidentiality of its certificate, it is classified as a confidential client application.
MSAL.NET separates public clients (desktop/mobile/CLI) from confidential clients (daemons/web APIs/web apps).
3
Select the correct MSAL.NET builder.
Use ConfidentialClientApplicationBuilder to instantiate the client.
ConfidentialClientApplicationBuilder provides the methods needed to configure confidential client credentials like client secrets and certificates.

Key Concept

MSAL.NET Client Application Types
Question 185Question →

A developer is configuring a C# console application that will run on a user's workstation. The application must authenticate the user using the Microsoft Identity Platform to retrieve their profile from Microsoft Graph. Which two components must be configured to support this authentication flow? (Select two)

Select all that apply

Show answer & explanation

Answer: An instance of IPublicClientApplication initialized using the Microsoft Authentication Library (MSAL); Delegated permissions for the Microsoft Graph API configured in the Microsoft Entra ID application registration

Answer

The correct configurations are initializing an instance of IPublicClientApplication using the Microsoft Authentication Library (MSAL) and configuring delegated permissions for the Microsoft Graph API.
The C# console application runs on a local workstation and is a public client, meaning it cannot securely store secrets. Therefore, it requires the IPublicClientApplication interface from MSAL to acquire tokens. Since the application accesses Microsoft Graph on behalf of the signed-in user, delegated permissions must be configured in Microsoft Entra ID.

Step-by-Step Solution

1
Determine the application client type.
Since the console app runs on a user's workstation and cannot secure a client secret, it is classified as a public client.
This dictates that MSAL's IPublicClientApplication should be used instead of IConfidentialClientApplication.
2
Identify the permission type required for user-bound operations.
Delegated permissions are selected because the application acts on behalf of the logged-in user.
Application permissions are only for services running without user interaction.

Key Concept

Public client authentication flow using MSAL and delegated permissions
Question 186Question →

You are developing a client-side React single-page application (SPA) that will run in users' web browsers. The application must authenticate users against Microsoft Entra ID and access a secure downstream web API. You need to configure the authentication and identity settings for the React application. Which configuration should you implement in Microsoft Entra ID?

Show answer & explanation

Answer: Register the application in Microsoft Entra ID, configure a redirect URI with the Single-page application (SPA) platform type, and use the authorization code flow with PKCE.

Answer

Register the application in Microsoft Entra ID, configure a redirect URI with the Single-page application (SPA) platform type, and use the authorization code flow with PKCE.
The correct option is to register the application in Microsoft Entra ID with the platform type set to Single-page application (SPA) and use the authorization code flow with PKCE. Because the React app runs in the user's browser, it is a public client and cannot secure a client secret. PKCE eliminates the need for a client secret while protecting the flow against authorization code interception attacks. Furthermore, registering as an SPA enables the necessary CORS support on Entra ID token endpoints.

Step-by-Step Solution

1
Analyze the client application architecture.
The application is a client-side React Single-Page Application (SPA) running entirely in the user's web browser.
Understanding the execution environment is crucial to determine if the client is public (cannot protect secrets) or confidential (can protect secrets).
2
Determine the appropriate authentication flow.
The Authorization Code Flow with Proof Key for Code Exchange (PKCE) is the standard and secure flow for client-side applications.
PKCE protects the authorization code from interception without requiring a client secret.
3
Configure the platform type in Microsoft Entra ID App Registration.
Register the Redirect URI under the Single-page application (SPA) platform type.
The SPA platform type ensures Microsoft Entra ID issues tokens using the authorization code flow with PKCE and supports the required Cross-Origin Resource Sharing (CORS) headers.

Key Concept

Selecting the correct platform registration and authentication flow in Microsoft Entra ID for public client applications.
Question 187Question →

You are developing a background daemon service named ConfigSync that runs as a containerized application in Azure Container Instances. The service must periodically query Microsoft Graph to read tenant group memberships to synchronize configurations. No user is signed in when the service runs.

You register the application in Microsoft Entra ID. You need to configure the API permissions for the application registration while adhering to the principle of least privilege.

Which configuration should you implement?

Show answer & explanation

Answer: Add Microsoft Graph Application permissions for GroupMember.Read.All, and have a global administrator grant admin consent.

Answer

Add Microsoft Graph Application permissions for GroupMember.Read.All, and have a global administrator grant admin consent.
The service runs as a background daemon without any user signed in, which dictates the use of the client credentials flow and Microsoft Graph Application permissions. To follow the principle of least privilege, GroupMember.Read.All should be chosen over Group.Read.All because it limits access strictly to reading memberships rather than full group properties. Application permissions always require a global administrator to grant admin consent.

Step-by-Step Solution

1
Determine the application type and interaction model.
Since the ConfigSync service runs as a background daemon with no user signed in, it must use the client credentials flow which requires Application permissions rather than Delegated permissions.
Delegated permissions require a signed-in user to act on behalf of, whereas Application permissions are used by applications that run without a signed-in user.
2
Select the permission scope adhering to the principle of least privilege.
Select GroupMember.Read.All instead of Group.Read.All.
GroupMember.Read.All is more restricted as it only allows reading group memberships and basic member profiles, whereas Group.Read.All allows reading all group properties and settings.
3
Determine the consent requirement.
A global administrator must grant admin consent for the tenant.
Application permissions always require administrator consent before they can be used by the application.

Key Concept

Microsoft Entra ID Application permissions and Client Credentials flow for background daemon services
Question 188Question →

You are configuring a daemon application (App1) to call a custom Web API (API1) programmatically. Both applications are registered in Microsoft Entra ID. You need to configure API1 to expose an application permission, assign that permission to App1, and ensure App1 can successfully request an access token. Which four actions should you perform in sequence?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To configure the daemon application (App1) to call the Web API (API1) programmatically, you must first create the App Role (Application type) in the API1 registration. Next, add this App Role under the API permissions of the App1 registration. After that, grant tenant-wide admin consent for the permission in App1. Finally, request an access token in the App1 application code using the Client Credentials flow.
The correct sequence starts with defining the App Role on the target API (API1) because a permission must exist before it can be assigned. Next, the client application (App1) must request this permission by adding it to its registration. After the permission is registered, a tenant administrator must grant consent. Finally, with the permission consented, the client application can execute its code to request the access token using the client credentials flow.

Step-by-Step Solution

1
In the API1 registration, create an App Role with the allowed member types set to Applications.
The custom Web API exposes an application permission that other service principals can request.
A permission role must be declared on the target API resource before any client applications can reference or request it.
2
In the App1 registration, add the defined App Role of API1 under API permissions.
App1 declares a dependency on the API1 application permission.
The client application registration must explicitly declare which permissions it requires to access target resources.
3
In the App1 registration, select Grant admin consent to authorize the added permission.
The application permission is approved for use within the directory tenant.
Application permissions (App Roles) cannot be consented to by regular users and must be granted tenant-wide by an administrator before tokens can be issued.
4
In the App1 application code, request an access token using the Client Credentials flow.
The application receives an access token containing the role claims necessary to call the Web API.
With consent granted, the daemon application can now authenticate and request a token representing its own identity.

Key Concept

Configuring application permissions and client credentials authentication flow in Microsoft Entra ID.
Estimated Time:2m 0s
Question 189Question →

You are deploying an Azure App Service web application that must retrieve a database connection string from an Azure Key Vault without modifying the application code. You plan to configure an application setting in App Service to reference the Key Vault secret directly. The secret is located at the URI: https://contosovault.vault.azure.net/secrets/dbconn/f3b890. Which syntax format must you use for the App Service application setting value to reference this secret?

Show answer & explanation

Answer: @Microsoft.KeyVault(SecretUri=https://contosovault.vault.azure.net/secrets/dbconn/f3b890)

Answer

The syntax prefixing the secret's URI with @Microsoft.KeyVault(SecretUri=...) is correct.
The correct answer is the syntax prefixing the URI with @Microsoft.KeyVault(SecretUri=...). When App Service detects this pattern, it resolves the secret from Key Vault on behalf of the application using the application's managed identity.

Step-by-Step Solution

1
Identify the requirement to resolve an Azure Key Vault secret inside an App Service configuration setting.
The App Service must use the Key Vault reference syntax to intercept the environment variable loading and fetch the secret value.
This allows the application to retrieve secrets dynamically without requiring custom Key Vault SDK integration.
2
Select the correct provider prefix and parameter for the reference.
The provider prefix must be '@Microsoft.KeyVault' and the parameter must be 'SecretUri'.
The App Service runtime specifically parses '@Microsoft.KeyVault' and expects 'SecretUri' as the parameter containing the full secret URL.

Key Concept

Azure Key Vault Reference Syntax in App Service
Question 190Question →

You are developing a secure C# .NET console application that uses the `Azure.Security.KeyVault.Certificates` SDK. The application must provision a new SSL/TLS certificate inside Azure Key Vault. Your organization requires that the certificate be signed by an internal corporate Certificate Authority (CA) that is not integrated with Azure Key Vault. You need to complete the process of generating the certificate while keeping the private key secure within the key vault. Arrange the steps in the correct order to configure, sign, and complete the certificate creation process.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

First, start the certificate creation process using a policy with the issuer specified as 'Unknown'. Second, retrieve the pending certificate operation to extract the generated Certificate Signing Request (CSR). Third, submit the CSR to the non-integrated Certificate Authority to obtain the signed certificate. Finally, merge the signed certificate back into Azure Key Vault using the certificate client to complete the operation.
The correct sequence starts with initiating the request in Key Vault using 'Unknown' as the issuer, which forces the key vault to generate the private key and prepare a pending operation. Next, the pending operation is queried to extract the CSR. Then, the CSR is signed by the external CA. Finally, the signed certificate is merged back into Key Vault to associate it with the private key and activate the certificate resource.

Step-by-Step Solution

1
Initiate the creation request using `CertificateClient.StartCreateCertificateAsync` with a policy where `IssuerName` is set to "Unknown".
A pending `CertificateOperation` is created inside Azure Key Vault, and the private key is generated within the vault.
Azure Key Vault must generate the public/private key pair and create a CSR. Setting the issuer to "Unknown" is required for non-integrated CAs.
2
Query the key vault to retrieve the active `CertificateOperation` and extract the CSR from its properties.
The base64-encoded CSR string is retrieved.
The CSR is needed so that the external CA can sign it, confirming the identity and public key details.
3
Submit the CSR to the external CA and download the signed certificate chain.
The signed X.509 certificate file containing the certificate chain.
The external CA acts as the trust anchor and signs the public key provided in the CSR.
4
Call `CertificateClient.MergeCertificateAsync` to import the signed certificate.
The certificate operation is completed, and the active certificate is now available in Azure Key Vault.
Merging associates the signed certificate with the private key that remained securely inside Key Vault, finalizing the enrollment lifecycle.

Key Concept

Azure Key Vault Certificate Enrollment with Non-Integrated Certificate Authorities
Question 191Question →

An organization is transitioning its Azure resources to use Azure Role-Based Access Control (RBAC) instead of Key Vault access policies. A developer needs to ensure that an Azure Web App can retrieve secrets from a Key Vault named kv-prod using its system-assigned managed identity.

Which configuration change must be performed to allow the Web App to retrieve the secrets?

Show answer & explanation

Answer: Set the Key Vault permission model to Azure RBAC, and assign the Key Vault Secrets User role to the Web App's managed identity.

Answer

Set the Key Vault permission model to Azure RBAC, and assign the Key Vault Secrets User role to the Web App's managed identity.
Setting the Key Vault permission model to Azure RBAC and assigning the Key Vault Secrets User role is correct because the Key Vault Secrets User role provides the necessary data-plane permissions to read secret values, and system-assigned managed identities are fully compatible with Azure RBAC.

Step-by-Step Solution

1
Select the correct permission model on the Key Vault.
The Key Vault is configured to authorize data-plane operations using Azure role-based access control (Azure RBAC).
This is required to shift from the legacy Key Vault access policies to RBAC-based authorization.
2
Assign the appropriate data-plane role to the application's identity.
The system-assigned managed identity of the Web App is assigned the Key Vault Secrets User role.
The Key Vault Secrets User role is the specific built-in role designed to allow reading secret contents (secrets/get) without granting administrative control.

Key Concept

Key Vault access authorization model transition and data-plane role assignment
Estimated Time:1m 0s
Question 192Question →

You are developing a secure client-side Single Page Application (SPA) named OrderClient and a backend Web API named OrderProcessor. The OrderClient application must make HTTP requests to OrderProcessor to retrieve order history on behalf of the currently signed-in user. You need to configure the Microsoft Entra ID app registrations for both applications to secure the API calls using OAuth 2.0. Which of the following configurations should you implement?

Show answer & explanation

Answer: In the OrderProcessor app registration, configure the Application ID URI to api://<OrderProcessor-ClientId>, expose a delegated scope named Orders.Read, and in the OrderClient app registration, add the delegated permission api://<OrderProcessor-ClientId>/Orders.Read.

Answer

Configuring a delegated scope on the backend Web API registration and granting it as a delegated permission to the SPA registration.
Configuring a delegated scope on the backend Web API and granting it to the SPA registration correctly enforces OAuth 2.0 delegated authorization. Using the Application ID URI prefix ensures the scope is globally unique in Microsoft Entra ID, allowing the client application to obtain tokens specifically for that resource.

Step-by-Step Solution

1
Identify the application architecture and user context.
The client is a Single Page Application (SPA) calling a backend Web API on behalf of a signed-in user.
This establishes that delegated permissions (scopes) are required rather than application permissions (App Roles) or managed identities.
2
Expose the custom scope on the backend Web API registration.
Configure an Application ID URI (e.g., api://<OrderProcessor-ClientId>) and define a delegated scope (e.g., Orders.Read).
Microsoft Entra ID requires custom API scopes to be prefixed with the Application ID URI to ensure global uniqueness.
3
Grant the delegated permission to the client application registration.
Add the fully qualified scope URI (api://<OrderProcessor-ClientId>/Orders.Read) to the client application's requested API permissions.
This allows the SPA to request access tokens containing the custom scope during the OAuth 2.0 authorization code flow.

Key Concept

Microsoft Entra ID Delegated Permissions and Custom API Scopes
Question 193Question →

You need to configure an Azure App Service web app to retrieve configuration settings from an Azure App Configuration store. The solution must use a user-assigned managed identity.

Which sequence of actions should you perform? Arrange the actions in the correct order from first to last.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence is: Create the user-assigned managed identity; grant the identity the App Configuration Data Reader role on the configuration store; configure the App Service to use the identity; and add the configuration store's endpoint URI to the App Service settings.
To secure App Configuration access using a user-assigned managed identity, you must first create the identity. Next, you assign the necessary RBAC permissions (App Configuration Data Reader role) to the identity. After permissions are set, you link the identity to the App Service web app. Lastly, you define the App Configuration endpoint inside the App Service settings so that the app code knows where to fetch settings using the assigned identity.

Step-by-Step Solution

1
Create a user-assigned managed identity.
A standalone security principal is created.
You need a security principal to grant permissions to and associate with the App Service.
2
Assign the App Configuration Data Reader role to the identity on the App Configuration store.
The identity receives read access to the configuration store.
This establishes access control permissions for the identity.
3
Associate the identity with the App Service web app.
The App Service is configured to use the identity for outbound calls.
The web app must have the identity linked to authenticate requests under it.
4
Add the App Configuration store endpoint to the App Service application settings.
The web app is configured with the target configuration store URI.
The application code needs this endpoint configuration to locate and fetch settings from the store.

Key Concept

Configuring access to Azure App Configuration using a user-assigned managed identity
Question 194Question →

You are developing a web application that will be hosted on an on-premises web server. The application must programmatically retrieve database connection strings stored as secrets in an Azure Key Vault.

You need to configure the security and authentication requirements to allow the application to access the secrets.

Which of the following actions should you perform?

Show answer & explanation

Answer: Register the application in Microsoft Entra ID to create an application object and a service principal, configure a client secret or certificate for the registration, and grant the service principal access to the secrets in the Key Vault access policy.

Answer

Register the application in Microsoft Entra ID to create an application object and a service principal, configure a client secret or certificate for the registration, and grant the service principal access to the secrets in the Key Vault access policy.
The correct option outlines the standard process for enabling an application running outside of Azure (on-premises) to authenticate and access Azure Key Vault. Since it is hosted on-premises, it cannot use Azure Managed Identities. It requires an Application Registration in Microsoft Entra ID to establish a service principal. The application uses a client secret or certificate to authenticate as this service principal, which must be granted the necessary permissions in the Key Vault access policy to retrieve the secrets.

Step-by-Step Solution

1
Register the application in Microsoft Entra ID.
This creates an application object (definition) and a corresponding service principal (local representation/identity) in the tenant.
An identity is required for the application to authenticate against Microsoft Entra ID.
2
Configure credentials (a client secret or certificate) for the application registration.
The application can now use these credentials to obtain an access token from Microsoft Entra ID.
Since the application runs on-premises, it cannot use managed identities directly and must supply credentials to authenticate.
3
Grant the service principal permission to get secrets in the Azure Key Vault access policy.
The service principal is authorized to retrieve the secrets.
Microsoft Entra ID authentication only proves identity; authorization must be configured at the target resource (Key Vault).

Key Concept

App Registrations and Service Principals are used to establish a security identity for applications, especially when running outside of Azure where Managed Identities are not supported.
Question 195Question →

You are developing a C# application that runs on an Azure Virtual Machine (VM). The application uses the Azure.Identity library to authenticate to an Azure Key Vault using DefaultAzureCredential. Both a system-assigned managed identity and a user-assigned managed identity are enabled on the VM. The user-assigned managed identity is granted the Key Vault Secrets User role on the Key Vault, but the system-assigned managed identity has no permissions. When the application runs, it fails to retrieve secrets because DefaultAzureCredential attempts to authenticate using the system-assigned managed identity. You need to configure the environment so that DefaultAzureCredential uses the user-assigned managed identity without modifying the code that instantiates DefaultAzureCredential. Which of the following actions should you perform?

Show answer & explanation

Answer: Set the AZURE_CLIENT_ID environment variable on the Virtual Machine to the Client ID of the user-assigned managed identity.

Answer

Set the AZURE_CLIENT_ID environment variable on the Virtual Machine to the Client ID of the user-assigned managed identity.
When multiple managed identities are configured on a resource, DefaultAzureCredential defaults to the system-assigned managed identity. To override this behavior and select a specific user-assigned managed identity without code changes, you must set the AZURE_CLIENT_ID environment variable to the Client ID of the user-assigned managed identity.

Step-by-Step Solution

1
Identify the authentication behavior of DefaultAzureCredential when both system-assigned and user-assigned managed identities are present.
By default, DefaultAzureCredential will attempt to use the system-assigned managed identity first.
DefaultAzureCredential follows a specific sequence of credential providers, and for managed identities, it defaults to the system-assigned identity unless instructed otherwise.
2
Determine how to configure DefaultAzureCredential to select a specific user-assigned managed identity without code changes.
Identify that the AZURE_CLIENT_ID environment variable can be set to specify the Client ID of the desired user-assigned managed identity.
The Azure Identity SDK checks for the AZURE_CLIENT_ID environment variable to resolve the identity client ID when initializing the ManagedIdentityCredential component of DefaultAzureCredential.
3
Select the correct environment variable value.
The value must be the Client ID (also known as Application ID) of the user-assigned managed identity, not its Resource ID or Principal ID.
Using the Resource ID, Tenant ID, or Principal ID will fail because the SDK expects the Client ID representation to uniquely query the token endpoint for that specific identity.

Key Concept

Configuring DefaultAzureCredential for user-assigned managed identity using environment variables
Question 196Question →

You are hosting an ASP.NET Core web application in an Azure App Service. The application requires a database connection string stored as a secret named db-conn in an Azure Key Vault named prod-kv. You create a user-assigned managed identity named app-identity and associate it with the App Service. In prod-kv, you grant the Key Vault Secrets User role to app-identity using Azure RBAC. In the App Service configuration, you add an application setting named ConnectionStrings__DefaultConnection with the value @Microsoft.KeyVault(SecretUri=https://prod-kv.vault.azure.net/secrets/db-conn/). However, the App Service fails to resolve the Key Vault reference at runtime and the application cannot retrieve the database connection string. Which of the following actions should you take to resolve this issue?

Show answer & explanation

Answer: Configure the App Service's keyVaultReferenceIdentity property to point to the resource ID of app-identity.

Answer

Configure the App Service's keyVaultReferenceIdentity property to point to the resource ID of app-identity.
To resolve Key Vault references using a user-assigned managed identity, you must set the keyVaultReferenceIdentity property of the App Service to the resource ID of the user-assigned identity. By default, the App Service attempts to use its system-assigned managed identity, which fails if it is not configured or lacks permissions.

Step-by-Step Solution

1
Identify the authentication mechanism used for resolving Key Vault references.
The App Service is configured with a user-assigned managed identity (app-identity) and lacks a system-assigned managed identity.
By default, App Service attempts to resolve Key Vault references using the system-assigned managed identity.
2
Set the Key Vault reference identity property.
Update the keyVaultReferenceIdentity property of the App Service to point to the Resource ID of the user-assigned identity.
This explicitly tells the App Service which user-assigned managed identity to use for authenticating against the Key Vault to resolve reference strings.
3
Verify reference resolution in the App Service configuration.
The reference status changes to Resolved, and the application successfully retrieves the secret value at runtime.
Once the identity is mapped and permissions are verified, App Service can fetch the secret content.

Key Concept

Using user-assigned managed identities to resolve App Service Key Vault references.
Estimated Time:3m 0s
Question 197Question →

You are transitioning a .NET web application hosted on an Azure App Service named `web-prod` from using a system-assigned managed identity to a new user-assigned managed identity named `id-prod`. The application retrieves secrets from an Azure Key Vault named `kv-prod` using the `DefaultAzureCredential` class. The system-assigned identity must remain temporarily enabled during the migration to prevent configuration issues, but the application must immediately begin using the new user-assigned identity to authenticate. You need to configure the resource association and access permissions using the Azure CLI, and update the application configuration. Arrange the steps in the correct order to achieve this transition while preventing application authorization errors during the configuration process.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order of steps is: 1) Run `az identity create` to create the user-assigned identity, 2) Run `az webapp identity assign` to associate the identity with the App Service, 3) Run `az role assignment create` to grant the identity the Key Vault Secrets User role, 4) Add the `AZURE_CLIENT_ID` App Setting to direct `DefaultAzureCredential` to the new identity, and 5) Deploy the updated application code.
The correct sequence begins with creating the user-assigned managed identity to obtain its unique identifiers. Next, the identity must be associated with the App Service so that the App Service can request tokens for it. The RBAC role assignment is then configured at the Key Vault scope to authorize access. Following that, the `AZURE_CLIENT_ID` App Setting is configured to instruct `DefaultAzureCredential` to use this specific user-assigned identity, resolving the ambiguity of coexisting identities. Finally, deploying the application code ensures a seamless transition without access failures.

Step-by-Step Solution

1
Create the user-assigned managed identity.
The identity `id-prod` is created in Microsoft Entra ID, generating its Client ID and Principal ID.
The Client ID and Principal ID are required dependencies for role assignment and App Service configuration.
2
Associate the identity with the App Service host.
The App Service is configured to recognize the user-assigned identity `id-prod`.
The App Service environment must have the identity registered so the Azure Instance Metadata Service (IMDS) token endpoint can retrieve tokens for it.
3
Assign the RBAC role to the identity's Principal ID.
The identity `id-prod` is granted the 'Key Vault Secrets User' role at the `kv-prod` Key Vault scope.
Assigning permissions prior to forcing the application to use the identity prevents 403 Forbidden errors when the application attempts to fetch secrets.
4
Configure the `AZURE_CLIENT_ID` App Setting.
The environment variable `AZURE_CLIENT_ID` is set to the client ID of `id-prod`.
When both system-assigned and user-assigned identities are active on the same App Service, `DefaultAzureCredential` requires the `AZURE_CLIENT_ID` environment variable to identify which user-assigned identity to use.
5
Deploy the application code.
The application runs, and `DefaultAzureCredential` successfully fetches Key Vault secrets using the user-assigned managed identity.
With all infrastructure, permissions, and environment variables fully configured, the application can securely execute without service disruption.

Key Concept

Configuring coexisting managed identities and directing DefaultAzureCredential using environment variables.
Question 198Question →

You are designing the security architecture for an enterprise Azure Function app that processes financial transactions. The app requires access to an Azure SQL Database and retrieves cryptographic keys from an Azure Key Vault. Due to strict CI/CD and compliance policies, the Function app is frequently torn down and recreated in different resource groups using automated Terraform scripts. You need to choose a managed identity configuration that ensures the application can authenticate to Azure SQL and Key Vault with the least administrative effort during deployment cycles, specifically avoiding the need to recreate database users or update Key Vault access policies after each deployment.

Which configuration should you implement?

Show answer & explanation

Answer: Configure a user-assigned managed identity as a standalone Azure resource, grant it the required roles on the Azure SQL Database and Key Vault, and assign this identity to the Function app during deployment.

Answer

Configure a user-assigned managed identity as a standalone Azure resource, grant it the required roles on the Azure SQL Database and Key Vault, and assign this identity to the Function app during deployment.
A user-assigned managed identity exists as a standalone Azure resource with its own lifecycle. When the Azure Function app is deleted and recreated by Terraform, the user-assigned identity and its associated service principal object ID remain unchanged. Consequently, the permissions granted to the identity in the Azure SQL Database and Azure Key Vault persist across deployments, requiring only that the new Function app instance be associated with the existing identity.

Step-by-Step Solution

1
Analyze the resource lifecycle requirement.
The application infrastructure is ephemeral (frequently deleted and recreated via CI/CD), while the target systems (Azure SQL and Key Vault) are persistent.
Choosing a system-assigned identity would tie the identity's lifecycle to the ephemeral resource, causing credential loss and requiring constant manual reconfiguration.
2
Compare system-assigned and user-assigned managed identities.
A user-assigned managed identity is created as a standalone Azure resource. It survives the deletion of the associated Azure Function App.
To maintain persistent authorization in Key Vault and Azure SQL without updating permissions during deployments, the identity must have an independent lifecycle.
3
Verify authorization requirements.
The managed identity must have specific data plane permissions (e.g., Key Vault Secrets User, Azure SQL database roles) to retrieve keys and query data.
Generic management plane roles like Reader do not authorize data plane operations, so direct RBAC role assignments or access policies are required.

Key Concept

The lifecycle difference between System-Assigned and User-Assigned Managed Identities.
Estimated Time:2m 0s
Question 199Question →

You are developing a background worker service in C# that runs as a containerized application within Azure Container Apps. The service must run on a schedule without user interaction and authenticate to the Microsoft Identity Platform to read files from Microsoft Graph.

To comply with security policies, you must use Azure Managed Identities for authentication. The credentials must persist independently of the containerized app's lifecycle, allowing the container instances to be deleted, recreated, or scaled across different resource groups without requiring permissions to be reconfigured in Microsoft Entra ID.

Which approach should you use to implement this authentication?

Show answer & explanation

Answer: Create a user-assigned managed identity as a standalone Azure resource. Grant this identity the required Microsoft Graph application permissions, associate it with the Azure Container App, and initialize DefaultAzureCredential by passing the client ID of the user-assigned managed identity.

Answer

Create a user-assigned managed identity as a standalone Azure resource. Grant this identity the required Microsoft Graph application permissions, associate it with the Azure Container App, and initialize DefaultAzureCredential by passing the client ID of the user-assigned managed identity.
The correct approach is to create a user-assigned managed identity. A user-assigned managed identity is created as a standalone Azure resource and has its own lifecycle independent of the Azure Container App. If the container app is deleted or recreated, the user-assigned identity and its assigned Microsoft Graph permissions persist. When initializing DefaultAzureCredential in code, the client ID of the user-assigned managed identity must be specified to ensure the SDK authenticates with the correct identity.

Step-by-Step Solution

1
Create a user-assigned managed identity in Azure.
A standalone identity resource is generated with its own Client ID and Object ID, separate from the container app.
To ensure that the identity credentials persist even if the hosting container app is deleted or redeployed.
2
Grant the user-assigned managed identity the required Microsoft Graph application permissions.
The identity is authorized to access Microsoft Graph APIs directly without user intervention.
Because the background worker service runs automatically on a schedule and cannot perform interactive user login.
3
Associate the user-assigned managed identity with the Azure Container App and configure the C# application to use it.
The Container App gets access to the identity, and DefaultAzureCredential is initialized using the client ID of the user-assigned managed identity.
To ensure the Azure SDK/MSAL resolves to the correct user-assigned identity instead of attempting to fall back to other credentials.

Key Concept

Managed Identities (system-assigned vs. user-assigned) and their lifecycle differences when authenticating to the Microsoft Identity Platform.
Question 200Question →

You are configuring a Python FastAPI web application hosted on Azure App Service to load its settings from an Azure App Configuration store. One of the keys in the App Configuration store, DbConnectionString, is configured as a Key Vault reference pointing to a secret in Azure Key Vault. The App Service is configured to use a system-assigned managed identity. At runtime, the application successfully retrieves standard key-values from the App Configuration store but fails with an authorization error when attempting to resolve the value of the DbConnectionString key. How should you resolve this issue?

Show answer & explanation

Answer: Grant the App Service's system-assigned managed identity the Key Vault Secrets User role on the Azure Key Vault.

Answer

Grant the App Service's system-assigned managed identity the Key Vault Secrets User role on the Azure Key Vault.
The correct solution is to grant the App Service's system-assigned managed identity the Key Vault Secrets User role on the Azure Key Vault. In Azure App Configuration, Key Vault references are resolved client-side by the application client library. This library uses the credentials supplied to the configuration provider (in this scenario, the system-assigned managed identity of the App Service) to authenticate directly against the Azure Key Vault. Therefore, the App Service's identity requires direct access to read secrets in the Key Vault.

Step-by-Step Solution

1
Identify where the Key Vault reference resolution takes place.
The App Configuration provider library resolves Key Vault references client-side within the application process.
Understanding the client-side nature of Key Vault references in App Configuration is critical for setting permissions on the correct identity.
2
Determine which identity is executing the application process.
The App Service's system-assigned managed identity.
Since the application runs on the App Service, it uses the App Service's identity to connect to resources.
3
Assign the appropriate RBAC role to the App Service's identity on the Key Vault.
Assign Key Vault Secrets User role (or Get permissions in access policies) to the App Service's identity.
This grants the application permission to fetch the secret value during the configuration loading process.

Key Concept

Key Vault Reference Resolution in Azure App Configuration
Estimated Time:1m 30s
PreviousPage 10 / 11Next
Implement Azure Security Practice Questions — Microsoft Azure Developer (AZ-204) — Page 10 | Examkin