All practice questions

972 questions

All types972 Multiple choice497 Multiple select269 Matching9 Ordering171 Fill in the blank26

An Azure App Service web application experiences intermittent failures. You are troubleshooting the issues by querying Application Insights telemetry.

You need to correlate the exceptions recorded over the last $24$ hours with their associated failed requests to identify the most common problem IDs.

Which KQL query should you execute to retrieve this data with the best query performance?

exceptions
| join kind=inner (
requests
| where success == false
) on operation_Id
| summarize OccurrenceCount = count() by problemId
| top 5 by OccurrenceCount desc

Show answer & explanation

Answer

The correct query applies the 'where timestamp > ago(24h)' filter to both the exceptions and the requests tables before performing the inner join.

The correct query applies the time filter to both the exceptions table and the requests subquery before executing the join. In Kusto Query Language (KQL), filtering tables by time range as early as possible—especially on both sides of a join—minimizes the dataset size processed in memory, yielding the best query execution performance.

Step-by-Step Solution

Filter both input tables by timestamp

Limits the scope of data retrieved from both the exceptions and requests tables to the last 24 hours.

Applying time-range filters early on both sides of a join prevents the query engine from scanning historical telemetry, optimizing execution speed.

Perform the inner join on operation_Id

Correlates only the relevant 24-hour records between the two tables.

Using operation_Id matches the exceptions to their corresponding failed requests.

Summarize and retrieve the top results

Groups the matched exceptions by problemId, counts the occurrences, and returns the top 5.

This answers the diagnostic requirement to find the most common problem IDs.

Key Concept

Best practices for KQL query optimization when joining high-volume telemetry tables in Application Insights.

Question 862Question →

You are designing a monitoring and remediation strategy for an enterprise web application hosted on Azure App Service. The application logs exceptions to an Application Insights workspace.

You need to implement an Azure Monitor Log Search Alert rule that triggers when the exception rate exceeds a specific threshold. The alert must execute the following workflow:
1. Dynamically email all users who hold the built-in 'Monitoring Contributor' role at the subscription level.
2. Invoke an automated remediation service hosted on an Azure Function App. This endpoint is secured using Microsoft Entra ID authentication.
3. Minimize query overhead and avoid duplicate filtering in the underlying Kusto Query Language (KQL) query execution.

Which $3$ configurations must you implement to meet these requirements?

Select all that apply

In the Action Group, add an action of type 'Email Azure Resource Manager Role' and select the 'Monitoring Contributor' role.

In the Action Group, add an action of type 'Webhook', enable Microsoft Entra ID authentication, and specify the Tenant ID, Object ID of the service principal, and the Identifier URI of the secured endpoint.

In the Log Search Alert rule, write a KQL query that excludes any explicit temporal filter (such as where timestamp > ago(...)), allowing the rule's aggregation parameters to control the query window.

In the Action Group, add an action of type 'Azure Function', enable Microsoft Entra ID authentication, and provide the service principal details of the target Function App.

In the Log Search Alert rule's KQL query, include a 'where timestamp > ago(5m)' clause to explicitly restrict the scanned telemetry to the

5

-minute evaluation period.

In the Action Group, add an action of type 'Email/SMS/Push/Voice', select 'Email', and manually add the individual email addresses of all team members currently holding the 'Monitoring Contributor' role.

Show answer & explanation

Answer: In the Action Group, add an action of type 'Email Azure Resource Manager Role' and select the 'Monitoring Contributor' role.; In the Action Group, add an action of type 'Webhook', enable Microsoft Entra ID authentication, and specify the Tenant ID, Object ID of the service principal, and the Identifier URI of the secured endpoint.; In the Log Search Alert rule, write a KQL query that excludes any explicit temporal filter (such as where timestamp > ago(...)), allowing the rule's aggregation parameters to control the query window.

Answer

To meet the requirements, you must add an 'Email Azure Resource Manager Role' action to the Action Group for the 'Monitoring Contributor' role, use a 'Webhook' action type with Microsoft Entra ID authentication enabled to trigger the secured Azure Function, and omit manual time filters from the alert rule's KQL query.

Implementing a dynamic notification requires the 'Email Azure Resource Manager Role' type to map roles dynamically. Calling an Entra ID-secured Azure Function requires using the Webhook action type, as the direct Azure Function receiver only supports host/function key authentication. Lastly, KQL queries for alert rules should not contain manual time filters, as Azure Monitor automatically appends the target time window based on the rule parameters.

Step-by-Step Solution

Address the notification requirement dynamically using Azure RBAC roles.

Create an action within the Action Group of type 'Email Azure Resource Manager Role' targeting 'Monitoring Contributor'. This ensures any user with the role is automatically emailed.

Hardcoding individual emails makes the system static and hard to maintain, while the ARM role receiver dynamically evaluates membership.

Select the correct Action Group receiver for Microsoft Entra ID secured endpoints.

Create a 'Webhook' action type, enable Microsoft Entra ID authentication, and configure the tenant, object ID, and audience URI.

Although the target is an Azure Function, the native 'Azure Function' action type in Action Groups does not support Entra ID authentication; the 'Webhook' action type must be used to send authenticated payloads.

Optimize the KQL query by leveraging the alert rule's native evaluation parameters.

Write the KQL query without any timestamp filters (like 'ago()').

Azure Monitor automatically appends the time bounds based on the alert rule's lookback period. Adding them manually overrides these parameters and can cause incorrect or slow evaluations.

Key Concept

Azure Monitor Action Groups support securing webhook actions using Microsoft Entra ID authentication, but this capability is not natively present in the direct Azure Function action type. Additionally, Log Search Alert KQL queries must omit manual time bounds as Azure Monitor manages the query period automatically.

Estimated Time:3m 0s

Question 863Question →

You are configuring an inbound policy in Azure API Management (APIM) to extract user information from a custom HTTP header named `X-Auth-Token`, which contains a raw JSON Web Token (JWT). The policy must extract the first value of the `email` claim from the token and forward it to the backend service inside a new request header named `X-User-Email`. If the claim is not present, it should default to an empty string.

Complete the XML policy definition below by filling in the correct C# extension method and JWT property name in the blanks.

Fill in the blanks below

xml
<policies>
<inbound>
<base />
<set-header name="X-User-Email" exists-action="override">
<value>@(context.Request.Headers.GetValueOrDefault("X-Auth-Token", "").()?..GetValueOrDefault("email")?[0] ?? "")</value>
</set-header>
</inbound>
</policies>

Show answer & explanation

Answer

To extract the `email` claim from the raw JWT in the `X-Auth-Token` header, you must convert the string token using the `AsJwt` extension method, and then access its `Claims` property. The correct values for the blanks are `AsJwt` for the first blank and `Claims` for the second blank.

The correct configuration uses the `AsJwt` extension method on the token string to parse the JWT into a helper object. It then accesses the `Claims` property of this object, which returns a dictionary containing all the claims in the token. Using `GetValueOrDefault("email")?[0]` retrieves the first value of the `email` claim in a null-safe manner.

Step-by-Step Solution

Identify the string extension method in Azure API Management policy expressions that parses a raw JWT string.

The `AsJwt()` extension method is used to parse a JWT string and return a C# object of type `Jwt`.

Before you can inspect claims or other properties of a JWT in a policy expression, you must convert the string representation of the token into a helper object.

Identify the property of the `Jwt` class that exposes the claims dictionary.

The `Claims` property exposes the token's claims as a read-only dictionary (`IReadOnlyDictionary<string, string[]>`).

Custom claims, such as `email`, are stored in the claims dictionary and can be retrieved using standard dictionary lookup methods.

Use safe navigation to access the first element of the claim array and provide a fallback.

The expression uses `GetValueOrDefault("email")?[0] ?? ""` to safely retrieve the first email address or fall back to an empty string.

This prevents runtime exceptions if the claim is missing or if the array is empty.

Key Concept

Azure API Management policy expressions allow the use of C# code to perform dynamic request transformation. The `AsJwt()` extension method and `Claims` property of the `Jwt` class enable inspection and extraction of specific JWT claims directly within policies.

Question 864Question →

You are developing a .NET background worker service that processes critical payment transactions from an Azure Service Bus queue. The processing of each payment involves calling a third-party gateway, which can take up to 2 minutes during peak hours. The Service Bus queue is configured with a default LockDuration of 30 seconds and a MaxDeliveryCount of 5.

You must ensure that:
1. Messages are never lost if the worker service crashes or restarts mid-transaction.
2. Messages are not processed by multiple workers simultaneously if processing exceeds 30 seconds.
3. Message processing failures due to transient errors are immediately released back to the queue for retry up to the maximum delivery count.

You use the Azure.Messaging.ServiceBus SDK to initialize the processor with the following code:

csharp
var client = new ServiceBusClient(connectionString);
var options = new ServiceBusProcessorOptions
{
ReceiveMode = [ReceiveMode],
AutoCompleteMessages = [AutoComplete],
MaxAutoLockRenewalDuration = [MaxAutoLockRenewal]
};
ServiceBusProcessor processor = client.CreateProcessor(queueName, options);

processor.ProcessMessageAsync += async args =>
{
try
{
await ProcessPaymentWithRetryAsync(args.Message);
[CompleteMessage]
}
catch (Exception)
{
[HandleException]
}
};

Which set of configuration values and code segments should you use to meet these requirements?

[ReceiveMode] = ServiceBusReceiveMode.PeekLock
[AutoComplete] = false
[MaxAutoLockRenewal] = TimeSpan.FromMinutes(5)
[CompleteMessage] = await args.CompleteMessageAsync(args.Message);
[HandleException] = await args.AbandonMessageAsync(args.Message);

[ReceiveMode] = ServiceBusReceiveMode.ReceiveAndDelete
[AutoComplete] = true
[MaxAutoLockRenewal] = TimeSpan.FromMinutes(5)
[CompleteMessage] = // No-op
[HandleException] = // No-op

[ReceiveMode] = ServiceBusReceiveMode.PeekLock
[AutoComplete] = false
[MaxAutoLockRenewal] = TimeSpan.Zero
[CompleteMessage] = await args.CompleteMessageAsync(args.Message);
[HandleException] = await args.AbandonMessageAsync(args.Message);

[ReceiveMode] = ServiceBusReceiveMode.PeekLock
[AutoComplete] = true
[MaxAutoLockRenewal] = TimeSpan.FromMinutes(5)
[CompleteMessage] = await args.CompleteMessageAsync(args.Message);
[HandleException] = await args.AbandonMessageAsync(args.Message);

Show answer & explanation

Answer: [ReceiveMode] = ServiceBusReceiveMode.PeekLock
[AutoComplete] = false
[MaxAutoLockRenewal] = TimeSpan.FromMinutes(5)
[CompleteMessage] = await args.CompleteMessageAsync(args.Message);
[HandleException] = await args.AbandonMessageAsync(args.Message);

Answer

Use PeekLock mode, disable auto-complete, set the automatic lock renewal duration to 5 minutes, explicitly complete the message upon success, and explicitly abandon the message upon failure.

The configuration using PeekLock receive mode, AutoCompleteMessages set to false, and MaxAutoLockRenewalDuration set to 5 minutes is correct. PeekLock ensures that messages remain on the queue until explicitly completed, preventing message loss. Setting MaxAutoLockRenewalDuration to 5 minutes ensures the lock remains active for the duration of the 2-minute payment process. Explicitly completing the message on success and abandoning it on exception ensures correct settlement and immediate retry in case of failure.

Step-by-Step Solution

Analyze reliability requirements to determine the correct ServiceBusReceiveMode.

ServiceBusReceiveMode.PeekLock must be used. Using ReceiveAndDelete deletes messages immediately upon retrieval, resulting in data loss if the worker crashes before processing finishes.

Ensures that messages are not lost and can be retried in case of application failure.

Determine the lock renewal duration based on the processing time.

MaxAutoLockRenewalDuration must be set to a duration greater than the maximum processing time (e.g., TimeSpan.FromMinutes(5)).

Since payment processing takes up to 2 minutes but the queue lock duration is only 30 seconds, auto-renewal prevents other workers from processing the active message concurrently.

Establish the settlement model by configuring AutoCompleteMessages and handler code.

Set AutoCompleteMessages to false, explicitly complete the message using CompleteMessageAsync on success, and explicitly abandon it using AbandonMessageAsync on exception.

Explicitly abandoning the message on failure ensures it is immediately unlocked and made available for retry rather than waiting for the remaining lock duration to expire. Redundant manual settlement when AutoCompleteMessages is true causes runtime exceptions.

Key Concept

Azure Service Bus message receive modes, lock renewal configuration, and message settlement lifecycle.

Estimated Time:3m 0s

Question 865Question →

You are deploying an Azure API Management (APIM) self-hosted gateway to an on-premises Kubernetes cluster to manage local microservices. You have created the gateway resource within your APIM instance in the Azure portal. You need to configure the self-hosted gateway container deployment so that it can successfully register and retrieve its configuration from the parent APIM instance. Which two environment variables must you configure on the container to enable this connection? (Select two.)

Select all that apply

config.service.endpoint

gateway.auth.token

gateway.auth.key

telemetry.config.connectionstring

Show answer & explanation

Answer: config.service.endpoint; gateway.auth.token

Answer

To enable the self-hosted gateway to retrieve its configuration, you must configure the config.service.endpoint variable to point to the configuration endpoint URL and the gateway.auth.token variable to contain a valid access token.

The self-hosted gateway container connects to the Azure API Management control plane using the configuration service endpoint and authenticates via a gateway-specific access token. Therefore, the variables config.service.endpoint and gateway.auth.token must be set.

Step-by-Step Solution

Access the Azure API Management gateway resource in the portal and generate an access token using one of the gateway keys.

A time-bound access token is generated.

This token is required by the container to authenticate and download configurations from Azure.

Apply the config.service.endpoint environment variable to the gateway container specification, setting it to the API Management configuration service URL.

The container is configured to query the correct control plane address.

This establishes the endpoint location for configuration updates.

Apply the gateway.auth.token environment variable to the container specification, setting it to the generated access token.

The container successfully authenticates and downloads the API routing policies.

This completes the handshake and secure registration.

Key Concept

Self-hosted gateway deployment configuration parameters

Question 866Question →

An enterprise web application hosted on Azure App Service is instrumented with Application Insights. You are implementing an Azure Monitor Log Search Alert rule to monitor server-side errors. The alert rule must trigger an Action Group if the percentage of HTTP 5xx responses exceeds $5\%$ of the total requests over a rolling 15-minute window, evaluated every 5 minutes.

The alert rule condition is configured with the following properties:
- Measure: Metric measurement
- Metric column: ErrorRate
- Aggregation type: Average
- Aggregation granularity (Period): 15 minutes
- Frequency of evaluation: 5 minutes

Which of the following configurations should you implement to satisfy the monitoring requirement and ensure telemetry ingestion and alert execution are successful?

Use a KQL query that groups by 'bin(timestamp, 5m)' and projects 'timestamp' and 'ErrorRate' without any time-range filter clause, and configure the web app with the 'APPLICATIONINSIGHTS_CONNECTION_STRING' app setting.

Use a KQL query that filters for 'timestamp > ago(15m)' before grouping by 'bin(timestamp, 5m)', and configure the web app with the 'APPLICATIONINSIGHTS_CONNECTION_STRING' app setting.

Use a KQL query that groups by 'bin(timestamp, 5m)' and projects 'timestamp' and 'ErrorRate' without any time-range filter clause, and initialize the Application Insights SDK in code without setting the connection string, relying on parameterless initialization.

Use a KQL query that groups by 'bin(timestamp, 5m)' and projects 'timestamp' and 'ErrorRate' without any time-range filter clause, and configure the action group to use a secure webhook that retrieves its client secret from Key Vault using a key vault reference, without assigning a 'Get Secret' permission to the Azure Monitor service principal.

Show answer & explanation

Answer: Use a KQL query that groups by 'bin(timestamp, 5m)' and projects 'timestamp' and 'ErrorRate' without any time-range filter clause, and configure the web app with the 'APPLICATIONINSIGHTS_CONNECTION_STRING' app setting.

Answer

The correct configuration uses a query that summarizes the error rate using 'bin(timestamp, 5m)' and projects 'timestamp' alongside 'ErrorRate' without a hardcoded time-range filter. It also relies on the 'APPLICATIONINSIGHTS_CONNECTION_STRING' setting to successfully stream application logs to Application Insights. This satisfies all configuration best practices and ensures successful alert operation.

Step-by-Step Solution

Analyze KQL query structure requirements for Azure Monitor Log Search Alerts.

Identify that for Metric Measurement alerts, the query must project a timestamp column (e.g., 'timestamp') and a metric value column (e.g., 'ErrorRate'). The query should not include hardcoded time filters like 'ago(15m)' because Azure Monitor automatically handles the time-range filtering based on the rule configuration.

Hardcoding the time-range in KQL can cause redundant filtering or incorrect evaluations if the alert evaluation window is updated in the rule settings.

Determine telemetry collection pre-requisites.

Ensure Application Insights is correctly configured. A connection string must be supplied to the SDK (often via the 'APPLICATIONINSIGHTS_CONNECTION_STRING' application setting in Azure App Service).

Without a valid connection string, telemetry is not sent to Application Insights, meaning the 'requests' table will be empty and the alert cannot fire.

Evaluate secure webhook and action group authentication.

Ensure any Key Vault references used by Azure Monitor Action Groups or related automated webhooks have appropriate access policies.

If the Azure Monitor service principal or the Webhook app's service principal cannot access the Key Vault secret due to a missing access policy, the Action Group will fail to execute actions.

Key Concept

Log Search Alert Condition and Telemetry Ingestion Configuration

Estimated Time:3m 0s

Question 867Question →

You are implementing an event processor client in a C# (.NET) application using the `Azure.Messaging.EventHubs.Processor` library. The application consumes telemetry from an Azure Event Hub and uses an Azure Blob Storage container to store checkpoints and partition ownership metadata.

During a deployment, you encounter the following two issues:
1. A secondary management service in the application fails with an HTTP 412 (Precondition Failed) error when attempting to append custom monitoring metadata directly to the active partition ownership lease blobs.
2. The event processor client fails to authenticate with the Storage account when using a User-Assigned Managed Identity, throwing an credential authentication exception.

Which of the following actions should you perform to resolve these issues? (Select TWO)

Select all that apply

In the secondary management service, retrieve the active lease ID of the partition ownership blob and include it in the request headers when modifying the blob's metadata.

Perform metadata updates directly on the partition ownership blob without providing a lease ID, as Azure Storage allows concurrent metadata modifications on leased blobs.

Initialize DefaultAzureCredentialOptions with the explicit ClientId of the User-Assigned Managed Identity, and pass these options when creating the DefaultAzureCredential.

Instantiate the credentials using DefaultAzureCredential without parameters, as Azure will automatically discover and utilize the User-Assigned Managed Identity in a multi-identity environment.

Show answer & explanation

Answer: In the secondary management service, retrieve the active lease ID of the partition ownership blob and include it in the request headers when modifying the blob's metadata.; Initialize DefaultAzureCredentialOptions with the explicit ClientId of the User-Assigned Managed Identity, and pass these options when creating the DefaultAzureCredential.

Answer

To resolve these issues, you must include the active lease ID in the request headers when modifying the partition ownership blob's metadata, and configure DefaultAzureCredentialOptions with the explicit ClientId of the User-Assigned Managed Identity when instantiating the credential.

The correct options ensure that the application handles active blob leases and configures credentials properly. Modifying a leased blob requires passing the active lease ID to satisfy Azure Storage concurrency constraints. Additionally, configuring the DefaultAzureCredential with the specific Client ID allows the application to successfully authenticate using the designated User-Assigned Managed Identity.

Step-by-Step Solution

Address the HTTP 412 error on the partition ownership lease blobs.

Identify that because the EventProcessorClient actively leases these blobs to track ownership, any external service attempting to write to or modify the metadata of these blobs must supply the active lease ID.

Azure Blob Storage enforces write-locks on leased blobs, making the lease ID mandatory for any modifications.

Address the authentication failure for the User-Assigned Managed Identity.

Configure the DefaultAzureCredential constructor by passing DefaultAzureCredentialOptions containing the target User-Assigned Managed Identity's Client ID.

Without explicit configuration, the credential defaults to the System-Assigned Managed Identity or fails to distinguish between multiple assigned identities.

Key Concept

Handling active partition leases in Blob Storage checkpointing and authenticating Event Hubs clients using User-Assigned Managed Identities.

Question 868Question →

You are designing an airline flight booking system that processes seat reservation requests using Azure Service Bus queues. The system must meet the following technical requirements:
- Seat reservations for any specific flight must be processed in the exact order they are received.
- Any duplicate reservation requests sent due to client-side network retries within a 10-minute window must be automatically discarded by the queue.
- If a message fails to be processed after 5 attempts, it must be automatically routed to a dead-letter queue.

Which two configurations should you implement to satisfy the message ordering and duplicate detection requirements? (Select two.)

Select all that apply

Enable sessions on the queue, and set the SessionId property on each sent message to the flight identifier.

Enable duplicate detection on the queue with a 10-minute detection window, and ensure the sender sets a unique MessageId on each message.

Configure the receiver to use the ReceiveAndDelete receive mode, and set the queue's MaxDeliveryCount to 5.

Authenticate the message-sending client using a Shared Access Signature (SAS) token configured with Manage permissions at the namespace level.

Show answer & explanation

Answer: Enable sessions on the queue, and set the SessionId property on each sent message to the flight identifier.; Enable duplicate detection on the queue with a 10-minute detection window, and ensure the sender sets a unique MessageId on each message.

Answer

Enable sessions on the queue while setting the SessionId to the flight identifier, and enable duplicate detection on the queue while ensuring the sender sets a unique MessageId on each message.

To satisfy the requirements, you must enable sessions for message ordering and configure duplicate detection. Specifically, setting the SessionId on sent messages to the flight identifier ensures sequential processing of related messages. Enabling duplicate detection with a 10-minute window requires assigning a unique MessageId to each message so the Service Bus can track and discard duplicates.

Step-by-Step Solution

Enable sessions on the queue and set the SessionId property on each message.

Guarantees FIFO (first-in-first-out) ordering for seat reservations on a per-flight basis, as all messages with the same SessionId are processed sequentially by a single consumer.

Standard queues do not guarantee message order when multiple consumers read from them, but sessions lock messages to a single receiver to enforce order.

Enable duplicate detection on the queue and define a 10-minute duplicate detection window.

Enables the queue to detect duplicate messages sent within the window based on their MessageId.

Ensures that if the sender retries sending a message due to a network timeout, the duplicate message is automatically discarded if it arrives within the configured duplicate detection window.

Set a unique MessageId on each sent message.

Enables Azure Service Bus to match and de-duplicate messages.

Duplicate detection relies entirely on the MessageId property. If this property is not set uniquely by the sender, Service Bus cannot identify duplicates.

Key Concept

Message sessions for FIFO processing and duplicate detection for idempotent message delivery in Azure Service Bus.

Question 869Question →

An e-commerce system writes custom telemetry to Application Insights. To troubleshoot a sudden latency spike in checkout processing, you must identify the top 5 slowest dependencies of type 'HTTP' over the last 6 hours. You must write a query that minimizes resource consumption and query execution time.

Which KQL query should you execute to retrieve these results efficiently?

dependencies
| where type == "HTTP"
| top 5 by duration desc
| where timestamp > ago(6h)

dependencies
| where type == "HTTP"
| top 5 by duration desc

dependencies
| where timestamp > ago(6h) and type == "HTTP"
| top 5 by duration desc

dependencies
| project timestamp, type, duration, name
| top 5 by duration desc
| where type == "HTTP" and timestamp > ago(6h)

Show answer & explanation

Answer: dependencies
| where timestamp > ago(6h) and type == "HTTP"
| top 5 by duration desc

Answer

The query that filters by timestamp and type first, and then applies the top operator: dependencies | where timestamp > ago(6h) and type == "HTTP" | top 5 by duration desc

The correct query applies the time range filter (`timestamp > ago(6h)`) and the type filter (`type == "HTTP"`) immediately at the start of the query pipeline. This ensures that the query engine only scans telemetry data within the specified time window, improving performance. The `top 5 by duration desc` operator is then used to efficiently retrieve the 5 slowest dependencies.

Step-by-Step Solution

Apply the time range filter `timestamp > ago(6h)` and type filter `type == 'HTTP'` at the very beginning of the query pipeline.

Limits the scope of the search to HTTP dependencies logged within the last 6 hours, minimizing data scan.

KQL queries execute operations sequentially; filtering early prevents downstream operations from processing unnecessary historical data.

Use the `top 5 by duration desc` operator to retrieve the slowest dependencies.

Returns the 5 records with the largest `duration` values in descending order.

The `top` operator is optimized for finding the largest values and performs better than sorting the entire dataset with `order by` followed by `take`.

Key Concept

Filtering telemetry data by time range early in Kusto Query Language (KQL) queries to optimize query performance and limit data scanning.

Estimated Time:1m 30s

Question 870Question →

You are configuring a custom gateway domain for an Azure API Management (APIM) instance. The TLS certificate for the custom domain is stored in Azure Key Vault. You have enabled a system-assigned managed identity for the APIM instance. You need to configure the Azure Key Vault access policy to allow the APIM instance to retrieve the TLS certificate while adhering to the principle of least privilege. Which permission must you grant to the APIM system-assigned managed identity in the Key Vault access policy?

`Get` permission under Secret permissions

`Get` permission under Certificate permissions

`Get` permission under Key permissions

`List` permission under Secret permissions and `Get` permission under Certificate permissions

Show answer & explanation

Answer: `Get` permission under Secret permissions

Answer

`Get` permission under Secret permissions

The correct answer is the option specifying the `Get` permission under Secret permissions. When configuring a custom domain in Azure API Management using a certificate stored in Key Vault, API Management must retrieve the complete certificate including the private key. In Azure Key Vault, the private key portion of a certificate is stored as a secret, which requires Secret Get permission to retrieve.

Step-by-Step Solution

Determine the certificate retrieval mechanism.

API Management retrieves the certificate from Azure Key Vault by accessing it as a secret to obtain the private key.

When a certificate with a private key is imported into Key Vault, the private key is stored as a secret.

Identify the minimum permission required for secret retrieval.

The identity requires the 'Get' permission under Secret permissions.

This permission allows the managed identity of the API Management instance to read the certificate content containing the private key.

Verify compliance with the principle of least privilege.

Granting Secret Get provides the exact reading capability needed without adding extra administrative permissions like List or Delete.

Using the specific Secret Get permission ensures only the required read access is given.

Key Concept

Azure API Management custom domain configuration requires Key Vault Secret Get permissions to retrieve the certificate's private key.

Estimated Time:2m 0s

Question 871Question →

You are troubleshooting a performance issue in an Azure Web App. You need to write an optimized Kusto Query Language (KQL) query to find the average duration of requests grouped by the operation name. To avoid the performance impact of scanning all historical telemetry logs, you must first filter the telemetry data to only include requests from the last 6 hours.

Complete the KQL query by filling in the blanks.

Fill in the blanks below

requests
| where >
| summarize AvgDuration = avg(duration) by operation_Name

Show answer & explanation

Answer

The completed query uses the 'timestamp' column and the 'ago(6h)' function to filter for the last 6 hours of requests: `requests | where timestamp > ago(6h) | summarize AvgDuration = avg(duration) by operation_Name`

The correct query begins with the 'requests' table, immediately followed by a filter on the 'timestamp' column using the 'ago(6h)' function. This filters the data to the last 6 hours before performing any aggregations, which is critical for query efficiency. The 'summarize' operator then groups the results by 'operation_Name' and calculates the average duration.

Step-by-Step Solution

Identify the time-range column in the Application Insights telemetry tables.

The 'timestamp' column represents the date and time when the telemetry record was logged.

All telemetry tables in Application Insights (such as requests, dependencies, exceptions) use the 'timestamp' column for tracking log entry times.

Select the appropriate KQL timespan function to calculate the date and time offset for 6 hours ago.

The 'ago(6h)' function returns the datetime value relative to the current UTC time minus 6 hours.

Filtering on timestamp with 'ago()' ensures that only records within the specified window are scanned, preventing expensive full-table scans.

Key Concept

Query optimization using time-range filters in KQL

Question 872Question →

You are configuring mutual TLS (mTLS) authentication between an Azure API Management (APIM) gateway and a backend API hosted on an Azure App Service. The client certificate used for authentication must be securely stored in Azure Key Vault and dynamically retrieved by APIM. You have already enabled a system-assigned managed identity for the APIM instance.

Which two configurations are required to ensure the APIM gateway successfully retrieves the certificate and authenticates with the backend API? (Select two.)

Select all that apply

Grant the API Management system-assigned managed identity Key Vault Secret User (or GET secret) permissions on the Azure Key Vault.

Add the `<authentication-certificate certificate-id="my-cert" />` policy inside the `<inbound>` element of the API policy configuration.

Add the `<authentication-certificate certificate-id="my-cert" />` policy inside the `<outbound>` element of the API policy configuration.

Grant the backend App Service's system-assigned managed identity GET certificate permissions on the Azure Key Vault.

Add the `<authentication-certificate certificate-id="my-cert" />` policy inside the `<on-error>` element of the API policy configuration.

Show answer & explanation

Answer: Grant the API Management system-assigned managed identity Key Vault Secret User (or GET secret) permissions on the Azure Key Vault.; Add the `<authentication-certificate certificate-id="my-cert" />` policy inside the `<inbound>` element of the API policy configuration.

Answer

Grant the API Management system-assigned managed identity Key Vault Secret User (or GET secret) permissions on the Azure Key Vault, and add the `<authentication-certificate certificate-id="my-cert" />` policy inside the `<inbound>` element of the API policy configuration.

To secure the backend connection using mutual TLS (mTLS) with a certificate stored in Azure Key Vault, two main configurations are required: first, the API Management instance must have access to retrieve the certificate's private key from Key Vault, which requires granting its system-assigned managed identity Secret User or Secret GET permissions (as the private key is stored as a secret). Second, the `<authentication-certificate>` policy must be applied in the `<inbound>` policy block to attach the certificate to the outgoing backend request during the TLS handshake.

Step-by-Step Solution

Assign permissions in Azure Key Vault for API Management.

The API Management instance is authorized to retrieve the secret/private key part of the certificate.

Since certificates with private keys are stored as secrets in Azure Key Vault, the API Management managed identity requires Key Vault Secret User or Secret GET permissions to pull the certificate.

Add the certificate reference to the API Management instance.

The certificate is registered in the API Management instance with a specific identifier.

Before the certificate can be referenced in policies, it must be added to the certificates repository of the APIM instance by pointing to the Azure Key Vault secret identifier.

Configure the API inbound policy to use the certificate.

The request sent to the backend includes the designated client certificate.

The `<authentication-certificate>` policy is evaluated during inbound processing to configure the client certificate for the backend connection.

Key Concept

Configuring mutual TLS authentication between Azure API Management and backend services using Key Vault integration and inbound policies.

Question 873Question →

You are designing autoscale rules for a production Azure Virtual Machine Scale Set (VMSS) hosting a microservice API. The VMSS has a minimum instance count of $3$ and a maximum instance count of $10$ .

The current autoscale settings are configured as follows:
* Scale-out rule: When the CPU Percentage (aggregated as Average) is greater than $80\%$ for $10$ minutes, increase the instance count by $2$ .
* Scale-in rule: When the CPU Percentage (aggregated as Average) is less than $T\%$ for $10$ minutes, decrease the instance count by $2$ .

You need to configure the scale-in rule to prevent autoscale flapping (repeated scale-out and scale-in cycles) under constant workload conditions.

Which two changes should you implement? (Select two.)

Select all that apply

Set the scale-in threshold

T

45\%

Set the scale-in threshold

T

55\%

and change the scale-in action to decrease the instance count by

1

Set the scale-in threshold

T

55\%

Set the scale-in threshold

T

65\%

and change the scale-in action to decrease the instance count by

1

Show answer & explanation

Answer: Set the scale-in threshold $T$ to $45\%$ .; Set the scale-in threshold $T$ to $55\%$ and change the scale-in action to decrease the instance count by $1$ .

Answer

To prevent autoscale flapping under constant workload, you should either set the scale-in threshold to 45% or set the scale-in threshold to 55% and change the scale-in action to decrease the instance count by 1.

To prevent autoscale flapping, the average CPU percentage after a scale-in event must remain below the scale-out threshold of 80%. When using the default configuration (decrement by 2), the most restrictive scale-in scenario occurs when scaling from 5 to 3 instances. A scale-in threshold of 45% ensures that the total workload is less than

5 \times 45\% = 225\%

, which translates to a post-scale-in average CPU of less than

75\%

on 3 instances. Alternatively, reducing the decrement to 1 instance allows a higher threshold of 55%. In this case, the most restrictive scenario is scaling from 4 to 3 instances. A threshold of 55% ensures the total workload is less than

4 \times 55\% = 220\%

, leading to a post-scale-in average CPU of less than

73.3\%

. Both options successfully prevent immediate scale-out.

Step-by-Step Solution

Analyze the scale-in condition when scaling from 5 to 3 instances with a decrement of 2.

The scale-in triggers when the average CPU is less than

T\%

, meaning the total workload is less than

5 \times T\%

. After scaling down to 3 instances, the new average CPU is

\frac{5 \times T\%}{3}

We must find a threshold

T

such that the new average CPU is strictly less than the scale-out threshold of 80% to avoid immediate scale-out.

Calculate the maximum safe threshold

T

for a decrement of 2.

\frac{5 \times T}{3} < 80 \implies 5T < 240 \implies T < 48\%

. Thus,

T = 45\%

is safe.

Setting

T

below 48% ensures that the post-scale-in CPU load remains below the scale-out trigger.

Analyze the scale-in condition when scaling from 4 to 3 instances with a decrement of 1.

The scale-in triggers when the average CPU is less than

T\%

, meaning the total workload is less than

4 \times T\%

. After scaling down to 3 instances, the new average CPU is

\frac{4 \times T\%}{3}

We need to verify if changing the decrement to 1 allows a higher threshold like 55%.

Calculate the maximum safe threshold

T

for a decrement of 1.

\frac{4 \times T}{3} < 80 \implies 4T < 240 \implies T < 60\%

. Thus,

T = 55\%

with a decrement of 1 is safe.

Setting

T

below 60% with a decrement of 1 ensures the post-scale-in CPU load remains below the scale-out trigger.

Key Concept

Autoscale flapping occurs when a scale-in action reduces capacity to a point where the remaining instances immediately exceed the scale-out threshold, causing an endless loop. To prevent this, the scale-in threshold and scale-in step size must be configured such that the workload at the trigger point, when distributed over the reduced instance count, does not exceed the scale-out threshold.

Estimated Time:3m 0s

Question 874Question →

You are developing a .NET background service that processes high-value medical prescription renewal messages from an Azure Service Bus queue named `prescriptions-queue`. The system has the following requirements:

1. Messages must be processed reliably; if the application crashes or restarts while a message is being processed, the message must not be lost and must be made available for reprocessing.
2. The application must authenticate to the Service Bus namespace using a managed identity that has an independent lifecycle from the hosting Azure resource.
3. The identity must follow the principle of least privilege, with permissions scoped directly to the queue rather than the entire namespace or resource group.

Which combination of Azure Role-Based Access Control (RBAC) role assignment and code implementation should you use?

Assign the Azure Service Bus Data Receiver role to a System-Assigned Managed Identity at the resource group scope. In code, instantiate the ServiceBusClient using DefaultAzureCredential without specifying a client ID, and create the ServiceBusProcessor using ServiceBusProcessorOptions set to ServiceBusReceiveMode.PeekLock.

Assign the Azure Service Bus Data Receiver role to the User-Assigned Managed Identity at the queue scope. In code, instantiate the ServiceBusClient using DefaultAzureCredential configured with the identity's client ID, and create the ServiceBusProcessor using ServiceBusProcessorOptions set to ServiceBusReceiveMode.PeekLock.

Generate a Shared Access Signature (SAS) token at the Service Bus Namespace level with Manage, Send, and Listen permissions. In code, instantiate the ServiceBusClient using the namespace connection string containing the SAS token, and create the ServiceBusProcessor using ServiceBusProcessorOptions set to ServiceBusReceiveMode.PeekLock.

Show answer & explanation

Answer: Assign the Azure Service Bus Data Receiver role to the User-Assigned Managed Identity at the queue scope. In code, instantiate the ServiceBusClient using DefaultAzureCredential configured with the identity's client ID, and create the ServiceBusProcessor using ServiceBusProcessorOptions set to ServiceBusReceiveMode.PeekLock.

Answer

The correct implementation requires assigning the 'Azure Service Bus Data Receiver' role directly to the User-Assigned Managed Identity at the queue scope. This meets the least privilege principle and the independent lifecycle criteria. In the code, configuring DefaultAzureCredential with the specific user-assigned client ID and setting the processor to PeekLock mode ensures that if the background service crashes during processing, the lock will time out and the message will safely reappear on the queue for subsequent processing.

Step-by-Step Solution

Select the correct identity model for lifecycle requirements.

Identify that a User-Assigned Managed Identity must be used.

The scenario requires the identity to have an independent lifecycle from the hosting resource, which matches User-Assigned rather than System-Assigned.

Apply the least privilege principle for Azure Service Bus RBAC.

Assign the 'Azure Service Bus Data Receiver' role scoped strictly to the queue 'prescriptions-queue'.

Scoping the role to the queue rather than the namespace or resource group satisfies the minimum required scope for consuming messages.

Configure the client and processor for message durability.

Instantiate the client with DefaultAzureCredential pointing to the user identity's client ID and use PeekLock receive mode.

Specifying the client ID targets the correct User-Assigned Identity. PeekLock ensures that messages are locked, processed, and explicitly settled (completed), preventing message loss if the application crashes.

Key Concept

Configuring passwordless Managed Identity authentication and PeekLock receive reliability for Azure Service Bus processing.

Question 875Question →

An organization is deploying an API to Azure API Management (APIM) that communicates with a backend service hosted on Azure App Service. The API must meet the following security requirements:
1. Inbound requests to APIM must be authenticated using OAuth 2.0. APIM must validate that the JWT contains a claim named "roles" containing the value "Writer", and that the token is issued specifically by the company's Azure AD tenant (contoso.onmicrosoft.com). If validation fails, a 401 Unauthorized status must be returned.
2. APIM must authenticate to the backend App Service using a User-Assigned Managed Identity named "apim-identity" (Client ID: 11111111-1111-1111-1111-111111111111).

Which of the following policy configurations should you implement in the APIM policy definition to meet these requirements?

<inbound>
<base />
<validate-jwt header-name="Authorization" failed-validation-httpcode="401" failed-validation-error-message="Unauthorized">
<openid-config url="https://login.microsoftonline.com/contoso.onmicrosoft.com/v2.0/.well-known/openid-configuration" />
<required-claims>
<claim name="roles" match="any">
<value>Writer</value>
</claim>
</required-claims>
</validate-jwt>
<authentication-managed-identity resource="https://backend.contoso.com" client-id="11111111-1111-1111-1111-111111111111" />
</inbound>

<inbound>
<base />
<validate-jwt header-name="Authorization" failed-validation-httpcode="401" failed-validation-error-message="Unauthorized">
<openid-config url="https://login.microsoftonline.com/contoso.onmicrosoft.com/v2.0/.well-known/openid-configuration" />
<required-claims>
<claim name="roles" match="any">
<value>Writer</value>
</claim>
</required-claims>
</validate-jwt>
<authentication-managed-identity resource="https://backend.contoso.com" identity-id="/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg/providers/Microsoft.ManagedIdentity/userAssignedIdentities/apim-identity" />
</inbound>

<inbound>
<base />
<validate-jwt header-name="Authorization" failed-validation-httpcode="401" failed-validation-error-message="Unauthorized">
<openid-config url="https://login.microsoftonline.com/contoso.onmicrosoft.com/v2.0/.well-known/openid-configuration" />
<required-claims>
<claim name="roles" match="any">
<value>Writer</value>
</claim>
</required-claims>
</validate-jwt>
</inbound>
<outbound>
<base />
<authentication-managed-identity resource="https://backend.contoso.com" client-id="11111111-1111-1111-1111-111111111111" />
</outbound>

<inbound>
<base />
<validate-jwt header-name="Authorization" failed-validation-httpcode="401" failed-validation-error-message="Unauthorized">
<openid-config url="https://login.microsoftonline.com/contoso.onmicrosoft.com/v2.0/.well-known/openid-configuration" />
<required-claims>
<claim name="roles" match="any">
<value>Writer</value> </claim> </required-claims>
</validate-jwt>
<authentication-managed-identity resource="https://backend.contoso.com" />
</inbound>

Show answer & explanation

Answer: <inbound>
<base />
<validate-jwt header-name="Authorization" failed-validation-httpcode="401" failed-validation-error-message="Unauthorized">
<openid-config url="https://login.microsoftonline.com/contoso.onmicrosoft.com/v2.0/.well-known/openid-configuration" />
<required-claims>
<claim name="roles" match="any">
<value>Writer</value>
</claim>
</required-claims>
</validate-jwt>
<authentication-managed-identity resource="https://backend.contoso.com" client-id="11111111-1111-1111-1111-111111111111" />
</inbound>

Answer

The policy configuration that places both validate-jwt and authentication-managed-identity with the client-id attribute set to the GUID of the user-assigned managed identity in the inbound section.

The correct configuration places both policies in the inbound section. The validate-jwt policy uses a tenant-specific OpenID Configuration URL to enforce single-tenant token validation and asserts that the roles claim contains the value Writer. The authentication-managed-identity policy correctly specifies the client-id parameter to utilize the user-assigned managed identity.

Step-by-Step Solution

Examine the policy section placement for backend authentication.

The authentication-managed-identity policy must reside in the inbound section so that it executes before the request is forwarded to the backend service.

Placing it in the outbound section would apply authentication to the response returned to the client, which is incorrect.

Determine how to configure the user-assigned managed identity in the policy.

The policy requires the client-id attribute set to the GUID of the user-assigned identity.

If client-id is omitted, APIM defaults to the system-assigned managed identity. Using the resource ID path with an incorrect attribute name like identity-id is not supported.

Ensure the validate-jwt config targets the correct tenant endpoint.

The openid-config URL must reference the specific tenant (contoso.onmicrosoft.com) to restrict token issuance to that directory.

Using a generic endpoint like common would allow tokens from other directories, violating the security requirements.

Key Concept

Securing API Management backend connections using User-Assigned Managed Identity authentication policies and validating inbound JWT scopes and claims.

Estimated Time:3m 0s

Question 876Question →

An Azure App Service web application is experiencing latency issues. You need to write an optimized Kusto Query Language (KQL) query in Application Insights to identify the top 5 slowest dependencies based on their average duration over the last 24 hours. The query must minimize the data scanned to ensure high performance.

Which KQL query should you run?

dependencies
| where timestamp > ago(24h)
| summarize avg_duration = avg(duration) by target
| top 5 by avg_duration desc

dependencies
| summarize avg_duration = avg(duration) by target
| top 5 by avg_duration desc

dependencies
| where timestamp > ago(24h)
| where isnotempty(sdkVersion) and isnotempty(connectionString)
| summarize avg_duration = avg(duration) by target
| top 5 by avg_duration desc

dependencies
| where timestamp > ago(24h)
| where target has "cdn" and url has "cache=bypass"
| summarize avg_duration = avg(duration) by target
| top 5 by avg_duration desc

Show answer & explanation

Answer: dependencies
| where timestamp > ago(24h)
| summarize avg_duration = avg(duration) by target
| top 5 by avg_duration desc

Answer

The KQL query that filters the dependencies table by timestamp first, then calculates the average duration grouped by target, and finally selects the top 5 results sorted in descending order of average duration.

The correct query filters the `dependencies` table by `timestamp > ago(24h)` first to minimize data scanning, then groups by `target` using `summarize` to calculate the average `duration`, and uses the `top` operator to return the 5 slowest dependencies.

Step-by-Step Solution

Filter by time range

Adds `| where timestamp > ago(24h)` right after the table name.

Ensures that the query scans only the last 24 hours of data, optimizing performance.

Aggregate duration by target

Adds `| summarize avg_duration = avg(duration) by target`.

Calculates the average latency (duration) for each unique dependency target.

Sort and limit results

Adds `| top 5 by avg_duration desc`.

Orders the aggregated results by average duration in descending order and returns only the top 5 records.

Key Concept

Optimizing Kusto Query Language (KQL) queries in Azure Application Insights by applying time-range filters early.

Estimated Time:1m 30s

Question 877Question →

An application processes background tasks using Azure Queue Storage. The application retrieves a message and processes it. Because processing can occasionally exceed the initial visibility timeout, the application must extend the visibility timeout of the retrieved message to prevent other workers from processing it concurrently.

Complete the C# code snippet below by filling in the blanks with the correct Azure Storage Queues SDK client library (.NET) method names and property names.

Fill in the blanks below

using System;
using System.Threading.Tasks;
using Azure.Storage.Queues;
using Azure.Storage.Queues.Models;

public class QueueWorker
{
public async Task ProcessMessageAsync(string connectionString)
{
QueueClient queueClient = new QueueClient(connectionString, "orders");

// Retrieve a single message and hide it for 30 seconds
var response = await queueClient.(1, TimeSpan.FromSeconds(30));

if (response.Value.Length > 0)
{
QueueMessage message = response.Value[0];

// Simulating long-running operation...
// Extend the visibility timeout by another 60 seconds without altering the message text
await queueClient.(
message.MessageId,
message.,
visibilityTimeout: TimeSpan.FromSeconds(60)
);

// Complete processing...
}
}
}

Show answer & explanation

Answer

The code requires the ReceiveMessagesAsync method to retrieve messages from the queue with an initial visibility timeout, the UpdateMessageAsync method to modify the message state, and the PopReceipt property to provide the cryptographic lease receipt required to authorize the update operation.

To retrieve and lease messages, ReceiveMessagesAsync must be used. To extend the visibility lease, UpdateMessageAsync must be invoked. The operation requires both the MessageId and the PopReceipt of the message to uniquely identify and authorize the update.

Step-by-Step Solution

Retrieve messages from the queue.

Call the ReceiveMessagesAsync method on the QueueClient object to retrieve messages and set their initial visibility lease.

ReceiveMessagesAsync retrieves messages and makes them invisible to other consumers for the specified visibility timeout.

Update the message's visibility timeout.

Call the UpdateMessageAsync method on the QueueClient object.

UpdateMessageAsync is the standard SDK method used to update a message's visibility timeout and/or body in the queue.

Provide the message identifier and lease token.

Access the PopReceipt property of the retrieved QueueMessage object.

Azure Queue Storage requires the PopReceipt token to verify that the worker currently owns the lock on the message before performing updates or deletion.

Key Concept

Extending message lease visibility timeout using the Azure Storage Queues SDK for .NET.

Question 878Question →

You are developing a C# (.NET) console application that transmits batch telemetry messages to an Azure Event Hub using the modern Azure.Messaging.EventHubs SDK. You need to write the publishing logic using the producer client to optimize performance and prevent message size violations. In which sequence should you perform the steps to initialize the client, build the batch, transmit the events, and release resources?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To publish batch events using Azure.Messaging.EventHubs, you must initialize the EventHubProducerClient, request an EventDataBatch via CreateBatchAsync, invoke TryAdd sequentially to fill the batch while checking boundary limits, execute SendAsync on the client to dispatch the batch, and cleanly end by invoking DisposeAsync.

The publisher lifecycle requires that the producer client is configured first, then the client generates the EventDataBatch, the batch is populated using TryAdd to check for capacity limits, the batch is sent, and finally, resources are cleaned up.

Step-by-Step Solution

Instantiate the client.

An active EventHubProducerClient is initialized with the endpoint details.

The client is the primary interface used to talk to Azure Event Hubs.

Create the batch buffer.

An EventDataBatch object configured with connection-specific size limits is allocated.

Using the client's helper method guarantees that size limitations are automatically respected during addition.

Append events.

The telemetry events are safely loaded into the batch storage.

Checking the return value of TryAdd prevents sending a packet that is larger than the Event Hub partition's allowed payload limit.

Transmit the batch.

The batch of messages is successfully published to Azure Event Hubs.

SendAsync handles serialization and physical network transit.

Dispose the client.

The underlying AMQP connections are closed.

This is critical in high-throughput or serverless solutions to avoid port leak issues.

Key Concept

EventHubProducerClient batch publishing pattern using Azure.Messaging.EventHubs SDK

Question 879Question →

You are configuring Azure API Management (APIM) to route requests to a secure backend Azure Function app. The backend function app requires Microsoft Entra ID authentication. You enable a user-assigned managed identity on the APIM instance, which has a client ID of `11111111-2222-3333-4444-555555555555`. You must configure APIM to authenticate against the backend function using this user-assigned managed identity. You define the following policy configuration:

xml
<policies>
<inbound>
<base />
<authentication-managed-identity resource="https://my-backend-function.azurewebsites.net" />
</inbound>
<backend>
<base />
</backend>
<outbound>
<base />
</outbound>
</policies>

When you test the API, requests to the backend fail with an HTTP 401 Unauthorized status. Which of the following modifications to the policy definition will resolve this issue?

Move the authentication-managed-identity element to the outbound section and add the client-id="11111111-2222-3333-4444-555555555555" attribute.

Omit the resource attribute in the inbound section to allow the policy to default to the function app's audience and use the system-assigned identity context.

Add the client-id="11111111-2222-3333-4444-555555555555" attribute to the authentication-managed-identity element in the inbound section.

Modify the policy to use the identity-id attribute pointing to an Azure Key Vault secret reference to retrieve the secret credentials of the identity.

Show answer & explanation

Answer: Add the client-id="11111111-2222-3333-4444-555555555555" attribute to the authentication-managed-identity element in the inbound section.

Answer

Add the client-id attribute containing the user-assigned managed identity's client ID to the authentication-managed-identity element in the inbound section.

Specifying the client-id attribute with the user-assigned managed identity's client ID inside the authentication-managed-identity element in the inbound section tells API Management to use that specific identity to retrieve an access token. Because the policy is situated in the inbound section, the token is obtained and attached to the Authorization header before APIM forwards the request to the secure backend.

Step-by-Step Solution

Analyze the error context

The APIM instance is failing to authenticate against the secure backend function because the authentication policy is missing information about which identity to use.

By default, the authentication-managed-identity policy attempts to use the system-assigned managed identity if no client-id or identity-id is specified.

Identify the required identity configuration

The scenario explicitly states that the APIM instance has been configured with a user-assigned managed identity.

To use a user-assigned managed identity, the policy must explicitly provide the client ID or resource ID of that identity.

Determine the correct policy section placement

The authentication-managed-identity policy must execute in the inbound section.

The token must be acquired and attached to the request headers before the request is forwarded to the backend service. Doing this in the outbound section would be too late as the outbound section only processes responses.

Key Concept

API Management policies can use managed identities to acquire access tokens for backend services. When using user-assigned managed identities, the client ID or resource ID must be specified using the client-id or identity-id attributes in the inbound policy section.

Question 880Question →

You are troubleshooting a performance degradation in an Azure Web App. You need to analyze the daily failure rate of incoming HTTP requests recorded in Application Insights over the last 7 days. To prevent query timeouts and minimize resource usage on your Application Insights resource, the queries must be optimized. Which two of the following Kusto Query Language (KQL) queries will successfully calculate the daily failure rate while meeting the optimization requirement?

Select all that apply

requests | where timestamp > ago(7d) | summarize FailureRate = countif(success == false) * 100.0 / count() by bin(timestamp, 1d)

requests | where timestamp > ago(7d) | summarize SuccessCount = countif(success == true), TotalCount = count() by bin(timestamp, 1d) | project timestamp, FailureRate = (TotalCount - SuccessCount) * 100.0 / TotalCount

requests | summarize FailureRate = countif(success == false) * 100.0 / count() by bin(timestamp, 1d)

requests | summarize SuccessCount = countif(success == true), TotalCount = count() by bin(timestamp, 1d) | project timestamp, FailureRate = (TotalCount - SuccessCount) * 100.0 / TotalCount

Show answer & explanation

Answer: requests | where timestamp > ago(7d) | summarize FailureRate = countif(success == false) * 100.0 / count() by bin(timestamp, 1d); requests | where timestamp > ago(7d) | summarize SuccessCount = countif(success == true), TotalCount = count() by bin(timestamp, 1d) | project timestamp, FailureRate = (TotalCount - SuccessCount) * 100.0 / TotalCount

Answer

The queries that filter requests where the timestamp is greater than seven days ago and then summarize the failure rate by daily bins.

The correct queries analyze request failures by either directly counting unsuccessful requests (success == false) or subtracting successful requests from total requests. Both queries utilize the where timestamp > ago(7d) filter, which restricts the telemetry scan to the target window and ensures the query executes efficiently without timing out.

Step-by-Step Solution

Filter the telemetry data by time range using a where operator with the timestamp.

The database engine scans only the partition matching the last 7 days, optimizing query speed and reducing resource consumption.

To prevent full table scans and query timeouts, KQL queries in Application Insights must specify a time range.

Use the summarize operator to group the requests daily using the bin function on the timestamp and compute the failure rate.

A dataset grouped by day containing the calculated percentage of failed requests.

Grouping by a daily time bin allows tracking failure trends over time, and dividing failed requests by total requests yields the failure rate.

Key Concept

Optimizing KQL queries in Application Insights by applying time-range filters to prevent performance degradation.

PreviousPage 44 / 49Next

All practice questions

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept