Examkin

All practice questions

972 questions

All types972Multiple choice497Multiple select269Matching9Ordering171Fill in the blank26
Question 621Question →

A developer is troubleshooting server-side HTTP 500 errors on a Windows-based Azure App Service. The developer runs the following Azure CLI command:

az webapp log config --name my-app --resource-group my-rg --failed-request-tracing true

The developer now needs to download and inspect the raw XML log files generated by this feature using the Kudu console. Under which directory in the App Service file system are the Failed Request Tracing logs stored?

Show answer & explanation

Answer: D:\home\LogFiles\W3SVC<SiteID>

Answer

The Failed Request Tracing logs are stored in the directory D:\home\LogFiles\W3SVC<SiteID>.
On a Windows-based Azure App Service, IIS Failed Request Tracing generates detailed XML logs of the IIS request pipeline. These logs are stored in the directory structured as D:\home\LogFiles\W3SVC<SiteID>, where <SiteID> is the platform-assigned IIS site identifier. Developers can browse, download, and analyze these XML files using the Kudu console or FTP to determine why specific requests failed.

Step-by-Step Solution

1
Identify the operating system and the specific logging feature being enabled.
The target is a Windows-based Azure App Service, and the feature is Failed Request Tracing.
Failed Request Tracing is an IIS-specific feature available on Windows-based App Services that outputs XML traces of request pipelines.
2
Determine the root filesystem structure of a Windows-based App Service.
The root path is D:\home, and all diagnostic logs are saved under D:\home\LogFiles.
Understanding the path structure allows you to distinguish between Windows-based (D:\home) and Linux-based (/home) filesystem structures.
3
Identify the correct subfolder for Failed Request Tracing files.
Failed Request Tracing files are saved under the W3SVC<SiteID> folder.
This subfolder is specifically designated for IIS Failed Request Tracing logs, whereas other folders like DetailedErrors store HTML errors and Application stores application traces.

Key Concept

Identifying the correct log storage directories for different App Service logging features on Windows versus Linux.
Question 622Question →

You are developing a C# console application to process customer support tickets from an Azure Service Bus queue named `support-tickets`. You need to retrieve a single message from the queue, process it, and remove it from the queue using the `Azure.Messaging.ServiceBus` SDK.

Arrange the steps in the correct order to implement this logic.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

First, instantiate a ServiceBusClient. Second, call CreateReceiver on the client. Third, call ReceiveMessageAsync on the receiver. Finally, call CompleteMessageAsync on the receiver.
The correct sequence begins with establishing the connection via the ServiceBusClient. From there, a ServiceBusReceiver is created for the specific queue. You then retrieve the message using ReceiveMessageAsync, and after processing, settle the message by calling CompleteMessageAsync to remove it from the queue.

Step-by-Step Solution

1
Instantiate a ServiceBusClient using the namespace connection string.
A connection to the Service Bus namespace is initialized.
The client is the entry point for interacting with all Service Bus entities in the namespace.
2
Call client.CreateReceiver("support-tickets") to create a receiver.
A ServiceBusReceiver instance scoped to the 'support-tickets' queue is obtained.
Specific message operations like receiving and completing are performed by a receiver.
3
Call receiver.ReceiveMessageAsync().
A ServiceBusReceivedMessage is fetched from the queue.
The message payload must be retrieved into application memory to perform processing.
4
Call receiver.CompleteMessageAsync(message).
The message is settled and permanently removed from the Service Bus queue.
Completing the message informs Service Bus that processing succeeded and the lock should be released and the message deleted.

Key Concept

Message receiver lifecycle and message settlement in Azure Service Bus
Question 623Question →

A queue-based backend worker application runs on an Azure App Service plan that is configured with a minimum of 55 instances. You set an autoscale rule to scale out by adding 11 instance when the average CPU percentage exceeds 80%80\%. You need to create a scale-in rule that removes 11 instance. To prevent autoscale flapping, what is the maximum CPU percentage threshold that should be set for the scale-in rule?

Show answer & explanation

Answer: 60%60\%

Answer

A scale-in threshold of 60%60\% is the maximum value among the choices that is strictly less than the post-scale-out average CPU utilization of approximately 66.7%66.7\%, thereby preventing autoscale flapping.
The correct answer is 60%60\% because at the scale-out threshold of 80%80\% with 55 instances, the total CPU workload is 400%400\%. Adding a 6th6\text{th} instance distributes this workload to approximately 66.7%66.7\% CPU usage per instance. To prevent the scale-in rule from triggering immediately after scale-out (flapping), the scale-in threshold must be set below 66.7%66.7\%. The only option meeting this requirement is 60%60\%.

Step-by-Step Solution

1
Calculate the total CPU load at the scale-out threshold.
Total CPU load is 5 instances×80%=400%5 \text{ instances} \times 80\% = 400\%.
This represents the aggregate workload capacity required by the application when the scale-out rule is triggered.
2
Calculate the expected CPU utilization per instance after the scale-out event occurs.
New CPU utilization per instance is 400%/6 instances≈66.67%400\% / 6 \text{ instances} \approx 66.67\%.
Scaling out adds 11 instance, distributing the same workload across 66 instances.
3
Identify the scale-in threshold that is lower than the new per-instance CPU utilization.
The threshold must be strictly less than 66.67%66.67\%.
If the scale-in threshold is higher than or equal to 66.67%66.67\%, the scale-in rule will immediately trigger after the scale-out event, causing flapping. Among the options, 60%60\% is the only value below this limit.

Key Concept

Autoscale flapping prevention by calculating post-scaling metric distribution
Question 624Question →

Complete the statement to identify the XML element required to inherit and execute policies from a parent scope in Azure API Management.

Fill in the blanks below

In Azure API Management, parent policies are not inherited by default at lower scopes. To inherit and execute policies defined at a higher scope within a specific policy section, you must include the XML element inside that section.
Show answer & explanation

Answer

The base element (or <base />)
The base element (often written as <base />) is used in Azure API Management policies to inherit and execute policies configured at a higher scope (such as Product or Global) inside the current scope (such as API or Operation). Its placement determines whether the current scope's policies run before or after the parent scope's policies.

Step-by-Step Solution

1
Identify the mechanism in Azure API Management policies that controls policy inheritance.
Policies are evaluated hierarchically (Global -> Product -> API -> Operation).
To avoid overriding parent policies, APIM uses a specific element to reference parent-level rules.
2
Determine the correct XML element for this mechanism.
The <base /> element represents the execution of policies from the parent scope.
Including <base /> tells the gateway to run the inherited policies at that exact point in the execution pipeline.

Key Concept

API Management policy inheritance and scoping
Estimated Time:45s
Question 625Question →

You are configuring an Azure API Management (APIM) instance to connect to a backend service that requires mutual TLS (mTLS) authentication. You need to configure APIM to authenticate with the backend using a client certificate. Which two actions should you perform? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Upload the client certificate to the Certificates store of the API Management instance.; Add the authentication-certificate policy to the inbound processing section of the API.

Answer

To configure mutual TLS authentication with a backend service in Azure API Management, you must upload the client certificate to the API Management Certificates store and add the authentication-certificate policy to the inbound processing block of the API.
To authenticate with a backend service using a client certificate, you must first upload the certificate to the Certificates store of the API Management instance so that the gateway can reference it. Then, you must configure the inbound processing section of the API with the authentication-certificate policy, which instructs the gateway to use the uploaded certificate during the outbound call to the backend.

Step-by-Step Solution

1
Upload the certificate to Azure API Management.
The certificate is registered in the API Management Certificates repository, generating a thumbprint and a certificate ID.
The APIM gateway must have access to the certificate file to present it to the backend service during the TLS handshake.
2
Add the authentication-certificate policy to the inbound policy section.
The API's inbound configuration includes the policy, referencing the uploaded certificate by its thumbprint or certificate ID.
The policy must run during inbound processing so that the gateway can select and attach the correct client certificate before the HTTP request is dispatched to the backend.

Key Concept

Gateway-to-Backend Mutual TLS (mTLS) Authentication
Question 626Question →

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 627Question →

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 628Question →

You are developing an Azure Function App that processes business orders. You configure the Function App to send telemetry to Application Insights. You must implement a monitoring solution using Azure Monitor to meet the following requirements:
- Automatically notify the operations team via email if any function execution takes longer than 10 seconds to complete.
- Execute a custom Azure Function to log details of the slow execution to an external auditing database.
- Optimize the alert query performance and minimize data scan costs.

Which two actions should you perform? (Choose two.)

Select all that apply

Show answer & explanation

Answer: Create a log search alert rule with a query that filters the requests table using: `requests | where timestamp > ago(5m) and duration > 10000`; Create an action group containing an Email receiver to notify the operations team and an Azure Function receiver to invoke the logging function

Answer

To meet the requirements, you must create a log search alert rule with a time-filtered KQL query (`requests | where timestamp > ago(5m) and duration > 10000`) and configure an action group that contains an Email receiver and an Azure Function receiver.
The correct actions involve configuring a Log Search alert rule that queries the `requests` table with a restricted time range (`timestamp > ago(5m)`) to maintain high performance and low costs, while detecting request durations greater than 10 seconds (`duration > 10000`). Additionally, you must configure an action group containing both an Email receiver to alert the operations team and an Azure Function receiver to execute the custom logging database logic.

Step-by-Step Solution

1
Write a KQL query to find requests exceeding 10 seconds with a time-range boundary.
`requests | where timestamp > ago(5m) and duration > 10000`
Using a time-range filter like `timestamp > ago(5m)` is required to limit data scanning, optimizing query execution speed and minimizing Azure Monitor costs.
2
Create an Azure Monitor Action Group with the appropriate notification and action receivers.
An Action Group featuring an Email receiver and an Azure Function receiver.
Action groups allow bundling different response mechanisms, satisfying the email notification and the automated custom function logging requirements simultaneously.

Key Concept

Implementing Log Search Alerts with KQL and configuring Action Groups with diverse receivers (Email and Azure Functions) in Azure Monitor.
Question 629Question →

You are configuring an inbound policy in Azure API Management to modify the request path before it is forwarded to the backend service. The policy must redirect the client request from the public URL structure to the backend endpoint path /users/{id}. Complete the policy XML block by identifying the missing element name to rewrite the path:

Fill in the blanks below

<inbound>
<base />
< template="/users/{id}" />
</inbound>
Show answer & explanation

Answer

rewrite-uri
The rewrite-uri policy modifies a request URL from the form in which it was received to the form expected by the web service that implements the API. In this scenario, it is used to redirect incoming requests to the /users/{id} path template.

Step-by-Step Solution

1
Identify the requirement to modify the request path/URL before forwarding to the backend.
The requirement is to rewrite the request URL/path to match the backend path structure.
Azure API Management provides specific inbound policies to transform request paths.
2
Select the appropriate policy element for rewriting URLs.
The rewrite-uri policy is the correct element used to change a request URL path from its public form to the form expected by the backend service.
This policy modifies the request path directly inside the inbound section using the template attribute.

Key Concept

Azure API Management URL rewriting policy
Question 630Question →

A telemetry ingestion system processes device readings stored in an Azure Cosmos DB container. You are deploying multiple instances of a .NET background service to process changes in parallel using the Change Feed Processor. All instances will share a single lease container. To ensure that the workload is distributed across all running instances of the background service rather than having them duplicate processing, which configuration strategy should you apply?

Show answer & explanation

Answer: Initialize the change feed processor on all instances with the same processor name, but assign a unique instance name to each host.

Answer

Initialize the change feed processor on all instances with the same processor name, but assign a unique instance name to each host.
To distribute the processing load across multiple instances, the change feed processor requires a shared logical identifier (the processor name) and a unique physical identifier (the instance name) for each host. The shared processor name groups the instances into a single deployment unit, allowing them to lease different partitions of the feed dynamically. The unique instance name prevents conflicts by ensuring that only one host owns a given partition lease at a time.

Step-by-Step Solution

1
Group instances into a single consumer group using a shared processor name.
The change feed processor recognizes all instances as part of the same logical deployment.
This prevents instances from acting as independent readers that duplicate the entire stream.
2
Assign a unique instance name to each host.
Each host is assigned a subset of partition leases without interfering with other hosts.
Unique instance names allow the change feed processor to allocate and track lease ownership correctly.
3
Ensure the lease container partition key is set to /id/id.
The lease container supports correct coordination of leases.
The Azure Cosmos DB SDK requires the lease container to be partitioned by /id/id.

Key Concept

Change Feed Processor Scale-out Configuration
Estimated Time:1m 30s
Question 631Question →

You are developing a C# .NET 8 Worker Service application that will be hosted in Azure Container Apps. You need to configure the Application Insights SDK to collect telemetry from this non-web application. You must use the latest Azure-recommended configuration practices and avoid deprecated properties.

Which two actions should you perform? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Call builder.Services.AddApplicationInsightsTelemetryWorkerService(); in the Program.cs file.; Configure an environment variable named APPLICATIONINSIGHTS_CONNECTION_STRING with the Application Insights connection string.

Answer

Register the telemetry worker service in the Program.cs file and configure the APPLICATIONINSIGHTS_CONNECTION_STRING environment variable.
For C# Worker Services, the Application Insights SDK is registered using the AddApplicationInsightsTelemetryWorkerService method. Telemetry routing is configured using the connection string, which is automatically read from the APPLICATIONINSIGHTS_CONNECTION_STRING environment variable by the SDK.

Step-by-Step Solution

1
Select the correct SDK registration method for non-web workloads.
Use the AddApplicationInsightsTelemetryWorkerService method in the services container.
Worker Services do not have HTTP contexts and require the specialized worker service registration rather than the standard web registration.
2
Configure the telemetry endpoint credentials.
Define the APPLICATIONINSIGHTS_CONNECTION_STRING environment variable with the resource's connection string.
Using connection strings is the modern, non-deprecated standard for routing telemetry data to the correct Application Insights instance.

Key Concept

Configuring SDK-based telemetry in non-web .NET applications using connection strings
Estimated Time:2m 0s
Question 632Question →

You are developing a distributed system that processes updates from an Azure Cosmos DB container using the .NET SDK v3 Change Feed Processor. You are configuring the lease container that will store the state and manage work distribution among multiple host instances.

Which of the following statements regarding the lease container configuration are correct? (Select TWO)

Select all that apply

Show answer & explanation

Answer: The lease container must be partitioned by the `/id` path.; Multiple independent consumer applications can share a single lease container if they are configured to use a unique lease prefix.

Answer

The lease container must be partitioned by the `/id` path, and multiple independent consumer applications can share a single lease container if they are configured to use a unique lease prefix.
The Change Feed Processor uses the lease container to store state and coordinate processing across multiple hosts. The lease container must be partitioned by the `/id` path. Additionally, multiple independent processors can share the same lease container if they use distinct lease prefixes to distinguish their lease documents.

Step-by-Step Solution

1
Determine the partition key requirement for the lease container.
The lease container stores the state of the feed (checkpoints) and must be partitioned by `/id` to allow the Change Feed Processor to manage lease ownership.
This is a requirement of the Azure Cosmos DB SDK v3 Change Feed Processor architecture.
2
Determine how multiple independent consumers share the lease container.
Using a unique lease prefix for each workflow allows them to share the lease container without conflict.
The prefix distinguishes lease documents belonging to different consumer groups processing the same or different partitions.

Key Concept

Azure Cosmos DB Change Feed lease container configuration requirements
Question 633Question →

You are deploying a containerized microservice named `orders-api` to Azure Container Apps by using a Bicep template. The container image is stored in a private Azure Container Registry (ACR) named `myregistry.azurecr.io`. You configure a system-assigned managed identity on the Container App and assign it the `AcrPull` role on the registry.

How should you configure the registry credentials in the Bicep template to ensure the Container App can pull the image from the private registry using the system-assigned managed identity?

Show answer & explanation

Answer: Set the `identity` property to `'system'` in the registry configuration block under the registries array.

Answer

To pull the image using a system-assigned managed identity, set the identity property to 'system' in the registry configuration block under the registries array.
The correct answer is to set the identity property to 'system' in the registry configuration block under the registries array. For system-assigned managed identity authentication to a private registry, Azure Container Apps requires the identity property of the registry object to be set to the string literal 'system'.

Step-by-Step Solution

1
Define the Container App resource in the Bicep template with a system-assigned managed identity enabled.
The Container App resource contains the identity block with type set to 'SystemAssigned'.
This generates a system-assigned managed identity for the Container App when deployed.
2
Reference the private Azure Container Registry and configure authentication.
An entry is added to the registries array under the configuration section.
Azure Container Apps needs to know which registry host requires authentication.
3
Assign the string literal 'system' to the identity property in the registry entry.
The configuration uses the system-assigned managed identity of the app for container image pull operations.
The Container Apps platform automatically resolves the keyword 'system' to the app's own system-assigned identity to authenticate the image pull.

Key Concept

Registry authentication using system-assigned managed identity in Azure Container Apps
Question 634Question →

You are migrating a deprecated multi-step web test that monitors an e-commerce checkout flow to a modern availability monitoring solution in Azure. The workflow requires logging in with a test account, searching for a product, and verifying the checkout service response.

You decide to implement a custom availability test using a Timer-triggered Azure Function and the Application Insights SDK. The function must run securely, retrieve test account credentials from Azure Key Vault, and report the workflow status to Application Insights.

You need to implement the telemetry reporting and ensure the function runs securely and successfully sends telemetry.

Which two actions should you perform? Select two.

Select all that apply

Show answer & explanation

Answer: Instantiate TelemetryClient by passing a TelemetryConfiguration initialized with the Application Insights connection string, and call the TrackAvailability method with an AvailabilityTelemetry instance.; Grant the Azure Function's system-assigned managed identity the Key Vault Secrets User role on the Key Vault that stores the test credentials, and reference those credentials in the function's application settings using Key Vault references.

Answer

To implement the custom availability monitoring solution, you must instantiate the TelemetryClient using a TelemetryConfiguration initialized with the Application Insights connection string and call TrackAvailability with an AvailabilityTelemetry instance. Additionally, you must grant the function's managed identity the Key Vault Secrets User role to allow resolving Key Vault references in the application settings.
Migrating deprecated multi-step tests requires executing custom logic (such as logging in, searching, and checking out) in code, which can be done using a Timer-triggered Azure Function. To report custom availability telemetry, the Azure Function must use the Application Insights SDK. Instantiating TelemetryClient with a configuration containing the connection string ensures the telemetry is directed to the correct resource. Furthermore, retrieving credentials securely requires using Key Vault references in the application settings, which fails unless the function's system-assigned managed identity is granted authorization, such as the Key Vault Secrets User role.

Step-by-Step Solution

1
Configure the Azure Function's App Settings to use Key Vault references for credentials, and authorize the Function's system-assigned managed identity to access the Key Vault.
The Function is granted authorization, allowing the runtime to resolve the @Microsoft.KeyVault references into actual credentials securely.
This is necessary because Azure resources do not have implicit access to Key Vault secrets, and credentials must be retrieved securely.
2
Initialize TelemetryConfiguration using the Application Insights connection string, and pass it to the constructor of TelemetryClient.
The TelemetryClient is correctly instantiated with the connection string, pointing to the intended Application Insights resource.
Instantiating the client without a connection string configuration will fail to transmit availability telemetry.
3
Construct an AvailabilityTelemetry instance with properties representing the test run (name, duration, success, location) and call TrackAvailability() on the TelemetryClient.
Custom availability data is successfully tracked and sent to Application Insights.
Standard web tests do not support multi-step checkout workflows or client certificates, necessitating custom availability logging via the SDK.

Key Concept

Custom availability monitoring with Application Insights SDK using Azure Functions and Key Vault integration
Question 635Question →

You are troubleshooting a Python web application deployed on a Linux-based Azure App Service named my-app in a resource group named my-rg. The application fails during the startup phase, and you need to enable container stdout/stderr logging to the filesystem and then view the live log stream in your local terminal. Which two of the following Azure CLI commands must you run?

Select all that apply

Show answer & explanation

Answer: az webapp log config --name my-app --resource-group my-rg --docker-container-logging filesystem; az webapp log tail --name my-app --resource-group my-rg

Answer

Enable container filesystem logging using the command with the --docker-container-logging filesystem flag, and stream the logs using the tail command.
To troubleshoot startup errors on a Linux-based App Service, you must configure container logging to the filesystem using the --docker-container-logging parameter and then use the log tail command to establish a live diagnostic connection.

Step-by-Step Solution

1
Enable container-level filesystem logging using the Azure CLI command.
The App Service is configured to persist stdout and stderr logs within the host filesystem.
On Linux App Services, application logs correspond to the container's standard output and error streams, which must be enabled via the docker-container-logging parameter.
2
Start a live log streaming session using the Azure CLI tail command.
A real-time connection to the App Service log stream is opened in the terminal.
This allows you to observe the startup errors interactively as the container attempts to initialize.

Key Concept

Configuring container logging and streaming logs for Linux-based App Services using the Azure CLI.
Question 636Question →

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 637Question →

You are configuring a custom domain for a publicly accessible Azure Container App. You want to secure the custom domain with an SSL/TLS certificate.

In which sequence must you perform the steps to successfully configure and secure the custom domain?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence is: first retrieve the domain verification code and FQDN from the Container App, next configure the TXT verification and CNAME records in your DNS provider, then add and verify the custom domain in the Container App, and finally bind the SSL/TLS certificate.
To successfully configure and secure a custom domain on Azure Container Apps, you must start by retrieving the unique verification code (asuid) and default FQDN. This allows you to create the required TXT verification and CNAME routing records in your DNS provider. Once the DNS records are active, you add the custom domain to the Container App, which triggers ownership verification. Finally, you secure the configuration by binding an SSL/TLS certificate.

Step-by-Step Solution

1
Retrieve verification details
Obtained the asuid verification code and FQDN from the Container App.
Azure requires these details to map your custom domain and verify your control over it.
2
Create DNS records
Created TXT and CNAME records at your DNS registrar.
Enables Azure's validation checks and ensures internet traffic routes to the Container App's default domain.
3
Add and verify the custom domain
Successfully associated the custom domain with the Container App.
The Container App checks for the presence of the TXT record to verify ownership before registration.
4
Bind the SSL certificate
Enabled HTTPS traffic securely on the custom domain.
Finalizes the setup to ensure secure, encrypted communication to the custom domain.

Key Concept

Custom domain configuration and verification sequence on Azure Container Apps
Estimated Time:2m 0s
Question 638Question →

A healthcare provider uses an Azure Service Bus queue named `patient-checkins` to manage incoming patient arrival data. You are writing a C# client using the Azure.Messaging.ServiceBus SDK to retrieve and process these messages. You must ensure that messages are only removed from the queue after they have been successfully processed, preventing message loss if the client application crashes during execution. Which configuration or approach should you implement?

Show answer & explanation

Answer: Initialize the `ServiceBusReceiver` with `ServiceBusReceiveMode.PeekLock` and call `CompleteMessageAsync` after the message is successfully processed.

Answer

Initialize the `ServiceBusReceiver` with `ServiceBusReceiveMode.PeekLock` and call `CompleteMessageAsync` after the message is successfully processed.
The correct answer is to use `ServiceBusReceiveMode.PeekLock` and call `CompleteMessageAsync` after processing. In PeekLock mode, the receiver locks the message on the queue for a specified duration, allowing the receiver to complete the message once successfully processed. If the receiver crashes, the lock expires, and the message becomes available to other receivers again, preventing loss.

Step-by-Step Solution

1
Determine the required message reliability level.
At-least-once delivery is required to prevent message loss.
The system must recover messages if the client crashes mid-execution.
2
Select the appropriate Service Bus receive mode.
`ServiceBusReceiveMode.PeekLock` is selected.
PeekLock locks the message on the queue during processing, allowing it to reappear if the lock duration expires without settlement.
3
Implement message settlement in code.
Call `CompleteMessageAsync` once the processing succeeds.
This explicitly completes the transaction on the Service Bus server, removing the message from the queue.

Key Concept

Azure Service Bus Receive Modes and Message Settlement
Question 639Question →

An organization is provisioning a new Azure API Management (APIM) instance. You must configure the APIM instance to retrieve a backend API key stored as a secret in an Azure Key Vault. You have already enabled a system-assigned managed identity on the APIM instance. Which action should you perform next to allow APIM to retrieve the secret?

Show answer & explanation

Answer: Grant the system-assigned managed identity of the APIM instance the Key Vault Secrets User role or GET permission in the Key Vault, and then create an APIM Named Value that references the Key Vault secret.

Answer

Grant the system-assigned managed identity of the APIM instance the Key Vault Secrets User role or GET permission in the Key Vault, and then create an APIM Named Value that references the Key Vault secret.
To retrieve and use a secret key from Key Vault securely, the API Management instance's system-assigned managed identity must have explicit read access (such as Key Vault Secrets User role or GET permission on secrets) in the Key Vault. Once access is authorized, a Named Value can be configured in API Management referencing the Key Vault secret URI, allowing APIM to fetch the secret dynamically.

Step-by-Step Solution

1
Configure permissions on Azure Key Vault
The system-assigned managed identity of the Azure API Management (APIM) instance is granted the Key Vault Secrets User Azure RBAC role or GET secret permission via Key Vault access policies.
This allows the APIM instance's identity to authenticate and retrieve secret values from the Key Vault.
2
Create a Named Value in APIM
A Named Value is created with the type 'Key Vault' and configured with the secret identifier (URI) from Key Vault.
This registers the secret as an APIM configuration property that can be referenced inside API policies or backend settings.

Key Concept

Azure API Management Named Values integration with Azure Key Vault using Managed Identities
Question 640Question →

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
PreviousPage 32 / 49Next
All practice questions — Microsoft Azure Developer (AZ-204) | Examkin