Examkin

Implement Azure Security

203 questions

All types203Multiple choice102Multiple select71Ordering30
Question 121Question →

You are developing an ASP.NET Core web application hosted on an Azure App Service. The application must retrieve database connection strings from an Azure Key Vault. The security architecture requires that:

1. The application must authenticate to Azure Key Vault without storing any credentials or secrets in code or configuration files.
2. The identity used for authentication must be shared across multiple web applications in the same environment to simplify access control management.

Which configuration should you implement to meet these requirements?

Show answer & explanation

Answer: Create a user-assigned managed identity, assign it the Key Vault Secrets User role on the Key Vault, associate the identity with the App Service, and configure the client ID in the application settings.

Answer

Create a user-assigned managed identity, assign it the Key Vault Secrets User role on the Key Vault, associate the identity with the App Service, and configure the client ID in the application settings.
The correct option is to create a user-assigned managed identity, assign it the Key Vault Secrets User role, associate it with the App Service, and configure the client ID in the settings. This ensures the identity is shared across resources without storing secrets and allows DefaultAzureCredential to resolve the specified identity.

Step-by-Step Solution

1
Determine the type of managed identity that supports sharing across multiple Azure resources.
Identify that user-assigned managed identities are standalone Azure resources that can be shared across multiple App Services, unlike system-assigned managed identities which are tied 1:1 to a single resource.
This satisfies the requirement to share the identity and simplify access control management.
2
Select the correct permission assignment method to allow the identity to read secrets from Key Vault.
Assign the Key Vault Secrets User role to the user-assigned managed identity.
This grants the identity the minimum required permission to retrieve secret values without requiring administrative access.
3
Associate the identity with the App Service and configure the application to target it.
Add the user-assigned identity to the App Service, and set the client ID in the application settings so that DefaultAzureCredential in the code knows which identity to use.
This completes the binding and allows the SDK to resolve the correct token.

Key Concept

User-assigned managed identities allow for shared access across multiple Azure resources with an independent lifecycle from the resource, whereas system-assigned managed identities are restricted to a single resource.
Question 122Question →

An organization is migrating an ASP.NET Core web application to Azure App Service. The application must retrieve a database connection string from Azure Key Vault `kv-prod` using Azure App Configuration. The web application is configured to use a user-assigned managed identity named `id-app-prod`. The Azure Key Vault uses Azure role-based access control (Azure RBAC) for authorization. You need to configure the App Configuration key-vault reference and ensure the App Service web application can retrieve the database connection string. Which two configuration steps must you perform? (Select TWO)

Select all that apply

Show answer & explanation

Answer: Configure a key-value pair in Azure App Configuration with a value of `@Microsoft.KeyVault(SecretUri=https://kv-prod.vault.azure.net/secrets/db-conn-string)`; Assign the 'Key Vault Secrets User' Azure RBAC role to the user-assigned managed identity `id-app-prod` for the Key Vault `kv-prod`

Answer

Configure a key-value pair in Azure App Configuration with a value using the `@Microsoft.KeyVault(SecretUri=...)` syntax, and assign the 'Key Vault Secrets User' Azure RBAC role to the user-assigned managed identity `id-app-prod` on the Key Vault.
The correct configuration requires using the exact `@Microsoft.KeyVault(SecretUri=...)` syntax in Azure App Configuration so the client provider knows to retrieve the secret value from Azure Key Vault. In addition, because the Key Vault uses Azure RBAC for authorization, the application's user-assigned managed identity must be granted the 'Key Vault Secrets User' role. The client application resolves these references at runtime using its own credentials, not the App Configuration service principal.

Step-by-Step Solution

1
Configure the key-value pair in Azure App Configuration.
The reference uses the prefix `@Microsoft.KeyVault(SecretUri=...)` pointing to the Key Vault secret URI.
This instructs the App Configuration client library to resolve the secret directly from Azure Key Vault.
2
Configure authorization on the Azure Key Vault.
The user-assigned managed identity `id-app-prod` is granted the 'Key Vault Secrets User' role on the vault.
Because the Key Vault uses Azure RBAC, the web app's identity must have read access to the secrets.

Key Concept

Azure App Configuration Key Vault References and Azure RBAC Authorization
Question 123Question →

You are developing a daemon application named 'BillingJob' that runs nightly as a background service on an Azure Virtual Machine. The application must query Microsoft Graph to retrieve the profile details of all users in the Microsoft Entra ID tenant to generate monthly billing reports. No user is signed in when the application runs.

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

Which configuration should you implement?

Show answer & explanation

Answer: Add the Microsoft Graph User.Read.All Application permission to the application registration, and grant admin consent for the tenant.

Answer

Add the Microsoft Graph User.Read.All Application permission to the application registration, and grant admin consent for the tenant.
Because the application runs as a background daemon service without user interaction, it cannot acquire a user context and must use Application permissions. The User.Read.All permission allows reading full user profiles for all accounts, and because it is an Application permission, it requires tenant administrator consent. This satisfies the requirement using the principle of least privilege.

Step-by-Step Solution

1
Determine the application type and interaction context.
The application runs as a background service (daemon) without any signed-in user.
This establishes that Delegated permissions cannot be used, and Application permissions (app roles) are required.
2
Identify the required data and the corresponding Microsoft Graph permission.
The application needs to read user profile details for all users in the tenant, which maps to the User.Read.All permission.
Using User.Read.All is the most restrictive permission that satisfies the requirement, aligning with the principle of least privilege.
3
Determine the consent requirement for the selected permission.
Application permissions for User.Read.All require administrator consent.
Microsoft Entra ID requires tenant administrator approval for application permissions that access organization-wide directory data.

Key Concept

Daemon applications running without user context must use Application permissions and require admin consent for directory-wide scopes.
Question 124Question →

You are developing a secure .NET web application using the `Azure.Storage.Blobs` SDK (v12). The application must generate a Shared Access Signature (SAS) token for an Azure Blob Storage container named `invoices`.

The security requirements are as follows:
- The token must be signed using Microsoft Entra ID credentials (a User Delegation SAS) instead of the storage account key.
- The client must only be allowed to read and list the contents of the container.
- The SAS must restrict access to requests originating from the client IP address range `198.51.100.0/24`.
- The token must enforce the use of HTTPS only.
- The token must account for potential clock skew by setting the start time to 15 minutes before the current time.

You write the following method to generate the SAS token:

csharp
public async Task<string> GenerateContainerSasUriAsync(BlobServiceClient client, string containerName, string accountName)
{
UserDelegationKey delegationKey = await client.GetUserDelegationKeyAsync(
DateTimeOffset.UtcNow.AddMinutes(-15),
DateTimeOffset.UtcNow.AddHours(2)
);

BlobSasBuilder builder = new BlobSasBuilder()
{
BlobContainerName = containerName,
Resource = "c",
StartsOn = DateTimeOffset.UtcNow.AddMinutes(-15),
ExpiresOn = DateTimeOffset.UtcNow.AddHours(2)
};

// INSERT CODE HERE

BlobSasQueryParameters sasParams = builder.ToSasQueryParameters(delegationKey, accountName);
return $"{client.Uri}{containerName}?{sasParams}";
}

Which code segment should you insert to complete the method and meet the requirements?

Show answer & explanation

Answer: builder.SetPermissions(BlobContainerSasPermissions.Read | BlobContainerSasPermissions.List);
builder.Protocol = SasProtocol.Https;
builder.IPRange = IPAddressRange.Parse("198.51.100.0/24");

Answer

The code segment that calls builder.SetPermissions with BlobContainerSasPermissions.Read and BlobContainerSasPermissions.List, configures builder.Protocol to SasProtocol.Https, and parses the correct IP range.
The correct option properly uses BlobContainerSasPermissions.Read | BlobContainerSasPermissions.List to grant both read and list permissions at the container level. It also restricts the communication to HTTPS-only using SasProtocol.Https and parses the IP range correctly using IPAddressRange.Parse.

Step-by-Step Solution

1
Select the correct permission enum class for the target resource level.
BlobContainerSasPermissions must be used because the SAS applies to a container (Resource = "c") and requires the List permission, which is not available in the blob-specific BlobSasPermissions class.
Ensures compilation succeeds and scope constraints match the container level.
2
Enforce the security protocol configuration.
builder.Protocol must be explicitly set to SasProtocol.Https.
By default, a SAS might allow both HTTP and HTTPS (HttpsAndHttp). Enforcing HTTPS-only mitigates data transit intercept risks.
3
Restrict request origins using IP filtering.
Assign IPAddressRange.Parse("198.51.100.0/24") to builder.IPRange.
This limits token usage strictly to the defined client subnet.

Key Concept

Configuring Container-scoped User Delegation Shared Access Signatures using Azure.Storage.Blobs SDK
Estimated Time:2m 30s
Question 125Question →

You are designing a security architecture for three Azure Function apps that must retrieve database connection secrets from a single Azure Key Vault. The solution must use managed identities, minimize administrative overhead, and grant only the minimum permissions required to read the secrets.

Which two configuration steps should you perform?

Select all that apply

Show answer & explanation

Answer: Create a single user-assigned managed identity and associate its resource ID with all three Function apps using the userAssignedIdentities configuration property.; Assign the Key Vault Secrets User role to the user-assigned managed identity at the Key Vault scope.

Answer

To implement the solution, you should create a single user-assigned managed identity, associate its resource ID with all three Function apps, and assign the Key Vault Secrets User role to this identity at the Key Vault scope.
A user-assigned managed identity is a standalone Azure resource with its own lifecycle. Because it is independent, it can be shared across multiple resources like the three Function apps. This reduces overhead since we only need to manage a single identity and configure permissions once on the Key Vault. The Key Vault Secrets User role is the minimum role required to retrieve the secret values.

Step-by-Step Solution

1
Determine the identity type that minimizes overhead for sharing access.
Select a user-assigned managed identity since it can be shared among multiple Function apps, requiring only one RBAC role assignment instead of three.
System-assigned identities cannot be shared across resources, which would lead to duplicate role assignments and increased management overhead.
2
Identify the minimum required RBAC role for reading secrets.
Select the Key Vault Secrets User role.
This role allows the identity to read secret values without granting permissions to manage the Key Vault itself.
3
Assign the selected role to the identity.
The user-assigned managed identity is granted Key Vault Secrets User access at the scope of the Key Vault.
This establishes authorization for the shared identity to pull database secrets securely.

Key Concept

User-Assigned Managed Identities and Least-Privilege RBAC Roles
Question 126Question →

You are developing a C# daemon application that runs on an Azure Virtual Machine. The application must automate the renewal of an Azure Key Vault certificate named 'ssl-cert' which is issued by a non-integrated internal Certificate Authority (CA).

The application must run under a user-assigned managed identity named 'app-identity'. The renewal workflow requires:
1. Retrieving the pending Certificate Signing Request (CSR) generated by Key Vault.
2. Submitting the CSR to the CA and receiving the signed certificate.
3. Merging the signed certificate back into Key Vault to complete the process.

You need to configure the required permissions and implement the code using the Azure.Security.KeyVault.Certificates library.

Which of the following configurations and code segments should you implement?

Show answer & explanation

Answer: Assign the 'app-identity' to the Virtual Machine and grant it the Key Vault Certificates Officer Azure RBAC role. Use the following C# code:

var client = new CertificateClient(new Uri("https://vault.vault.azure.net/"), new DefaultAzureCredential());
CertificateOperation operation = await client.GetCertificateOperationAsync("ssl-cert");
byte[] csr = operation.Csr;
// Submit to CA and receive signedCertBytes
await client.MergeCertificateAsync(new MergeCertificateOptions("ssl-cert", new[] { signedCertBytes }));

Answer

To perform certificate operations such as retrieving pending operations and merging certificates in Azure Key Vault, the application identity must possess certificate permissions (like the Key Vault Certificates Officer Azure RBAC role) rather than secret permissions. Furthermore, the user-assigned managed identity must be associated with the virtual machine hosting the application. The Azure.Security.KeyVault.Certificates SDK requires using GetCertificateOperationAsync to access the pending CSR and MergeCertificateAsync to upload the signed public certificate.
To complete the renewal of a certificate from a non-integrated CA, the application must fetch the pending CSR using GetCertificateOperationAsync, sign it at the CA, and then call MergeCertificateAsync to combine the signed certificate with the private key stored in Key Vault. Additionally, the user-assigned managed identity must be associated with the VM and granted the Key Vault Certificates Officer role to authorize the action.

Step-by-Step Solution

1
Ensure the user-assigned managed identity is attached to the Virtual Machine hosting the application.
The Virtual Machine environment can retrieve Azure AD tokens on behalf of the user-assigned managed identity.
DefaultAzureCredential attempts to acquire a token using the associated identities on the hosting environment.
2
Grant the user-assigned managed identity the 'Key Vault Certificates Officer' role (or appropriate certificate-level Access Policy permissions).
The identity is authorized to get certificate operations and merge certificates.
Secrets permissions do not authorize certificate lifecycle management actions.
3
Use GetCertificateOperationAsync to retrieve the pending CSR.
A CertificateOperation object containing the DER-encoded CSR is retrieved.
Key Vault generates the CSR and retains the private key during the initial certificate creation stage.
4
Use MergeCertificateAsync to upload the signed certificate from the CA.
The signed public key is combined with the private key stored inside Key Vault, completing the certificate.
For non-integrated CAs, merging completes the pending renewal process.

Key Concept

Azure Key Vault Certificate Lifecycle and Renewal for Non-Integrated CAs
Question 127Question →

An organization is implementing a client-side Single Page Application (SPA) named ClientConnect. The application must authenticate users using Microsoft Entra ID and access a secure downstream web API named DataAPI on behalf of the signed-in user. The DataAPI exposes a custom scope named Data.Write.

You register both ClientConnect and DataAPI in Microsoft Entra ID.

Which two configuration steps should you perform in Microsoft Entra ID to implement the required permissions and consent? Select two.

Select all that apply

Show answer & explanation

Answer: In the App Registration for ClientConnect, add the custom scope Data.Write from DataAPI as a Delegated permission.; In the App Registration for DataAPI, define the custom scope Data.Write under the Expose an API section.

Answer

In the App Registration for ClientConnect, add the custom scope Data.Write from DataAPI as a Delegated permission; and in the App Registration for DataAPI, define the custom scope Data.Write under the Expose an API section.
To access the custom downstream web API on behalf of a signed-in user, two configurations must be met: First, the target web API (DataAPI) must expose the scope by defining it in the Expose an API section. Second, the client application (ClientConnect) must request access by adding that scope as a Delegated permission. This maintains the user context flow.

Step-by-Step Solution

1
Expose the custom scope in the downstream API registration.
The Data.Write scope is defined in the registration of DataAPI, allowing other applications to request it.
Before a client can request permissions for a custom API, the API must explicitly declare the scopes it supports.
2
Add the exposed scope as a Delegated permission to the client application registration.
ClientConnect is configured with a delegated permission to request Data.Write on behalf of the signed-in user.
Since ClientConnect is a Single Page Application running in the context of the user, it requires delegated permissions to act on the user's behalf.

Key Concept

Delegated permissions and custom API scopes in Microsoft Entra ID
Question 128Question →

You are developing a native mobile application named FleetApp that allows delivery drivers to view their own calendar events from Microsoft Graph and upload telemetry data to a custom backend web API named RouteAPI. You register RouteAPI in Microsoft Entra ID and expose a custom scope named Telemetry.Write.

You register FleetApp in Microsoft Entra ID. The application must perform all actions on behalf of the signed-in driver, allow drivers to consent to permissions themselves, and adhere to the principle of least privilege.

Which permissions should you configure for the FleetApp registration?

Show answer & explanation

Answer: Delegated permission Calendars.Read for Microsoft Graph, and Delegated permission Telemetry.Write for RouteAPI

Answer

Delegated permission Calendars.Read for Microsoft Graph, and Delegated permission Telemetry.Write for RouteAPI
The correct configuration uses Delegated permissions for both APIs because the mobile application acts on behalf of a signed-in user (the driver). By selecting Calendars.Read instead of Calendars.Read.All, the application adheres to the principle of least privilege and allows the drivers to consent to the permissions themselves, as directory-level read permissions are not required.

Step-by-Step Solution

1
Analyze the client application context and user presence requirement.
The application runs on a mobile device and must perform actions using the identity of a signed-in user (the driver) and allow self-consent.
This determines that Delegated permissions (which run in the context of a signed-in user) must be used instead of Application permissions (which run as a daemon or background service without a user).
2
Evaluate the required scope level for Microsoft Graph access under the principle of least privilege.
The driver only needs to view their own calendar events, so the Calendars.Read permission is sufficient.
Using Calendars.Read.All would allow access to all users' calendars, which requires admin consent and violates the principle of least privilege.
3
Select the correct permission type and scope for the custom backend API.
FleetApp needs delegated permission for the custom scope Telemetry.Write exposed by RouteAPI.
Since the write operation is initiated by the signed-in driver, the driver must delegate their authority to the client application using a delegated permission.

Key Concept

Delegated vs. Application permissions and least-privilege scoping in Microsoft Entra ID app registrations.
Estimated Time:1m 30s
Question 129Question →

You are deploying a Node.js microservice to an Azure Kubernetes Service (AKS) cluster. The microservice uses a user-assigned managed identity named `mi-node-app` via workload identity.

The microservice must load configuration settings from an Azure App Configuration store named `appconfig-prod`. The store contains several configurations, including Key Vault references pointing to database credentials in an Azure Key Vault named `kv-prod`.

You need to configure the minimum required role assignments to allow the microservice to successfully fetch all configurations and resolve the Key Vault references.

Which two actions should you perform? Select two.

Select all that apply

Show answer & explanation

Answer: Assign the App Configuration Data Reader role on `appconfig-prod` to the `mi-node-app` user-assigned managed identity.; Assign the Key Vault Secrets User role on `kv-prod` to the `mi-node-app` user-assigned managed identity.

Answer

Assign the App Configuration Data Reader role on `appconfig-prod` to the `mi-node-app` user-assigned managed identity, and assign the Key Vault Secrets User role on `kv-prod` to the `mi-node-app` user-assigned managed identity.
The microservice's user-assigned managed identity (`mi-node-app`) needs direct read access to the App Configuration store to retrieve configuration key-values and Key Vault reference metadata. It also needs direct access to the Key Vault because Key Vault references are resolved on the client side by the application's SDK.

Step-by-Step Solution

1
Identify the identity used by the microservice.
The microservice authenticates using the workload identity associated with the `mi-node-app` user-assigned managed identity.
Permissions must be granted to the specific identity used by the workload running in the AKS cluster.
2
Assign the necessary role to read configuration metadata.
Grant the App Configuration Data Reader role on `appconfig-prod` to `mi-node-app`.
This allows the application SDK to fetch the keys and the Key Vault reference metadata from Azure App Configuration.
3
Assign the necessary role to resolve Key Vault secrets.
Grant the Key Vault Secrets User role on `kv-prod` to `mi-node-app`.
Key Vault references are resolved client-side by the application's client library, requiring direct read access to the secrets in Key Vault.

Key Concept

Key Vault references in Azure App Configuration are resolved client-side by the application, requiring the application's identity to have read permissions on both the App Configuration store and the target Key Vault.
Question 130Question →

A secure C# Web API is hosted on an Azure App Service instance that has a system-assigned managed identity enabled. The Web API needs to retrieve a database connection string stored as a secret in an Azure Key Vault named kv-prod. The Key Vault is configured to use the Azure role-based access control (Azure RBAC) permission model. During testing, the Web API receives a 403 Forbidden error when attempting to retrieve the secret. You need to resolve the authorization issue while adhering to the principle of least privilege. What should you do?

Show answer & explanation

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

Answer

Assign the Key Vault Secrets User role to the App Service's system-assigned managed identity at the Key Vault scope.
Assigning the Key Vault Secrets User role to the system-assigned managed identity at the Key Vault scope is the correct solution. Since the Key Vault uses the Azure RBAC permission model, traditional access policies are disabled. The Key Vault Secrets User role provides the minimum permissions necessary to retrieve secret values, satisfying the principle of least privilege.

Step-by-Step Solution

1
Identify the active authorization model for the Key Vault.
The Key Vault is configured to use the Azure RBAC permission model.
This determines whether to use role assignments or access policies.
2
Determine the minimum required permissions to read a secret.
The Key Vault Secrets User role is required to read secret values.
The Key Vault Secrets Officer role grants write/delete permissions and violates the principle of least privilege.
3
Assign the role to the correct identity at the appropriate scope.
Assign the Key Vault Secrets User role to the App Service's system-assigned managed identity at the Key Vault scope.
This authorizes the Web API to retrieve the connection string securely and with least privilege.

Key Concept

Azure Key Vault authorization using the Azure RBAC permission model
Question 131Question →

You are configuring a secure ASP.NET Core web application hosted in an Azure App Service to load configuration settings from an Azure App Configuration store. The configuration store contains key-values that reference secrets stored in an Azure Key Vault. You want to use a system-assigned managed identity to authenticate and authorize all access between these resources without storing credentials. In which order should you perform the steps to configure the security and connection between these services?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To configure the security and connection, you must first enable a system-assigned managed identity on the Azure App Service. Next, assign the 'App Configuration Data Reader' role to the App Service's managed identity on the App Configuration store. Then, assign the 'Key Vault Secrets User' role to the App Service's managed identity on the Key Vault. Finally, configure the App Service application settings to specify the App Configuration endpoint, and update the application startup code to initialize the configuration provider using DefaultAzureCredential.
The correct order requires establishing the system-assigned managed identity first. Once the identity exists, permissions must be assigned to it on both the Azure App Configuration store (App Configuration Data Reader) and the Azure Key Vault (Key Vault Secrets User). Finally, the App Service configuration must be updated with the endpoint, and the code updated to load configuration via DefaultAzureCredential.

Step-by-Step Solution

1
Enable system-assigned managed identity on the App Service.
A service principal is registered in Microsoft Entra ID for the App Service instance.
You must establish the identity principal in the tenant before assigning role-based access control permissions to it.
2
Grant 'App Configuration Data Reader' to the App Service identity on the App Configuration store.
The App Service is authorized to read keys and values from the configuration store.
This permission is necessary for the App Configuration provider to read settings and identify Key Vault references.
3
Grant 'Key Vault Secrets User' to the App Service identity on the Key Vault.
The App Service is authorized to read secret values directly from the Key Vault.
Key Vault references in App Configuration are resolved on the client side by the application itself; therefore, the App Service identity needs direct read access to Key Vault.
4
Add the endpoint configuration and modify startup code to use DefaultAzureCredential.
The application successfully connects to the App Configuration store at startup and resolves secrets using its managed identity.
This connects all configured security settings to the running application code.

Key Concept

Secure App Configuration and Key Vault References using Managed Identity
Estimated Time:2m 0s
Question 132Question →

A development team is configuring a new collaboration portal registered in Microsoft Entra ID. The portal must allow users from any corporate or academic Microsoft Entra ID tenant to authenticate, while strictly blocking personal Microsoft Accounts (such as Xbox, Skype, or Outlook.com accounts).

Which combination of application manifest settings and token authority endpoints should the team implement?

Show answer & explanation

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

Answer

Set the signInAudience parameter to AzureADMultipleOrgs and use the https://login.microsoftonline.com/organizations endpoint.
Setting signInAudience to AzureADMultipleOrgs allows sign-in by users with work or school accounts from any Microsoft Entra ID tenant. Using the /organizations endpoint ensures that only users from organizational directories are allowed to authenticate, which effectively blocks personal Microsoft accounts (MSA) like Outlook.com, Skype, or Xbox Live from logging in.

Step-by-Step Solution

1
Identify the tenant requirement for the multi-tenant application.
The application needs to accept work and school accounts from any tenant but reject personal accounts.
This defines the target audience scope.
2
Configure the signInAudience parameter in the application registration manifest.
Set the signInAudience parameter to AzureADMultipleOrgs.
AzureADMultipleOrgs allows any organizational directory but excludes personal accounts at the manifest registration level.
3
Select the correct token authority endpoint for authentication requests.
Route requests to the /organizations endpoint.
The /organizations endpoint restricts authentication specifically to organizational accounts, preventing personal accounts from obtaining tokens, unlike the /common endpoint which permits both.

Key Concept

Multi-tenant Applications Configuration
Estimated Time:1m 30s
Question 133Question →

You are deploying a C# background service as an Azure Function App named func-processor-prod. The application must securely retrieve a connection string from an Azure Key Vault named kv-prod using a user-assigned managed identity named id-processor-prod. The resource ID of the user-assigned identity is /subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-prod/providers/Microsoft.ManagedIdentity/userAssignedIdentities/id-processor-prod.

You have already assigned the managed identity to the Function App and granted it the Key Vault Secrets User role on the Key Vault. You need to configure the Function App's application settings to resolve the database secret.

Which configuration steps and reference syntax must you use?

Show answer & explanation

Answer: Set the Function App's keyVaultReferenceIdentity property to the resource ID of id-processor-prod, and configure the application setting value as @Microsoft.KeyVault(SecretUri=https://kv-prod.vault.azure.net/secrets/DbConnectionString/)

Answer

Set the Function App's keyVaultReferenceIdentity property to the resource ID of the user-assigned identity, and configure the application setting value using the correct @Microsoft.KeyVault syntax with the SecretUri parameter.
The correct option properly configures the keyVaultReferenceIdentity property on the Function App to point to the resource ID of the user-assigned managed identity. It also utilizes the correct @Microsoft.KeyVault syntax referencing the SecretUri of the secret in the Key Vault, which allows the App Service/Functions runtime to retrieve the connection string value at runtime.

Step-by-Step Solution

1
Assign the user-assigned identity to the Function App and grant it Secrets User permissions in Key Vault.
The identity is authorized to access the Key Vault secrets.
Before the platform can resolve secrets, the identity must have explicit read permissions on the Key Vault.
2
Configure the keyVaultReferenceIdentity property of the Function App resource to use the resource ID of the user-assigned managed identity.
The Function App is configured to use the specified user-assigned identity to fetch references.
If an app has multiple user-assigned identities or a combination of system-assigned and user-assigned identities, the platform needs this property set to know which identity to use for reference resolution.
3
Create the app setting in the Function App using the @Microsoft.KeyVault syntax.
The configuration setting is saved and the platform resolves it to the actual secret value at runtime.
Using the @Microsoft.KeyVault(SecretUri=...) format tells the Azure App Service/Functions runtime to intercept the configuration load and inject the secret.

Key Concept

Key Vault References using User-Assigned Managed Identity
Question 134Question →

You are developing a multi-tenant web application that will be registered in Microsoft Entra ID. The application must allow authentication for users with work or school accounts from any Microsoft Entra ID tenant, as well as users with personal Microsoft accounts (such as Outlook.com or Xbox Live accounts).

Which two configurations must you implement in the application registration and code? (Select two.)

Select all that apply

Show answer & explanation

Answer: Set the signInAudience property in the application manifest to AzureADandPersonalMicrosoftAccount; Configure the authority endpoint in the application code to use https://login.microsoftonline.com/common/v2.0

Answer

To support both work/school accounts from any Microsoft Entra ID tenant and personal Microsoft accounts, you must set the signInAudience property to AzureADandPersonalMicrosoftAccount in the application manifest, and configure the authority endpoint in your code to use the /common endpoint.
The correct configurations are to set the signInAudience property to AzureADandPersonalMicrosoftAccount in the application manifest and to use the common endpoint (/common) in the authority URL. The AzureADandPersonalMicrosoftAccount setting registers the application to accept work or school accounts from any corporate directory as well as personal Microsoft accounts. In the code, the /common endpoint acts as a multiplexer that resolves the user's home tenant type, routing both organizational users and personal account users to their respective login systems.

Step-by-Step Solution

1
Determine the required audience scope
The requirements specify work or school accounts from any tenant AND personal Microsoft accounts.
This corresponds to the AzureADandPersonalMicrosoftAccount value for the signInAudience manifest property.
2
Select the correct Microsoft Entra ID manifest property configuration
Configure the application registration manifest with signInAudience set to AzureADandPersonalMicrosoftAccount.
This registers the application in Microsoft Entra ID as a multi-tenant app that also accepts personal accounts.
3
Select the correct authority endpoint for the authentication library
Configure the authority URL to use the /common tenant placeholder endpoint.
The /common endpoint is required to multiplex login requests from both organization tenants and personal Microsoft accounts.

Key Concept

Multi-tenant configuration in Microsoft Entra ID requires aligning the manifest's signInAudience with the correct authorization authority endpoint in the application code.
Estimated Time:1m 30s
Question 135Question →

A developer is configuring a multi-tenant web application in Microsoft Entra ID. The application manifest has the signInAudience parameter configured as AzureADMultipleOrgs. The developer wants to configure the authentication middleware in the application to redirect users to the correct Microsoft identity platform endpoint so that users from any organizational tenant can sign in, but personal Microsoft accounts (such as Xbox or Outlook accounts) are excluded. Which authority URL should the developer configure for the authentication endpoint?

Show answer & explanation

Answer: https://login.microsoftonline.com/organizations

Answer

https://login.microsoftonline.com/organizations
The authority URL containing 'organizations' is the correct endpoint because it allows users with work or school accounts from any Microsoft Entra ID tenant to authenticate, matching the AzureADMultipleOrgs configuration and successfully excluding personal Microsoft accounts.

Step-by-Step Solution

1
Analyze the signInAudience setting in the application manifest.
The signInAudience is set to AzureADMultipleOrgs, which corresponds to multi-tenant organization accounts only.
This configuration indicates that only work and school accounts from any Microsoft Entra ID tenant should be allowed, and personal Microsoft accounts must be excluded.
2
Evaluate the available Microsoft identity platform authority endpoints.
The /organizations endpoint maps directly to AzureADMultipleOrgs. The /common endpoint maps to AzureADandPersonalMicrosoftAccount. The /consumers endpoint maps to PersonalMicrosoftAccount.
Choosing the correct endpoint ensures that the authentication requests are routed to the proper account pool in compliance with the manifest's signInAudience.
3
Select the authority URL that matches the /organizations endpoint.
The authority URL is https://login.microsoftonline.com/organizations.
This URL correctly restricts sign-in to organizational directories and matches the multi-tenant configuration.

Key Concept

Microsoft identity platform multi-tenant endpoints and signInAudience configuration
Question 136Question →

You are configuring a multi-tenant web application registration in Microsoft Entra ID. The application must allow users from any organizational Microsoft Entra ID tenant to sign in, but it must explicitly block users signing in with personal Microsoft accounts (such as outlook.com or hotmail.com). Which two configurations should you implement to satisfy this requirement? (Select two)

Select all that apply

Show answer & explanation

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

Answer

To configure a multi-tenant application to accept only organizational accounts while excluding personal accounts, you must set the signInAudience parameter to AzureADMultipleOrgs in the manifest and route authentication requests to the /organizations endpoint.
To limit access strictly to work or school accounts across any Microsoft Entra ID tenant, the application manifest must define the sign-in audience as AzureADMultipleOrgs. Correspondingly, client applications must request authorization from the /organizations endpoint to prevent personal accounts from being evaluated.

Step-by-Step Solution

1
Select the appropriate sign-in audience for organizational accounts.
The signInAudience property in the application registration manifest must be set to AzureADMultipleOrgs.
This configuration allows users from any Entra ID tenant (work or school accounts) to authenticate while blocking personal Microsoft accounts.
2
Determine the correct authorization authority endpoint.
The authority URL must use the /organizations endpoint instead of /common.
The /organizations endpoint restricts authentication to Entra ID organizational tenants only, whereas /common would also allow personal Microsoft accounts.

Key Concept

Configuring multi-tenant sign-in audiences and authority endpoints in Microsoft Entra ID
Estimated Time:1m 30s
Question 137Question →

An independent software vendor (ISV) is registering a new multi-tenant line-of-business application in Microsoft Entra ID. The application is designed to allow employees from any enterprise customer to log in with their work credentials, but it must reject sign-in attempts from personal Microsoft accounts.

Which configuration should the developer apply to the application manifest and the application's authentication endpoint?

Show answer & explanation

Answer: Set `signInAudience` to `AzureADMultipleOrgs` and use the `/organizations` authority endpoint.

Answer

Set the signInAudience to AzureADMultipleOrgs and use the /organizations authority endpoint.
Setting the signInAudience to AzureADMultipleOrgs restricts sign-ins to work or school accounts. Using the /organizations authority endpoint enforces this constraint at the Entra ID sign-in screen, ensuring personal accounts cannot log in.

Step-by-Step Solution

1
Evaluate the required sign-in audience scope.
Determine that `AzureADMultipleOrgs` is required to allow users from any enterprise directory while excluding personal Microsoft accounts.
Choosing `AzureADMyOrg` would limit authentication to a single tenant, whereas `AzureADandPersonalMicrosoftAccount` would allow personal accounts.
2
Determine the optimal authority endpoint.
Select the `/organizations` endpoint instead of `/common`.
The `/organizations` endpoint restricts access to organizational accounts directly at the authentication gate, avoiding user confusion by not allowing personal accounts to enter credentials.

Key Concept

Microsoft Entra ID Multi-tenant Sign-in Audience and Endpoint Filtering
Estimated Time:1m 30s
Question 138Question →

You are deploying an ASP.NET Core web application to an Azure App Service. The application must securely retrieve a database password stored as a secret in Azure Key Vault. You decide to use a system-assigned managed identity and Key Vault references to configure the application.

Which sequence of steps should you perform to configure the Azure resources and the App Service to resolve the secret?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order of steps is: 1) Enable the system-assigned managed identity on the Azure App Service instance. 2) Assign the Key Vault Secrets User role to the App Service's managed identity on the Azure Key Vault. 3) Retrieve the Secret Identifier (URI) of the database password secret from the Key Vault. 4) Add a new application setting in the App Service with a value formatted as @Microsoft.KeyVault(SecretUri=...).
The correct order establishes the security identity first, then applies the necessary Key Vault role permissions to it, retrieves the required secret identifier, and finally sets up the application configuration using the Key Vault reference syntax.

Step-by-Step Solution

1
Enable the system-assigned managed identity on the Azure App Service instance.
A service principal representing the App Service is created in Microsoft Entra ID.
This establishes the identity that will be authorized to access the Key Vault.
2
Assign the Key Vault Secrets User role to the App Service's managed identity on the Key Vault.
The App Service's identity is authorized to read secrets from the Key Vault.
Permissions must be configured in advance so that the App Service can resolve the secret reference as soon as it is configured.
3
Retrieve the Secret Identifier (URI) of the secret from the Key Vault.
The target secret's URI is copied.
The URI is required to construct the Key Vault reference syntax used in the App Service configuration.
4
Add a new application setting to the App Service using the @Microsoft.KeyVault(SecretUri=...) syntax.
The Key Vault reference is saved to the App Service settings.
The App Service runtime automatically detects this setting pattern, resolves the reference using the managed identity, and exposes the decrypted secret to the application code.

Key Concept

To securely reference Azure Key Vault secrets from App Service without code changes, you must enable a managed identity on the app, grant it the Key Vault Secrets User role on the Key Vault, and configure the app setting using the @Microsoft.KeyVault(SecretUri=...) syntax.
Question 139Question →

An application named App1 needs to be configured in Microsoft Entra ID. The application will be consumed by multiple external business partners who use their own corporate Entra ID directories, alongside external consultants who will sign in using their personal Microsoft accounts.

Which two configurations are required to support this authentication requirement? (Select two.)

Select all that apply

Show answer & explanation

Answer: Set the signInAudience property in the application manifest to AzureADandPersonalMicrosoftAccount; Use the common endpoint in the authority URI for user authentication

Answer

To support authentication for users from any corporate Entra ID tenant as well as personal Microsoft accounts, you must set the signInAudience property in the application manifest to AzureADandPersonalMicrosoftAccount and use the common endpoint in the authority URI for user authentication.
To support both multi-tenant organizational users and personal Microsoft accounts, the signInAudience parameter in the application manifest must be set to AzureADandPersonalMicrosoftAccount. In addition, the application's authentication configuration must point to the common endpoint (https://login.microsoftonline.com/common) because it routes both organizational and personal accounts, unlike the organizations endpoint which only routes organizational accounts.

Step-by-Step Solution

1
Identify the target user base requirements.
The application must support both multi-tenant organizational users (Entra ID) and personal accounts (Microsoft Accounts).
This determines the required directory audience and authentication endpoint configuration.
2
Choose the correct manifest sign-in audience.
Select AzureADandPersonalMicrosoftAccount.
The AzureADandPersonalMicrosoftAccount audience is designed specifically to allow logins from any Entra ID directory and personal Microsoft accounts.
3
Configure the authority endpoint in the application code.
Use the common endpoint (https://login.microsoftonline.com/common).
The common endpoint routes requests dynamically for both organizational accounts and personal Microsoft accounts, whereas the organizations endpoint restricts access to organizational accounts only.

Key Concept

Configuring multi-tenant Microsoft Entra ID applications to support both organizational accounts and personal Microsoft accounts.
Question 140Question →

A developer is deploying a Go-based web application to Azure App Service. The application must retrieve a database connection string stored in an Azure Key Vault named `kv-prod-westus`. A system-assigned managed identity is enabled for the App Service.

You configure an application setting in the App Service with the key `DbConnectionString` and the value `@Microsoft.KeyVault(VaultName=kv-prod-westus;SecretName=DbConnectionString)`.

During testing, the application fails to retrieve the secret value and instead reads the raw reference string.

Which of the following is the most likely cause of this issue?

Show answer & explanation

Answer: The system-assigned managed identity of the App Service has not been granted the 'Get' secret permission in the Key Vault access policies or Azure RBAC roles.

Answer

The system-assigned managed identity of the App Service has not been granted the 'Get' secret permission in the Key Vault access policies or Azure RBAC roles.
The correct answer is that the system-assigned managed identity lacks the necessary 'Get' secret permission. When Azure App Service is unable to resolve a Key Vault reference—due to missing permissions, network restrictions, or deletion of the resource—it will populate the environment variable with the raw reference string instead of failing the deployment or throwing an exception.

Step-by-Step Solution

1
Analyze the configuration and the observed behavior where the application receives the raw `@Microsoft.KeyVault(...)` reference string instead of the secret value.
Confirm that the syntax of the reference is correct and that the App Service is failing to resolve the reference at runtime.
When a Key Vault reference cannot be resolved due to configuration or access issues, App Service defaults to passing the raw reference string to the application code.
2
Verify the syntax of the Key Vault reference: `@Microsoft.KeyVault(VaultName=kv-prod-westus;SecretName=DbConnectionString)`.
The syntax is valid because it specifies both the correct vault name and secret name, and the secret version is optional.
This rules out syntax errors as the cause of the failure.
3
Check the authentication and authorization configuration between the App Service and the Key Vault.
The App Service has a system-assigned managed identity enabled, but it needs explicit authorization to read secrets.
For the App Service to retrieve the secret, its managed identity must be granted the 'Get' secret permission via Key Vault access policies or Azure RBAC (Key Vault Secrets User role).

Key Concept

Key Vault references in Azure App Service require correct syntax and appropriate read permissions ('Get' secret permission) granted to the app's managed identity in the Key Vault.
PreviousPage 7 / 11Next
Implement Azure Security Practice Questions — Microsoft Azure Developer (AZ-204) — Page 7 | Examkin