Implement Azure Security

203 questions

All types203 Multiple choice102 Multiple select71 Ordering30

You are deploying an Azure App Service web application that needs to retrieve a database connection string from an Azure Key Vault named my-keyvault. The connection string is stored as a secret named db-conn-string. You decide to use a Key Vault reference in the App Service application settings to retrieve the secret. Which of the following values represents the correct syntax format to reference this secret?

@Microsoft.KeyVault(SecretUri=https://my-keyvault.vault.azure.net/secrets/db-conn-string/)

@Azure.KeyVault(SecretUri=https://my-keyvault.vault.azure.net/secrets/db-conn-string/)

@Microsoft.KeyVault(SecretName=db-conn-string)

{"SecretUri": "https://my-keyvault.vault.azure.net/secrets/db-conn-string"}

Show answer & explanation

Answer: @Microsoft.KeyVault(SecretUri=https://my-keyvault.vault.azure.net/secrets/db-conn-string/)

Answer

The correct format is the option that uses the @Microsoft.KeyVault prefix followed by the SecretUri parameter pointing to the secret's URI, specifically: @Microsoft.KeyVault(SecretUri=https://my-keyvault.vault.azure.net/secrets/db-conn-string/).

The correct format uses the prefix '@Microsoft.KeyVault' followed by the 'SecretUri' parameter pointing to the URI of the secret in Azure Key Vault: @Microsoft.KeyVault(SecretUri=https://my-keyvault.vault.azure.net/secrets/db-conn-string/). This allows the App Service to authenticate using its managed identity and retrieve the secret at runtime.

Step-by-Step Solution

Identify the service and feature being configured.

Azure App Service Application Settings using a Key Vault reference.

This allows the App Service to automatically resolve the secret from Key Vault without application code changes.

Determine the prefix required for Key Vault references.

The prefix must be exactly '@Microsoft.KeyVault'.

Azure App Service parser looks for this specific prefix to resolve Key Vault secrets at runtime.

Identify the required parameter format inside the parentheses.

The parameter is 'SecretUri=' followed by the full URI of the secret.

This uniquely identifies the secret vault, secret name, and optionally the version.

Key Concept

Azure Key Vault Reference Syntax in Azure App Service Configuration

Question 82Question →

An organization is deploying a multi-tenant web application named App1 to Azure App Service. App1 needs to authenticate users from any Microsoft Entra ID tenant but must restrict access to corporate (work or school) accounts only, preventing personal Microsoft accounts from signing in. You are configuring the application registration manifest and the authentication authority endpoint in the application code.

Which of the following configurations should you apply to satisfy these requirements?

Set the signInAudience parameter to AzureADMultipleOrgs and use the authority endpoint https://login.microsoftonline.com/organizations

Set the signInAudience parameter to AzureADandPersonalMicrosoftAccount and use the authority endpoint https://login.microsoftonline.com/common

Set the signInAudience parameter to AzureADMultipleOrgs and use the authority endpoint https://login.microsoftonline.com/common

Set the signInAudience parameter to AzureADMyOrg and use the authority endpoint https://login.microsoftonline.com/organizations

Show answer & explanation

Answer: Set the signInAudience parameter to AzureADMultipleOrgs and use the authority endpoint https://login.microsoftonline.com/organizations

Answer

Set the signInAudience parameter to AzureADMultipleOrgs and use the authority endpoint https://login.microsoftonline.com/organizations

The correct configuration is to set the signInAudience to AzureADMultipleOrgs and use the /organizations authority endpoint. This ensures the application accepts authentication requests only from organizational (work or school) directories across any tenant while preventing personal Microsoft accounts from signing in.

Step-by-Step Solution

Analyze the tenant requirement

The application must support users from multiple external Microsoft Entra ID tenants, meaning a multi-tenant configuration is required.

Single-tenant configuration (AzureADMyOrg) will restrict logins to a single tenant.

Select the correct signInAudience

Choose AzureADMultipleOrgs instead of AzureADandPersonalMicrosoftAccount.

The requirement explicitly states that personal accounts must be blocked. AzureADMultipleOrgs targets only corporate accounts across tenants.

Select the correct authority endpoint

Use the /organizations endpoint instead of the /common endpoint.

The /organizations endpoint restricts sign-in requests to organizational accounts only, whereas the /common endpoint accepts both organizational and personal accounts.

Key Concept

Configuring multi-tenant Microsoft Entra ID applications with appropriate sign-in audiences and authorization endpoints.

Estimated Time:2m 0s

Question 83Question →

You need to configure a local script to run nightly administrative tasks against Azure resources. The script must run non-interactively and authenticate using certificate-based authentication. Which sequence of steps must you perform to set up the authentication and test the connection?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To set up certificate-based authentication, you must first generate the self-signed certificate, register the application in Microsoft Entra ID, upload the certificate public key, assign the required RBAC role to the service principal, and finally execute the login command using the certificate details.

The correct sequence starts with generating a certificate locally to obtain a public key. Then, the application is registered in Microsoft Entra ID to establish its identity. Next, the public key is uploaded to the application registration so Microsoft Entra ID can verify credentials. After that, the service principal is assigned an RBAC role to grant the necessary resource permissions. Finally, the script executes the login command using the certificate path, verifying the configuration.

Step-by-Step Solution

Generate a self-signed certificate locally.

A private key (retained locally) and a public key certificate (.cer file) are created.

The public key certificate is required to configure the application registration credential.

Create the application registration in Microsoft Entra ID.

An application object and a corresponding service principal are created in the Microsoft Entra tenant.

This establishes the identity that will be used by the automation script.

Upload the public key (.cer) to the application registration's Certificates & secrets.

The public key is associated with the application registration.

This allows Microsoft Entra ID to validate authentication requests signed by the private key.

Assign an RBAC role to the service principal.

The service principal is authorized to perform operations on the specified Azure resources.

Establishing identity is not enough; the service principal must be explicitly authorized to access resources.

Run the login command with the certificate details.

The script successfully authenticates and receives an access token.

This verifies that the identity, credentials, and RBAC permissions are correctly configured.

Key Concept

Configuring certificate-based authentication for service principals to enable secure, non-interactive scripting and automation.

Question 84Question →

An organization is deploying three separate Azure Function apps that all retrieve configuration secrets from a shared Azure Key Vault and query data from a shared Azure SQL Database. You need to configure managed identities for the application authentication. The solution must minimize administrative overhead for managing access control and ensure that deleting any individual Function app does not affect the permissions or credentials of the remaining apps. Which two actions should you perform? (Choose two.)

Select all that apply

Create a single user-assigned managed identity and configure all three Azure Function apps to use this identity.

Grant the user-assigned managed identity the Key Vault Secrets User role on the Azure Key Vault and the db_datareader role on the Azure SQL Database.

Enable a system-assigned managed identity on each of the three Azure Function apps.

Create a single system-assigned managed identity at the resource group level to represent all three Function apps.

Assign the Reader RBAC role at the Key Vault resource group level to the managed identity.

Show answer & explanation

Answer: Create a single user-assigned managed identity and configure all three Azure Function apps to use this identity.; Grant the user-assigned managed identity the Key Vault Secrets User role on the Azure Key Vault and the db_datareader role on the Azure SQL Database.

Answer

Create a single user-assigned managed identity and configure all three Azure Function apps to use this identity, and grant the user-assigned managed identity the Key Vault Secrets User role on the Azure Key Vault and the db_datareader role on the Azure SQL Database.

The correct options are to create a single user-assigned managed identity and assign it to all three apps, and to grant it the Key Vault Secrets User and db_datareader roles. A user-assigned managed identity is a standalone Azure resource with an independent lifecycle that can be associated with multiple resources. This satisfies the requirement to minimize overhead and prevent accidental credential deletion. To read secrets and SQL database data, the identity needs explicit data plane permissions.

Step-by-Step Solution

Analyze the identity sharing and lifecycle requirements.

A user-assigned managed identity is selected because it is created as a standalone Azure resource and can be shared across multiple resources (minimizing permission overhead), and its lifecycle is independent of the individual Function apps.

System-assigned identities are tied to a single resource and cannot be shared, which increases management overhead.

Assign the correct data plane permissions to the shared identity.

The identity is granted data-plane roles: Key Vault Secrets User on the Key Vault and db_datareader in the SQL Database.

Management plane roles like Reader at the resource group level do not grant access to the actual secrets contained within the Key Vault.

Key Concept

User-assigned managed identities allow credentials and access control to be shared among multiple resources while maintaining a lifecycle independent of the resources themselves, whereas data-plane access requires specific data-plane roles rather than management-plane Reader roles.

Question 85Question →

An enterprise Azure Function app is configured with a system-assigned managed identity. The application must perform envelope encryption on sensitive payloads before uploading them to Azure Blob Storage. A symmetric Data Encryption Key (DEK) is generated locally for each payload. The DEK must be wrapped (encrypted) using an HSM-backed RSA Key Encryption Key (KEK) named PayloadKEK stored in an Azure Key Vault named kv-prod. The Key Vault has Azure Role-Based Access Control (Azure RBAC) enabled as its permission model. You need to implement the solution using the latest Azure SDK for .NET. Which two of the following actions must you perform to configure permissions and wrap the DEK?

Select all that apply

Assign the Key Vault Crypto User role for kv-prod to the system-assigned managed identity of the Function app.

Assign the Key Vault Crypto Service Encryption User role for kv-prod to the system-assigned managed identity of the Function app.

In the Function app code, instantiate a CryptographyClient using DefaultAzureCredential and the URI of PayloadKEK, and call WrapKeyAsync.

In the Function app code, instantiate a KeyClient using DefaultAzureCredential, call GetKeyAsync to retrieve PayloadKEK, and perform the key wrapping locally using the key's public/private parameters.

Show answer & explanation

Answer: Assign the Key Vault Crypto User role for kv-prod to the system-assigned managed identity of the Function app.; In the Function app code, instantiate a CryptographyClient using DefaultAzureCredential and the URI of PayloadKEK, and call WrapKeyAsync.

Answer

Assign the Key Vault Crypto User role for the Key Vault to the system-assigned managed identity, and in the application code, use the CryptographyClient with DefaultAzureCredential to call WrapKeyAsync.

To perform envelope encryption, you must grant the system-assigned managed identity of the Function app the Key Vault Crypto User role, which enables the identity to invoke the key wrapping APIs of Key Vault. In the C# .NET SDK, you must use the CryptographyClient class from the Azure.Security.KeyVault.Keys.Cryptography namespace to handle cryptographic operations like key wrapping, using DefaultAzureCredential for token acquisition.

Step-by-Step Solution

Configure Key Vault Authorization

The system-assigned managed identity of the Azure Function app is assigned the Key Vault Crypto User role on the kv-prod Key Vault.

This RBAC role is required to grant the application permission to perform cryptographic wrap/unwrap operations using keys within the Key Vault.

Instantiate the Cryptography Client

The CryptographyClient is instantiated in the .NET code using the Key Vault key's URI and DefaultAzureCredential.

The modern Azure SDK separates management operations (KeyClient) from cryptographic operations (CryptographyClient). The CryptographyClient is specialized for wrapping and unwrapping.

Execute the Wrapping Operation

WrapKeyAsync is called on the CryptographyClient, passing the locally generated DEK and the desired KeyWrapAlgorithm.

This securely wraps the symmetric DEK using the KEK stored in the Key Vault, offloading the cryptographic operation to the Key Vault itself.

Key Concept

Azure Key Vault Key Cryptography and Azure RBAC Roles

Question 86Question →

You are deploying a web application to Azure App Service. You want to retrieve a database connection password stored in Azure Key Vault directly through the App Service application settings without modifying the application code.

Which of the following is the correct syntax to use as the value for the application setting to reference a secret named 'db-password' in a Key Vault named 'myvault'?

@AzureKeyVault(SecretUri=https://myvault.vault.azure.net/secrets/db-password/)

https://myvault.vault.azure.net/secrets/db-password/

@Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/db-password/)

@Microsoft.KeyVault(VaultUri=https://myvault.vault.azure.net;SecretName=db-password)

Show answer & explanation

Answer: @Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/db-password/)

Answer

The correct syntax is @Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/db-password/)

The correct format for a Key Vault reference in App Service uses the prefix @Microsoft.KeyVault followed by the SecretUri parameter set to the secret's absolute URL. This allows App Service to retrieve the secret automatically at runtime using the application's managed identity.

Step-by-Step Solution

Identify the required prefix for Azure Key Vault references in App Service.

The prefix must be @Microsoft.KeyVault.

Azure App Service uses the @Microsoft.KeyVault keyword to detect and process settings that should be fetched from Key Vault.

Determine the parameter format required to specify the location of the secret.

The parameters inside the parentheses must be either SecretUri or a combination of VaultName and SecretName.

The reference resolver requires specific key names to identify the vault and secret.

Format the final configuration value.

@Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/db-password/)

This format correctly combines the prefix and the valid SecretUri parameter.

Key Concept

Azure Key Vault references in App Service application settings allow applications to securely access secrets without modifying application code.

Estimated Time:45s

Question 87Question →

You are developing an ASP.NET Core web application that will be hosted in an Azure App Service. The application must retrieve configuration settings from an Azure App Configuration store. Several settings in the store are Key Vault references pointing to secrets in Azure Key Vault. You must secure access using a single user-assigned managed identity, adhering to the principle of least privilege.

Which of the following represents the correct sequence of steps to configure the Azure resources and the web application?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts with creating the user-assigned managed identity, associating it with the App Service web app, granting the identity the App Configuration Data Reader role on the App Configuration store and the Key Vault Secrets User role on the Key Vault, configuring the AZURE_CLIENT_ID application setting on the App Service, and finally updating the application startup code to use DefaultAzureCredential to connect to App Configuration and resolve Key Vault references.

The correct sequence ensures that the identity resource is established first, associated with the host compute resource, authorized via role-based access control (RBAC) to read configuration and Key Vault secrets, mapped to the environment via the standard client ID environment variable, and finally consumed by the application code using the DefaultAzureCredential.

Step-by-Step Solution

Create a user-assigned managed identity in Microsoft Entra ID.

A new managed identity resource is created with a unique Client ID and Principal ID.

You cannot perform role assignments or associate the identity with other Azure resources until the identity resource itself exists.

Associate the user-assigned managed identity with the Azure App Service web app.

The App Service web app is configured to use the user-assigned identity.

The web app must have the identity assigned so the hosting platform can request tokens on its behalf.

Assign the App Configuration Data Reader role to the identity on the App Configuration store, and the Key Vault Secrets User role to the identity on the Key Vault.

The managed identity is granted the minimum required permissions to read configuration keys and resolve Key Vault secrets.

Since Key Vault references in Azure App Configuration are resolved client-side by the application itself, the application's identity requires permissions to both services.

Add the AZURE_CLIENT_ID application setting to the App Service web app.

An environment variable with the identity's client ID is injected into the application's runtime context.

By default, DefaultAzureCredential attempts to use the system-assigned managed identity. Specifying the AZURE_CLIENT_ID environment variable forces it to use the correct user-assigned identity.

Configure the web app's startup code to connect to the App Configuration store using DefaultAzureCredential and enable Key Vault options.

The application successfully fetches the configuration and decrypts Key Vault references on startup.

The application code must explicitly register the App Configuration provider and pass DefaultAzureCredential to handle authentication.

Key Concept

Configuring secure client-side resolution of Azure App Configuration Key Vault references using a user-assigned managed identity.

Estimated Time:3m 0s

Question 88Question →

You are developing a C# .NET console application that must retrieve a connection string stored as a secret in Azure Key Vault. The application will run locally during development and as a containerized app in Azure once deployed. You want to connect to the Key Vault using the modern Azure SDK. Which two components are required to successfully authenticate the client and retrieve the secret? (Select two.)

Select all that apply

The DefaultAzureCredential class from the Azure.Identity package to handle authentication.

The SecretClient class from the Azure.Security.KeyVault.Secrets package to perform secret operations.

The KeyVaultClient class from the Microsoft.Azure.KeyVault package to establish a connection to the vault.

A Key Vault reference using the @Microsoft.KeyVault(SecretUri=...) format inside the application code.

Show answer & explanation

Answer: The DefaultAzureCredential class from the Azure.Identity package to handle authentication.; The SecretClient class from the Azure.Security.KeyVault.Secrets package to perform secret operations.

Answer

To authenticate and retrieve a secret using the modern Azure SDK, you must use the DefaultAzureCredential class from the Azure.Identity namespace and the SecretClient class from the Azure.Security.KeyVault.Secrets namespace.

To authenticate and retrieve a secret from Azure Key Vault using the modern Azure SDK, the application must construct a DefaultAzureCredential object to handle identity flow and pass it into a newly initialized SecretClient object to communicate with Key Vault.

Step-by-Step Solution

Import the modern Azure SDK namespaces Azure.Identity and Azure.Security.KeyVault.Secrets.

The required client and credential types become available in the application scope.

Ensures the application uses the current, non-deprecated SDK packages.

Instantiate a DefaultAzureCredential object.

An authentication token source is initialized that resolves credentials dynamically depending on whether the app runs locally or in Azure.

Allows passwordless authentication using the environment's identity flow.

Instantiate a SecretClient object, passing the vault URI and the DefaultAzureCredential instance, and call the GetSecret or GetSecretAsync method.

The connection is established, and the secret containing the connection string is successfully retrieved from the Key Vault.

Initiates the API request using the modern client implementation to retrieve the secret payload.

Key Concept

Retrieving secrets from Azure Key Vault using the modern Azure SDK for .NET with token-based Azure Identity authentication.

Question 89Question →

You are developing a multi-tenant SaaS application that will be registered in Microsoft Entra ID. The application must allow users from any corporate Microsoft Entra ID tenant to sign in using their work or school accounts. However, users with personal Microsoft accounts (such as Outlook.com or Xbox Live) must be prevented from signing in. Which of the following configuration actions must you perform to meet these requirements? (Select TWO.)

Select all that apply

Configure the signInAudience property in the application manifest to AzureADMultipleOrgs.

Configure the authority endpoint in the application code to use the /organizations tenant placeholder.

Configure the signInAudience property in the application manifest to AzureADandPersonalMicrosoftAccount.

Configure the authority endpoint in the application code to use the /common tenant placeholder.

Show answer & explanation

Answer: Configure the signInAudience property in the application manifest to AzureADMultipleOrgs.; Configure the authority endpoint in the application code to use the /organizations tenant placeholder.

Answer

Configure the signInAudience property in the application manifest to AzureADMultipleOrgs, and configure the authority endpoint in the application code to use the /organizations tenant placeholder.

To limit authentication to work or school accounts from any Microsoft Entra ID directory while excluding personal Microsoft accounts, you must set the application registration's manifest signInAudience property to AzureADMultipleOrgs and route sign-ins through the /organizations endpoint. This combination guarantees that only corporate identities can authenticate.

Step-by-Step Solution

Determine the required audience type for the multi-tenant application based on the identity restrictions.

Since personal Microsoft accounts must be excluded while corporate accounts are allowed, the target audience configuration value is AzureADMultipleOrgs.

The AzureADMultipleOrgs setting limits sign-ins strictly to corporate tenant environments and prevents personal Microsoft account validation.

Select the matching endpoint routing for the client-side authentication library.

The authority URI path must use the /organizations endpoint.

The /organizations path filters incoming sign-ins to only allow organizational directories, complementing the AzureADMultipleOrgs manifest setting.

Key Concept

Configuring multi-tenant Microsoft Entra ID applications with restricted sign-in audiences and endpoints

Estimated Time:1m 30s

Question 90Question →

You are developing a secure multi-tier application where the frontend web app is hosted on-premises and needs to authenticate to a backend API hosted in Azure. You register the frontend application in your Microsoft Entra ID tenant, which automatically creates an application object and a service principal in the tenant. Later, to comply with a security policy, you delete the application registration in the Azure portal. What is the immediate impact of deleting this application registration on the associated service principal in your tenant?

The service principal remains in the tenant and can still be authenticated using the existing certificates.

The service principal remains in the tenant but is permanently disabled.

The service principal is automatically deleted from the tenant.

The service principal is automatically converted into a user-assigned managed identity.

Show answer & explanation

Answer: The service principal is automatically deleted from the tenant.

Answer

The service principal is automatically deleted from the tenant.

In Microsoft Entra ID, an application registration creates an application object (the global representation of the app) and a service principal (the local instance of the app in the tenant). In the home tenant where the application is registered, deleting the application registration automatically deletes the associated service principal.

Step-by-Step Solution

Analyze the relationship between an Application registration and a Service Principal in Microsoft Entra ID.

An application registration creates a global application object and a local service principal in the home tenant.

Understanding the structural dependency between these two resources is essential for managing their lifecycle.

Determine the impact of deleting the application registration.

Deleting the application registration removes both the application object and its corresponding service principal in the home tenant.

Since the service principal in the home tenant is directly tied to the application registration lifecycle, removing the registration cleans up the associated security identity.

Key Concept

Application registrations and service principals share a linked lifecycle in their home tenant. Deleting the application registration automatically removes the service principal in that tenant.

Question 91Question →

You are developing a client-side application that needs to upload temporary log files to a specific container named 'logs' in an Azure Blob Storage account. You need to generate a Shared Access Signature (SAS) token for the client. The solution must adhere to the principle of least privilege, allow access only from the IP address range 198.51.100.0/24, restrict communication to HTTPS, and expire in 2 hours. Which of the following configurations should you implement?

An Account SAS scoped to the storage account with Read, Write, and List permissions across all services, protocol set to HTTP and HTTPS, and no IP address restrictions.

A Service SAS scoped only to the 'logs' container with Write-only permission, protocol restricted to HTTPS-only, IP address range restricted to 198.51.100.0/24, and a 2-hour expiration time.

A Service SAS scoped to the 'logs' container with Read, Write, and Delete permissions, protocol restricted to HTTPS-only, and a 24-hour expiration time.

An Account SAS scoped to the Blob service with Write and Delete permissions, protocol set to HTTP and HTTPS, and no IP address restrictions.

Show answer & explanation

Answer: A Service SAS scoped only to the 'logs' container with Write-only permission, protocol restricted to HTTPS-only, IP address range restricted to 198.51.100.0/24, and a 2-hour expiration time.

Answer

A Service SAS scoped only to the 'logs' container with Write-only permission, protocol restricted to HTTPS-only, IP address range restricted to 198.51.100.0/24, and a 2-hour expiration time.

The correct configuration is a Service SAS scoped to the 'logs' container with Write-only permission, HTTPS-only protocol, the specific client IP address range, and a 2-hour expiration time. This ensures that the client has only the necessary access permissions, is constrained to a secure protocol and IP range, and that the token expires as soon as possible.

Step-by-Step Solution

Identify the required scope for the SAS token.

The application only needs to write to a specific container ('logs'), so a Service SAS scoped to that container should be used rather than an Account SAS.

A Service SAS delegates access to a resource in a single storage service, enforcing the principle of least privilege.

Determine the required permissions for the scenario.

The application only needs to upload log files, which requires Write permission.

Granting Read or Delete permissions would violate the principle of least privilege.

Identify the security constraints required.

The protocol must be HTTPS-only, the allowed IP address range must be restricted to 198.51.100.0/24, and the token expiration must be set to 2 hours.

These constraints restrict the protocol, source networks, and temporal validity of the SAS token to minimize the risk of unauthorized access.

Key Concept

Shared Access Signatures (SAS) Principle of Least Privilege

Question 92Question →

You are authoring an Azure Resource Manager (ARM) template to deploy an Azure App Service web app that needs to read secrets from an Azure Key Vault. During testing, developers will frequently delete and recreate the App Service web app. You must ensure that redeploying the web app does not require recreating Key Vault access policies or re-granting permissions.

Which configuration should you define in the resources section of the ARM template to enable the managed identity?

Set the identity type to UserAssigned and define the resource ID of the existing user-assigned managed identity as a key in the userAssignedIdentities dictionary.

Set the identity type to SystemAssigned and define the resource ID of the existing user-assigned managed identity as a key in the userAssignedIdentities dictionary.

Set the identity type to UserAssigned and define the client ID of the existing user-assigned managed identity as a key in the userAssignedIdentities dictionary.

Set the identity type to SystemAssigned and assign Key Vault permissions to the principal ID generated by the App Service resource.

Show answer & explanation

Answer: Set the identity type to UserAssigned and define the resource ID of the existing user-assigned managed identity as a key in the userAssignedIdentities dictionary.

Answer

Set the identity type to UserAssigned and define the resource ID of the existing user-assigned managed identity as a key in the userAssignedIdentities dictionary.

The correct configuration uses a user-assigned managed identity, which exists as a standalone Azure resource independent of the App Service web app. By configuring the identity type as 'UserAssigned' and referencing the identity's resource ID in the 'userAssignedIdentities' block, the web app can be deleted and redeployed without deleting the managed identity itself or breaking the Key Vault access policies configured for it.

Step-by-Step Solution

Analyze the lifecycle requirements of the scenario.

Since the App Service web app is frequently deleted and recreated, a system-assigned identity would be deleted along with the app, invalidating any Key Vault access policies. A user-assigned identity must be used because its lifecycle is independent of the resources it is assigned to.

Choosing the correct identity type prevents needing to recreate access policies on each redeployment.

Determine the proper ARM template schema configuration for a user-assigned managed identity.

The identity configuration block in an ARM template requires setting the 'type' property to 'UserAssigned' and using the fully-qualified resource ID of the identity as a key in the 'userAssignedIdentities' dictionary.

Using client IDs or system-assigned configurations will fail to deploy or will configure the wrong identity type.

Key Concept

Selecting and configuring the correct managed identity type (System-Assigned vs User-Assigned) based on lifecycle requirements and ARM template properties.

Question 93Question →

A developer is configuring a Shared Access Signature (SAS) token to allow an external application to download diagnostic reports from a specific Azure Blob Storage container. The token must be valid for 24 hours, enforce HTTPS-only access, and restrict operations to downloading blobs. Which two configurations should the developer apply to the SAS token to meet these requirements?

Select all that apply

Set the permissions parameter to Read (r) only.

Set the allowed protocols parameter to HTTPS only.

Set the permissions parameter to Read and Write (rw) to allow metadata reading.

Set the allowed protocols parameter to HTTP and HTTPS to ensure compatibility.

Generate an Account-level SAS with access to Blob, File, and Queue services.

Show answer & explanation

Answer: Set the permissions parameter to Read (r) only.; Set the allowed protocols parameter to HTTPS only.

Answer

To meet the requirements, the developer must set the permissions parameter to Read (r) only and set the allowed protocols parameter to HTTPS only.

The correct configurations restrict the SAS token permissions to Read (r) only, which is sufficient for downloading files, and enforce HTTPS-only access to prevent cleartext transmission of data, aligning with security requirements.

Step-by-Step Solution

Determine the minimum required permissions for downloading files.

Only Read (r) permission is needed.

Granting additional permissions like Write (w) violates the principle of least privilege.

Determine the allowed protocol constraint.

HTTPS-only parameter configuration.

This enforces transport-level security and prevents unencrypted HTTP connections.

Key Concept

Configuring least-privilege permissions and protocol constraints on a Shared Access Signature (SAS) token.

Estimated Time:1m 0s

Question 94Question →

You are developing a secure C# application using the `Azure.Storage.Blobs` SDK. The application must generate a Shared Access Signature (SAS) token that allows external clients to upload a single PDF file named `confidential.pdf` to a container named `secure-docs` in an Azure Storage account named `corpdata`.

Your application must comply with the following security and operational constraints:
- Authentication: Storage account access keys must not be used, stored, or referenced by the application. You must authenticate using the application's system-assigned managed identity.
- Permissions: The token must grant only write permissions to the specific blob. No read, delete, or list permissions should be granted.
- Protocol: Connections must be restricted to HTTPS only.
- Network Constraints: The token must only be usable from the client's public IP address ` $198.51.100.72$ `.
- Validity: The token must be valid for exactly ` $30$ ` minutes from generation.
- Reliability: The token must be usable immediately upon receipt by the client, without failing due to potential clock synchronization differences (clock skew) between servers.

Which of the following C# code segments should you use to generate the SAS token?

var credential = new DefaultAzureCredential();
var blobServiceClient = new BlobServiceClient(
new Uri("https://corpdata.blob.core.windows.net"), credential);

UserDelegationKey delegationKey = await blobServiceClient.GetUserDelegationKeyAsync(
startsOn: DateTimeOffset.UtcNow.AddMinutes(-15),
expiresOn: DateTimeOffset.UtcNow.AddMinutes(45)
);

var sasBuilder = new BlobSasBuilder()
{
BlobContainerName = "secure-docs",
BlobName = "confidential.pdf",
Resource = "b",
StartsOn = DateTimeOffset.UtcNow.AddMinutes(-15),
ExpiresOn = DateTimeOffset.UtcNow.AddMinutes(30),
Protocol = SasProtocol.Https,
IPRange = SasIPRange.Parse("198.51.100.72")
};
sasBuilder.SetPermissions(BlobSasPermissions.Write);

string sasToken = sasBuilder.ToSasQueryParameters(delegationKey, "corpdata").ToString();

var sharedKeyCredential = new StorageSharedKeyCredential("corpdata", "AccountKeyString");
var blobServiceClient = new BlobServiceClient(
new Uri("https://corpdata.blob.core.windows.net"), sharedKeyCredential);

var sasBuilder = new BlobSasBuilder()
{
BlobContainerName = "secure-docs",
BlobName = "confidential.pdf",
Resource = "b",
StartsOn = DateTimeOffset.UtcNow.AddMinutes(-15),
ExpiresOn = DateTimeOffset.UtcNow.AddMinutes(30),
Protocol = SasProtocol.Https,
IPRange = SasIPRange.Parse("198.51.100.72")
};
sasBuilder.SetPermissions(BlobSasPermissions.Write);

string sasToken = sasBuilder.ToSasQueryParameters(sharedKeyCredential).ToString();

var credential = new DefaultAzureCredential();
var blobServiceClient = new BlobServiceClient(
new Uri("https://corpdata.blob.core.windows.net"), credential);

UserDelegationKey delegationKey = await blobServiceClient.GetUserDelegationKeyAsync(
startsOn: DateTimeOffset.UtcNow,
expiresOn: DateTimeOffset.UtcNow.AddMinutes(30)
);

var sasBuilder = new BlobSasBuilder()
{
BlobContainerName = "secure-docs",
BlobName = "confidential.pdf",
Resource = "b",
StartsOn = DateTimeOffset.UtcNow,
ExpiresOn = DateTimeOffset.UtcNow.AddMinutes(30),
Protocol = SasProtocol.Https,
IPRange = SasIPRange.Parse("198.51.100.72")
};
sasBuilder.SetPermissions(BlobSasPermissions.Write);

string sasToken = sasBuilder.ToSasQueryParameters(delegationKey, "corpdata").ToString();

var credential = new DefaultAzureCredential();
var blobServiceClient = new BlobServiceClient(
new Uri("https://corpdata.blob.core.windows.net"), credential);

UserDelegationKey delegationKey = await blobServiceClient.GetUserDelegationKeyAsync(
startsOn: DateTimeOffset.UtcNow.AddMinutes(-15),
expiresOn: DateTimeOffset.UtcNow.AddMinutes(45)
);

var sasBuilder = new BlobSasBuilder()
{
BlobContainerName = "secure-docs",
Resource = "c",
StartsOn = DateTimeOffset.UtcNow.AddMinutes(-15),
ExpiresOn = DateTimeOffset.UtcNow.AddMinutes(30),
Protocol = SasProtocol.HttpsAndHttp,
IPRange = SasIPRange.Parse("198.51.100.72")
};
sasBuilder.SetPermissions(BlobSasPermissions.Write);

string sasToken = sasBuilder.ToSasQueryParameters(delegationKey, "corpdata").ToString();

Show answer & explanation

Answer: var credential = new DefaultAzureCredential();
var blobServiceClient = new BlobServiceClient(
new Uri("https://corpdata.blob.core.windows.net"), credential);

UserDelegationKey delegationKey = await blobServiceClient.GetUserDelegationKeyAsync(
startsOn: DateTimeOffset.UtcNow.AddMinutes(-15),
expiresOn: DateTimeOffset.UtcNow.AddMinutes(45)
);

var sasBuilder = new BlobSasBuilder()
{
BlobContainerName = "secure-docs",
BlobName = "confidential.pdf",
Resource = "b",
StartsOn = DateTimeOffset.UtcNow.AddMinutes(-15),
ExpiresOn = DateTimeOffset.UtcNow.AddMinutes(30),
Protocol = SasProtocol.Https,
IPRange = SasIPRange.Parse("198.51.100.72")
};
sasBuilder.SetPermissions(BlobSasPermissions.Write);

string sasToken = sasBuilder.ToSasQueryParameters(delegationKey, "corpdata").ToString();

Answer

The code segment that uses DefaultAzureCredential to retrieve a UserDelegationKey, sets the start time in the past to allow for clock skew, restricts the protocol to HTTPS, limits the scope to the specific blob resource, and signs the token with the delegation key.

The correct code segment uses DefaultAzureCredential to obtain a UserDelegationKey from Azure Active Directory, complying with the requirement to avoid account keys. It sets the scope specifically to the blob resource by assigning Resource to 'b' and specifying the BlobName. It handles clock skew by setting the start time to 15 minutes in the past, ensures HTTPS-only connections, and limits access to the specified client IP range.

Step-by-Step Solution

Identify the authentication requirement.

Managed Identity authentication must be used.

Storage account access keys are forbidden by the security policy.

Select the correct SAS type.

User Delegation SAS.

A User Delegation SAS is secured using Azure Active Directory credentials rather than storage account keys.

Configure the resource scope.

Set BlobName to 'confidential.pdf' and Resource to 'b'.

Least-privilege requires limiting access to the specific blob, not the entire container.

Configure protocol, network, and clock skew properties.

Set Protocol to Https, IPRange to the client's IP, and StartsOn with a negative offset.

Connections must be HTTPS-only, restricted to the client's IP, and a negative offset on StartsOn allows for clock skew so the token is usable immediately.

Sign and generate the SAS token.

Call ToSasQueryParameters passing the UserDelegationKey.

The token must be signed using the obtained delegation key to be authorized.

Key Concept

Shared Access Signatures (SAS) allow for secure, delegated access to Azure Storage resources. A User Delegation SAS is secured using Azure AD credentials. For security and reliability, SAS tokens must implement least-privilege, enforce HTTPS, restrict IP ranges, and subtract a brief duration from the start time to mitigate clock skew issues.

Question 95Question →

A developer is implementing a partner integration service that authenticates users across several external enterprise clients using Microsoft Entra ID. The configuration must allow sign-ins from any corporate directory but must explicitly block users signing in with personal Microsoft accounts.

Which combination of the `signInAudience` value in the application manifest and the OAuth 2.0 authorization endpoint must be configured?

Set `signInAudience` to `AzureADMultipleOrgs` and use the `https://login.microsoftonline.com/common/oauth2/v2.0/authorize` endpoint.

Set `signInAudience` to `AzureADMultipleOrgs` and use the `https://login.microsoftonline.com/organizations/oauth2/v2.0/authorize` endpoint.

Set `signInAudience` to `AzureADandPersonalMicrosoftAccount` and use the `https://login.microsoftonline.com/common/oauth2/v2.0/authorize` endpoint.

Set `signInAudience` to `AzureADMyOrg` and use the `https://login.microsoftonline.com/organizations/oauth2/v2.0/authorize` endpoint.

Show answer & explanation

Answer: Set `signInAudience` to `AzureADMultipleOrgs` and use the `https://login.microsoftonline.com/organizations/oauth2/v2.0/authorize` endpoint.

Answer

Set `signInAudience` to `AzureADMultipleOrgs` and use the `https://login.microsoftonline.com/organizations/oauth2/v2.0/authorize` endpoint.

The correct configuration is to set `signInAudience` to `AzureADMultipleOrgs` and use the `/organizations` endpoint. The `AzureADMultipleOrgs` value limits the sign-in audience to work or school accounts from any Microsoft Entra ID tenant, excluding personal accounts. Using the `/organizations` endpoint ensures that the authentication flow restricts user discovery and entry to organizational directories only.

Step-by-Step Solution

Determine the required user audience restriction

Identify that only organizational (work or school) accounts are allowed, and personal Microsoft accounts must be blocked.

This requirement dictates the choice of the `signInAudience` value in the application registration.

Select the correct `signInAudience` parameter

Configure `signInAudience` to `AzureADMultipleOrgs`.

This setting allows users from any organizational Microsoft Entra ID tenant while excluding personal Microsoft accounts.

Select the corresponding authority endpoint for authentication

Use the `/organizations` endpoint: `https://login.microsoftonline.com/organizations/oauth2/v2.0/authorize`.

The `/organizations` endpoint restricts sign-in attempts to organizational tenants only. The `/common` endpoint would allow personal accounts to attempt to sign in, which does not satisfy the requirement to block them at the endpoint level.

Key Concept

Configuring multi-tenant Microsoft Entra ID application registration properties and authority endpoints to control user sign-in audience.

Question 96Question →

You are configuring an ASP.NET Core web application hosted on an Azure App Service to retrieve data from an Azure SQL Database. The application must authenticate using a user-assigned managed identity. You need to configure the required identity and database access. Which five actions should you perform in sequence? To answer, arrange the actions in the correct order.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To configure a user-assigned managed identity for an Azure App Service to access Azure SQL Database, the correct sequence of actions is: 1. Create a user-assigned managed identity in Microsoft Entra ID. 2. Associate the user-assigned managed identity with the Azure App Service web app. 3. Connect to the Azure SQL Database by using a Microsoft Entra ID administrator account. 4. Run the SQL command to create a database user mapped to the user-assigned managed identity. 5. Run the SQL command to add the database user to the db_datareader role.

The correct sequence starts with creating the user-assigned managed identity and associating it with the App Service web app. Next, you must connect to the Azure SQL Database using a Microsoft Entra ID administrator account to have the necessary privileges to provision external users. Inside the SQL Database, you run a SQL query to create a user mapped to the managed identity, and finally run another query to add that user to the db_datareader role to grant the application access.

Step-by-Step Solution

Create the user-assigned managed identity

The identity exists in Microsoft Entra ID and has a unique client ID and principal ID.

An identity must exist before it can be assigned to resources or referenced in permissions.

Associate the user-assigned managed identity with the App Service

The App Service is configured to use the identity for outbound authentications.

This allows the application hosted on the App Service to request access tokens for this identity.

Connect to Azure SQL Database using a Microsoft Entra ID administrator

Established database connection with administrative privileges capable of creating Entra-based users.

Standard SQL logins do not have permissions to query Microsoft Entra ID to validate and create database users from external providers.

Create a SQL database user mapped to the managed identity

A database user represents the managed identity within the database context.

A database user is required to grant database-level permissions to the identity.

Grant the database user the db_datareader role

The database user is added to the role, giving it read access.

This authorizes the identity to read data from the database.

Key Concept

Provisioning, assigning, and authorizing a user-assigned managed identity to access Azure SQL Database

Question 97Question →

An organization needs to allow a partner application to read data from a specific Azure Blob Storage container named `reports`. You must configure a Shared Access Signature (SAS) token that meets the following security requirements:

- Allows read-only (least-privilege) access to the `reports` container only.
- Restricts access to a specific external IP address range: $198.51.100.0/24$ .
- Restricts communication to the HTTPS protocol only.
- Begins validity immediately and expires in exactly $2$ hours.
- Uses Microsoft Entra ID credentials to secure and sign the token, avoiding the use of the storage account key.

Which type of Shared Access Signature (SAS) must you generate?

User Delegation SAS

Service SAS

Account SAS

Stored Access Policy

Show answer & explanation

Answer: User Delegation SAS

Answer

User Delegation SAS

The correct answer is the User Delegation SAS. A User Delegation SAS is signed with Microsoft Entra ID credentials rather than the storage account key. It utilizes a user delegation key obtained from the Microsoft Entra ID token to sign the SAS, providing enhanced security and auditing capability while satisfying the constraint to restrict access to a single container with specific IP ranges, protocols, and lifetime bounds.

Step-by-Step Solution

Identify the signing credential constraint from the requirements.

The SAS token must be secured and signed using Microsoft Entra ID credentials instead of the storage account access key.

This is a key security differentiator among Azure Storage SAS types.

Evaluate the signing mechanism for each SAS type.

Service SAS and Account SAS are signed using storage account access keys. User Delegation SAS is signed using a user delegation key acquired via Microsoft Entra ID.

To determine which token type matches the signing constraint.

Select the token type that matches all requirements, including container-level scope.

A User Delegation SAS supports container-level scope, HTTPS restriction, IP filters, and is signed using Microsoft Entra ID credentials.

It fulfills all the specified security and protocol requirements.

Key Concept

Selecting the correct type of Shared Access Signature based on credentials and scope requirements

Question 98Question →

An organization hosting a containerized API on Azure App Service (webapp-prod) needs to access database connection strings stored in Azure Key Vault (kv-prod). The Key Vault uses the Azure Role-Based Access Control (Azure RBAC) permission model. To comply with security policies, the API must authenticate using a user-assigned managed identity named id-prod instead of a system-assigned identity. Which three actions should you perform to configure the application and Key Vault to retrieve the secrets using the user-assigned managed identity? (Select three.)

Select all that apply

Assign the Key Vault Secrets User role to the id-prod managed identity at the key vault scope.

Associate the id-prod managed identity with webapp-prod by adding it to the App Service's identity configuration.

Set the keyVaultReferenceIdentity property of webapp-prod to the Resource ID of id-prod.

Assign the Reader role to the id-prod managed identity at the key vault scope.

Set the keyVaultReferenceIdentity property of webapp-prod to the Application (Client) ID of id-prod.

Assign the Key Vault Contributor role to the id-prod managed identity at the key vault scope.

Show answer & explanation

Answer: Assign the Key Vault Secrets User role to the id-prod managed identity at the key vault scope.; Associate the id-prod managed identity with webapp-prod by adding it to the App Service's identity configuration.; Set the keyVaultReferenceIdentity property of webapp-prod to the Resource ID of id-prod.

Answer

To configure Key Vault secret retrieval using a user-assigned identity, you must assign the Key Vault Secrets User role to the identity, associate the identity with the App Service, and set the keyVaultReferenceIdentity property of the App Service to the identity's Resource ID.

To retrieve secrets from a Key Vault configured with Azure RBAC using a user-assigned managed identity, you must first assign the Key Vault Secrets User role to the identity to grant data plane read access. Second, you must associate the user-assigned identity with the App Service so that the host environment can access the identity. Finally, you must configure the App Service to use this specific identity for resolving Key Vault references by setting the keyVaultReferenceIdentity property to the Azure Resource Manager (ARM) Resource ID of the identity.

Step-by-Step Solution

Assign the appropriate Azure RBAC role to the managed identity.

The user-assigned identity id-prod is granted the Key Vault Secrets User role.

Key Vault RBAC separates management plane roles from data plane roles. The identity needs data plane permissions to retrieve secret values.

Associate the user-assigned identity with the App Service web app.

The App Service is configured to load and present the id-prod identity during credential requests.

An App Service cannot use a user-assigned managed identity until the identity is explicitly added to the app's resource configuration.

Configure Key Vault references to use the user-assigned identity.

The keyVaultReferenceIdentity App Service property is set to the Resource ID of id-prod.

By default, App Service Key Vault references use the system-assigned managed identity. To use a user-assigned identity, the app must be instructed which identity to use via its Resource ID.

Key Concept

Azure Key Vault Secret Management with Azure RBAC and User-Assigned Managed Identity

Question 99Question →

A Python-based background worker runs in an Azure Function App named func-worker-prod. The Function App needs to retrieve a database password from an Azure Key Vault named kv-secrets-prod.

You configure a user-assigned managed identity named id-worker-prod for the Function App and grant it the Key Vault Secrets User role on kv-secrets-prod. The DbPassword application setting in the Function App is currently configured as follows:

@KeyVault(SecretUri=https://kv-secrets-prod.vault.azure.net/secrets/db-password)

At runtime, the Python worker reads the DbPassword environment variable as the plain text reference string rather than the actual secret value. Which two configuration updates must you perform to ensure the Key Vault reference resolves correctly?

Select all that apply

Create a new application setting named keyVaultReferenceIdentity and set its value to the resource ID of the user-assigned managed identity.

Update the value of the DbPassword application setting to @Microsoft.KeyVault(SecretUri=https://kv-secrets-prod.vault.azure.net/secrets/db-password/).

Create a new application setting named keyVaultReferenceIdentity and set its value to the client ID of the user-assigned managed identity.

Update the value of the DbPassword application setting to @Microsoft.KeyVault(SecretUri=https://kv-secrets-prod.vault.azure.net/secrets/db-password).

Create a new application setting named AZURE_CLIENT_ID and set its value to the client ID of the user-assigned managed identity.

Grant the user-assigned managed identity the Key Vault Contributor role on kv-secrets-prod.

Show answer & explanation

Answer: Create a new application setting named keyVaultReferenceIdentity and set its value to the resource ID of the user-assigned managed identity.; Update the value of the DbPassword application setting to @Microsoft.KeyVault(SecretUri=https://kv-secrets-prod.vault.azure.net/secrets/db-password/).

Answer

Create a new application setting named keyVaultReferenceIdentity set to the identity's resource ID, and update the DbPassword setting to use the correct @Microsoft.KeyVault syntax with a trailing slash.

To successfully resolve a Key Vault reference using a user-assigned managed identity in Azure Functions, you must update the reference to use the correct syntax and point the App Service runtime to the correct identity. The correct syntax must begin with @Microsoft.KeyVault and include a trailing slash at the end of the URL if no secret version is specified. Additionally, you must add the keyVaultReferenceIdentity application setting and set it to the resource ID of the user-assigned managed identity.

Step-by-Step Solution

Correct the Key Vault reference syntax.

Changing the prefix from @KeyVault to @Microsoft.KeyVault and adding a trailing slash since no version is specified.

The App Service runtime requires the full @Microsoft.KeyVault prefix and a trailing slash for versionless secret URIs to correctly parse and resolve the reference.

Configure the keyVaultReferenceIdentity setting.

Adding the keyVaultReferenceIdentity setting with the user-assigned identity's resource ID.

If an app has only a user-assigned managed identity, the App Service platform needs the resource ID of that identity specified in the keyVaultReferenceIdentity setting to fetch the secret from Key Vault.

Key Concept

Key Vault references in App Service and Azure Functions require correct syntax (including trailing slash for versionless URIs) and explicit configuration of the keyVaultReferenceIdentity setting when using user-assigned managed identities.

Question 100Question →

You are developing an ASP.NET Core Web API that runs in an autoscaling Azure App Service plan. The Web API authenticates users using the Microsoft Identity Platform. It must make downstream calls to Microsoft Graph on behalf of the signed-in user by using the OAuth 2.0 On-Behalf-Of (OBO) flow.

During load testing, you observe that downstream calls experience intermittent latency and fail with HTTP 429 (Too Many Requests) errors from Microsoft Entra ID. You determine that because the App Service scales out to multiple instances, each instance maintains a separate in-memory token cache, resulting in frequent, redundant token exchange requests to Microsoft Entra ID.

You need to resolve the performance issue and prevent rate-limiting while maintaining the signed-in user's context for Microsoft Graph calls.

Which of the following configuration changes should you implement?

Enable a system-assigned managed identity on the Azure App Service host to bypass user-delegated token acquisition for Microsoft Graph.

Generate a Shared Access Signature (SAS) token with appropriate delegated permissions and pass it in the authorization header of downstream requests.

Configure a distributed cache (such as Azure Cache for Redis) and register it in the application startup using the AddDistributedTokenCaches method.

Write custom middleware to extract, encrypt, and store the user's delegated access tokens inside Azure Key Vault Secrets.

Show answer & explanation

Answer: Configure a distributed cache (such as Azure Cache for Redis) and register it in the application startup using the AddDistributedTokenCaches method.

Answer

Configure a distributed cache (such as Azure Cache for Redis) and register it in the application startup using the AddDistributedTokenCaches method.

Configuring a distributed cache (such as Azure Cache for Redis) and registering it using the `AddDistributedTokenCaches` method is correct because it shares the token cache across all instances of the scaled-out App Service. When one instance exchanges the user's incoming assertion for a downstream token using the On-Behalf-Of flow, the acquired token is stored in the shared distributed cache. Subsequent requests from the same user handled by other instances will read the token directly from the distributed cache, preventing redundant token exchange calls to Microsoft Entra ID and avoiding HTTP 429 throttling.

Step-by-Step Solution

Analyze the token caching behavior in a multi-instance Web API environment.

Realized that default in-memory token caching is limited to individual hosts, leading to cold caches on new scale-out instances and resulting in redundant OAuth 2.0 OBO requests to Microsoft Entra ID.

To identify why rate-limiting and performance degradation are occurring under load.

Select a shared token cache strategy that spans across all application instances.

Chose distributed token caching utilizing an external store such as Azure Cache for Redis or SQL Server.

A shared cache ensures that once an access token is acquired for a user, any scaled-out instance can access and reuse it, avoiding redundant OBO token exchanges.

Added `AddDistributedTokenCaches` to the authentication builder chain in the application's startup file.

This configures the Microsoft.Identity.Web library to write and read tokens from the registered `IDistributedCache` provider instead of the default in-memory cache.

Key Concept

Distributed Token Cache Serialization in MSAL / Microsoft.Identity.Web

Estimated Time:2m 30s

PreviousPage 5 / 11Next

Implement Azure Security

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept