All practice questions

972 questions

Question 561Question

An Azure App Service web app retrieves secrets from an Azure Key Vault. You configure Application Insights to monitor the web app. During testing, you find that no telemetry data is arriving in Application Insights. In addition, you must establish an alert that sends an email to the operations team if the Key Vault's overall availability falls below 99% over a 5-minute interval. Which configuration should you implement to resolve the telemetry issue and set up the alert?

Show answer & explanation

Answer: Set the APPLICATIONINSIGHTS_CONNECTION_STRING in the App Service application settings. Create an Azure Monitor metric alert rule for the Key Vault resource with the Availability metric set to less than 99%, and associate it with an Action Group containing an email receiver.

Answer

To resolve the telemetry issue, configure the APPLICATIONINSIGHTS_CONNECTION_STRING application setting in the App Service. To implement the alerting system, configure an Azure Monitor metric alert rule on the Key Vault targeting the Availability metric, and associate it with an Action Group containing an email receiver.
The correct configuration requires adding the APPLICATIONINSIGHTS_CONNECTION_STRING app setting to the App Service web app to ensure telemetry is sent to Application Insights. In addition, an Azure Monitor metric alert rule must be configured on the Key Vault's Availability metric with a threshold below 99% and linked to an Action Group containing an email receiver.

Step-by-Step Solution

1
Identify the root cause of the missing telemetry in Application Insights.
Determine that the App Service needs the APPLICATIONINSIGHTS_CONNECTION_STRING setting configured to route telemetry.
Without the connection string, the App Insights SDK does not know where to send application telemetry.
2
Determine the correct alert rule type for tracking Key Vault availability.
Select a metric alert rule targeting the Availability metric on the Key Vault resource.
Availability is a near real-time metric measured over a time window, which requires a metric alert rather than an activity log alert.
3
Configure the notification mechanism.
Create an Azure Action Group containing an email receiver, and associate this Action Group with the metric alert rule.
Action Groups define the list of notification preferences and actions to execute when the alert rules are triggered.

Key Concept

Azure Monitor Metric Alerts and Action Groups configuration combined with Application Insights telemetry configuration
Estimated Time:1m 30s
Question 562Question

You are developing a serverless monitoring solution using Azure Durable Functions in C# (.NET Isolated). The orchestrator function is designed to poll an external database migration status endpoint every 55 minutes until the status returns as 'Success' or 'Failed'. To comply with orchestrator constraints and avoid wasting resources, the orchestrator must yield execution and release the thread between status checks.

Which code segment should you use in the orchestrator function to implement the 55-minute wait?

Show answer & explanation

Answer: DateTime nextCheck = context.CurrentUtcDateTime.AddMinutes(5);
await context.CreateTimer(nextCheck, CancellationToken.None);

Answer

The correct code segment uses context.CurrentUtcDateTime and context.CreateTimer to create a deterministic, durable delay.
The correct code segment utilizes the context object's CurrentUtcDateTime property to calculate a deterministic expiration time, and then calls context.CreateTimer. This ensures that the time remains identical during orchestrator replays, preventing execution mismatches, while safely yielding thread resources back to the hosting platform.

Step-by-Step Solution

1
Analyze the orchestrator function requirements for delaying execution.
The orchestrator must pause for 55 minutes in a durable, non-blocking, and deterministic manner.
Orchestrators are replayed to rebuild state, meaning standard thread-blocking or non-durable asynchronous delays are invalid.
2
Evaluate the source of current time inside the orchestrator.
Using DateTime.UtcNow is non-deterministic. Using context.CurrentUtcDateTime is deterministic.
DateTime.UtcNow changes on each replay execution, whereas context.CurrentUtcDateTime reads the execution history to return the same timestamp consistently.
3
Select the correct mechanism to register the timer with the Durable Functions framework.
Use context.CreateTimer with a deterministic target time.
context.CreateTimer writes a timer start event to the history and yields execution, allowing the system to scale to zero until the timer fires.

Key Concept

Durable Functions orchestrator constraints and durable timers
Estimated Time:1m 30s
Question 563Question

An administrator provisions a new Azure API Management (APIM) instance and imports several backend services as APIs. You need to configure APIM to package these APIs and allow external developers to register and obtain subscription keys to consume them.

Which two components must you configure in APIM to achieve this goal? (Select two.)

Select all that apply

Show answer & explanation

Answer: Products; Subscriptions

Answer

To publish APIs and provide access via subscription keys to developers, you must configure Products and Subscriptions.
Products are used to group one or more APIs and present them to developers. Subscriptions are the actual keys provided to developers to grant them access to those products. Together, these two components enable key-based developer access.

Step-by-Step Solution

1
Group the imported APIs into one or more Products in APIM.
The APIs are packaged together under a defined scope with usage terms.
In APIM, APIs must be associated with a product before they can be made available to developers.
2
Enable subscription requirements on the product and create or allow developers to request a Subscription.
A subscription is established, generating primary and secondary subscription keys.
Subscriptions grant access to products and provide the actual keys that developers include in API requests.

Key Concept

Azure API Management Publishing Model
Question 564Question

You are troubleshooting an application error on a Windows-based Azure App Service named `marketing-prod` in a resource group named `marketing-rg`.

You need to perform the following tasks:
1. Enable verbose-level application logging to the file system.
2. Monitor the log messages in real-time as they occur.
3. Generate telemetry by sending HTTP requests to the application.
4. Download the historical log files locally for offline review.

Which sequence of Azure CLI commands and actions should you perform? To answer, arrange the actions in the correct order.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

First, configure the application logging to the file system with verbose level. Second, start the log tail stream to listen for logs. Third, make HTTP requests to generate log data. Finally, download the consolidated logs using the Azure CLI.
The correct sequence begins by configuring the App Service to log application traces to the filesystem at a verbose level. Next, starting the log stream ensures that the developer can monitor incoming events in real-time. Tailing must occur before sending requests so that transient startup log entries are not missed. Once the stream is active, generating traffic triggers the application logic and records the diagnostic information. Finally, downloading the log files aggregates all of the persistent log data for deep offline analysis.

Step-by-Step Solution

1
Configure the web app log settings.
FileSystem application logging is enabled with the verbose severity level.
Before logs can be streamed or downloaded, logging must be explicitly enabled and configured on the App Service instance.
2
Initiate the log streaming session.
A persistent connection to the App Service log streaming endpoint is established.
Starting the tail session before sending requests ensures that the live stream captures the initial errors as they occur.
3
Generate web application traffic.
Application events and errors are triggered and written to the filesystem and the stream.
This generates the diagnostic data required to identify the root cause of the application error.
4
Download the diagnostic logs.
A ZIP archive containing the log files is saved to the local machine.
This retrieves the complete set of log files for offline analysis and permanent archiving.

Key Concept

Azure App Service built-in diagnostic logging and log streaming lifecycle via Azure CLI
Question 565Question

You are deploying a backend worker service as an Azure Container App named `order-processor`. The app needs to process messages from an Azure Service Bus queue named `orders` and scale dynamically between 11 and 1010 replicas based on the queue depth. You are configuring this deployment using a Bicep template.

Which two of the following configurations must you define in the Bicep template to meet these scaling requirements? (Select two.)

Select all that apply

Show answer & explanation

Answer: Define the `minReplicas` and `maxReplicas` properties within the `scale` block under the `template` section of the Container App resource properties.; Add a scaling rule to the `rules` array under the `scale` block, defining a `custom` rule type with the `type` property set to `'azure-servicebus'`.

Answer

To configure scaling based on an Azure Service Bus queue, you must define the minimum and maximum replicas inside the template's scale block, and define a custom scaling rule inside the rules array with the type set to 'azure-servicebus'.
Defining the replication boundaries within the scale block under the template property sets the minimum and maximum limits. Since there is no dedicated Service Bus schema element, using a custom rule with the type set to 'azure-servicebus' correctly instructs the underlying KEDA engine to connect to and monitor the Service Bus queue.

Step-by-Step Solution

1
Set scaling limits inside the Bicep template.
Define `properties.template.scale.minReplicas` as 11 and `properties.template.scale.maxReplicas` as 1010.
This establishes the minimum and maximum scaling boundaries for the container instances.
2
Configure the scaling trigger type.
Create an entry in the `properties.template.scale.rules` array containing a `custom` object where `type` is set to `'azure-servicebus'`. Provide the queue name and trigger threshold within the `metadata` object.
Azure Container Apps scales using KEDA. While Azure Storage Queues have a dedicated `azureQueue` helper block, Azure Service Bus requires using the generic `custom` block targeting the `'azure-servicebus'` KEDA scaler.

Key Concept

Configuring KEDA-based custom autoscaling rules in Azure Container Apps Bicep templates.
Question 566Question

You are configuring an Azure Monitor alert rule to notify your operations team when a critical application error occurs. You need to configure the Azure Monitor Action Group that will handle the response.

Which of the following actions are supported directly within an Azure Monitor Action Group? (Select two).

Select all that apply

Show answer & explanation

Answer: Sending an email notification to users assigned to a specific Azure Resource Manager (ARM) Role; Triggering an Azure Function to execute a custom remediation workflow

Answer

Sending an email notification to users assigned to a specific Azure Resource Manager (ARM) Role and Triggering an Azure Function to execute a custom remediation workflow
Azure Monitor Action Groups natively support sending email notifications to members assigned to specific Azure Resource Manager (ARM) roles, as well as triggering Azure Functions to execute custom automation code.

Step-by-Step Solution

1
Identify the purpose of an Azure Monitor Action Group.
Action Groups are collections of notification preferences and actions triggered by an alert.
Understanding the boundary between Alert Rules (which evaluate conditions) and Action Groups (which execute notifications or automation) is key.
2
Evaluate the supported notification and action types in an Action Group.
Supported actions include Email/SMS/Push/Voice, Azure Functions, Logic Apps, Webhooks, Automation Runbooks, ITSM, and Event Hubs.
This confirms that sending emails to ARM roles and triggering Azure Functions are native action types.
3
Differentiate between alert actions and autoscale or security operations.
Scaling operations are defined via Autoscale rules. Credentials or secret retrieval from Key Vault is not a native action group feature.
This rules out the incorrect options regarding App Service scaling and Key Vault secret retrieval.

Key Concept

Azure Monitor Action Groups define a collection of notification preferences and actions to execute when an alert is triggered, supporting native integrations with email, ARM roles, Azure Functions, Logic Apps, and Webhooks.
Question 567Question

You are developing a Single Page Application (SPA) using React and MSAL.js 2.x2.\text{x}. The application must authenticate users using the Microsoft Identity Platform and call a downstream secured Microsoft Graph API. You register the application in the Microsoft Entra admin center. Under the Authentication blade, you add a redirect URI of `http://localhost:3000` but configure the platform type as Web instead of Single-page application. During testing, users can successfully sign in and the application receives an authorization code. However, when the application attempts to exchange the authorization code for an access token, the token endpoint returns an error. You need to resolve the error and ensure that the application can successfully acquire access tokens. Which of the following actions should you perform?

Show answer & explanation

Answer: In the app registration, change the redirect URI platform type from Web to Single-page application.

Answer

Change the redirect URI platform type from Web to Single-page application in the app registration.
The correct action is to change the redirect URI platform type from Web to Single-page application. Microsoft Identity Platform requires browser-based SPAs to use the Single-page application platform type, which supports the Authorization Code Flow with Proof Key for Code Exchange (PKCE). This configuration allows the token endpoint to safely exchange the authorization code for an access token without requiring a client secret, which cannot be kept secure in a browser-based environment.

Step-by-Step Solution

1
Identify the client application type and the authentication requirements.
The application is a browser-based Single Page Application (SPA) requiring user login and token acquisition for Microsoft Graph.
Understanding the application architecture helps in selecting the correct OAuth 2.0 flow.
2
Determine why the token exchange request is failing when using the 'Web' platform registration.
The 'Web' platform registration expects a client secret for authorization code redemption, which the SPA cannot provide.
Public clients like SPAs cannot securely store credentials on the client-side.
3
Select the correct platform registration configuration in Microsoft Entra ID.
Configure the platform type as 'Single-page application' (SPA) to enable the Authorization Code Flow with PKCE.
The SPA platform registration tells Microsoft Identity Platform to allow public token exchange without a client secret.

Key Concept

Single-page application platform registration and PKCE flow requirements in Microsoft Entra ID.
Estimated Time:2m 0s
Question 568Question

A manufacturing company is implementing an Azure Event Grid custom topic to process telemetry reports from IoT sensors. Individual telemetry payloads can reach up to 100 KB100\text{ KB} in size. You plan to configure an Event Grid subscription that routes these events directly to an Azure Queue Storage queue for processing by a background service. Which statement correctly identifies the limitation of this design and the appropriate solution?

Show answer & explanation

Answer: Queue Storage has a maximum message size limit of 64 KB64\text{ KB}. You must store the telemetry payload in Azure Blob Storage and route only the blob URL reference via Event Grid.

Answer

Queue Storage has a maximum message size limit of 64 KB64\text{ KB}. You must store the telemetry payload in Azure Blob Storage and route only the blob URL reference via Event Grid.
The correct answer states that Queue Storage has a maximum message size limit of 64 KB64\text{ KB}, and that the telemetry payload must be stored in Azure Blob Storage while routing only the blob URL reference. This correctly addresses the physical constraints of Azure Queue Storage and follows the Azure integration architecture guidelines.

Step-by-Step Solution

1
Analyze the size of the payloads compared to the destination limits.
The payloads are up to 100 KB100\text{ KB}, which exceeds the 64 KB64\text{ KB} maximum message size limit of Azure Queue Storage.
Azure Queue Storage has a hard limit of 64 KB64\text{ KB} per message. Any attempt to write a larger message directly will fail.
2
Determine the appropriate pattern for handling large message payloads in Event Grid.
Use the Claim-Check pattern by storing the large payload in Azure Blob Storage.
Instead of sending the raw payload directly through the message queue, the payload is stored in a data store, and the event notification contains only the reference link.
3
Route the reference metadata through Event Grid.
The Event Grid subscriber reads the blob URL, fetches the payload, and processes it.
This keeps the event payload well below the 64 KB64\text{ KB} limit, ensuring successful delivery to Queue Storage.

Key Concept

Handling large message payloads in Event Grid subscriptions using the Claim-Check pattern.
Estimated Time:1m 30s
Question 569Question

A developer hosts a web application on a Windows-based Azure App Service. To troubleshoot intermittent database connection errors, the developer enables Application Logging (Filesystem) with a level of Verbose. Two days later, the developer notices that new log files are no longer appearing in the filesystem, even though the database connection errors are still occurring. Which of the following explains why the log files are no longer being generated?

Show answer & explanation

Answer: Application logging configured to use the local filesystem is automatically disabled by Azure after 12 hours.

Answer

Application logging configured to use the local filesystem is automatically disabled by Azure after 12 hours.
The correct option is correct because when you enable application logging to the filesystem in Azure App Service, Azure automatically disables this setting after 12 hours. This prevents the local disk space from filling up, especially under verbose logging levels. If persistent logging is required, application logs must be configured to write to Azure Blob Storage.

Step-by-Step Solution

1
Analyze the configured log target and lifetime behavior.
Filesystem-based application logging is identified as the active logging target.
Different log targets in Azure App Service have different behaviors and persistence rules.
2
Recall the built-in limitation for App Service filesystem logs.
Azure App Service enforces a strict 12-hour limit on filesystem-based application logging.
This restriction prevents the local VM filesystem from running out of disk space due to runaway verbose log generation.
3
Evaluate the options against the 12-hour expiration rule.
The option stating that filesystem application logging is automatically disabled after 12 hours is the correct explanation.
This explains why logs stopped appearing after two days, as the logging was turned off by the platform after the first 12 hours.

Key Concept

App Service application logs configured to the local filesystem are temporary and automatically turn off after 12 hours.
Question 570Question

You are developing a C# application that updates the metadata and changes the access tier of an existing blob using the `Azure.Storage.Blobs` SDK. The blob is currently protected by an active write lease. You also need to retrieve the updated metadata to verify the changes.

Which two actions must you perform? (Select two.)

Select all that apply

Show answer & explanation

Answer: Provide the active lease ID within a `BlobRequestConditions` object passed to the metadata and access tier update methods.; Reference the metadata keys using lowercase strings when reading them from the retrieved `Metadata` dictionary.

Answer

Provide the active lease ID within a BlobRequestConditions object, and reference the metadata keys using lowercase strings when reading them from the retrieved Metadata dictionary.
Updating a leased blob's metadata and access tier requires providing the active lease ID in the request conditions. Additionally, because the Azure Blob Storage service converts all metadata keys to lowercase on the server, you must retrieve them using lowercase keys to avoid key lookup errors.

Step-by-Step Solution

1
Address the active write lease requirement.
Ensure the active lease ID is passed within the request conditions.
An active write lease prevents any write operations (including metadata and access tier changes) unless the corresponding lease ID is provided.
2
Address the metadata retrieval case sensitivity.
Ensure all metadata lookups in the C# dictionary use lowercase keys.
The Azure Storage service stores all metadata keys in lowercase. The .NET SDK does not normalize key lookups, so searching for mixed-case keys will fail.

Key Concept

Concurrency management with blob leases and case-insensitivity behavior of blob metadata in the Azure SDK.
Question 571Question

You are developing a secure application in C# that interacts with an Azure Storage account. The application must generate a Shared Access Signature (SAS) token to grant an external service temporary read and write permissions to a private blob container named invoices. The solution must meet the following security requirements:

- Access must be limited to HTTPS only.
- The storage account access keys must not be exposed or used to sign the SAS.
- The SAS must be valid for exactly two hours, starting immediately, while accounting for potential clock synchronization differences between clients and Azure.

Which two actions should you perform to create the SAS token? (Select two.)

Select all that apply

Show answer & explanation

Answer: Request a user delegation key from the BlobServiceClient using an Azure AD credential such as DefaultAzureCredential.; Set the StartsOn property of the BlobSasBuilder to 10 minutes prior to the current UTC time.

Answer

To secure the SAS without exposing account keys and to handle potential clock synchronization issues, you must request a user delegation key using Azure AD credentials and set the start time of the SAS builder to 10 minutes in the past.
A User Delegation SAS uses Azure AD credentials (e.g. DefaultAzureCredential) to secure the token, which avoids exposing storage account access keys. Setting the start time 10 minutes in the past ensures the token is immediately valid even if client and server clocks are out of sync (clock skew).

Step-by-Step Solution

1
Acquire credentials using Azure Active Directory to sign the token.
A user delegation key is requested via the BlobServiceClient.
This avoids using or exposing the storage account access keys directly.
2
Set the start time of the token builder in the past.
The StartsOn property is configured to 10 minutes prior to the current time.
This accounts for clock skew between the client machines and Azure infrastructure.
3
Configure the allowed protocol.
The Protocol property is set to Https only.
This ensures compliance with security guidelines to forbid unencrypted HTTP traffic.

Key Concept

User Delegation SAS configuration and clock skew mitigation
Question 572Question

You are implementing an alert rule in Azure Monitor to detect when an Azure App Service web app exceeds its allocated memory limit. When the alert fires, you want to send an email notification to the operations team and trigger a webhook.

Which Azure Monitor resource must you configure and associate with the alert rule to define these notification and routing actions?

Show answer & explanation

Answer: An Action Group

Answer

An Action Group
The correct answer is the option stating 'An Action Group'. In Azure Monitor, an Action Group is a reusable collection of notification preferences (such as email, SMS, or voice) and actions (such as webhooks, Azure Functions, or Logic Apps) that can be triggered when an alert rule is activated.

Step-by-Step Solution

1
Identify the requirement to send an email notification and trigger a webhook when an Azure Monitor alert fires.
The target component must support both notification receivers (email) and automation actions (webhook).
This helps narrow down the Azure Monitor components to the one that handles post-alert triggering behaviors.
2
Evaluate Azure Monitor components against this requirement.
Action Groups support email, SMS, push notifications, voice, webhooks, Azure Functions, Logic Apps, and automation runbooks.
Determining the correct component that acts as the container for these actions.
3
Confirm that other Azure resources such as Autoscale settings, Diagnostic settings, or Key Vault access policies do not perform notification routing.
Only Action Groups are associated with alert rules to perform these tasks.
Validates the correct answer and eliminates distractors.

Key Concept

Azure Monitor Action Groups define a collection of notification preferences and actions to execute when an alert triggers.
Question 573Question

You are configuring caching for an Azure CDN Standard from Microsoft endpoint. The endpoint distributes content for a web application that includes:

- Static product images under `/images/products/` which should be cached long-term.
- An API endpoint at `/api/inventory/status` that returns real-time stock levels and must not be cached by the CDN.
- A search page at `/search` that displays results based on a query parameter named `q`. Each unique search query must be cached independently to optimize performance for recurring searches.

Which two configuration settings should you apply to the Azure CDN endpoint? (Select two.)

Select all that apply

Show answer & explanation

Answer: Configure the query string caching behavior to Cache every unique URL.; Create a custom caching rule for the path /api/inventory/status and set the caching behavior to Bypass cache.

Answer

Configure the query string caching behavior to Cache every unique URL, and create a custom caching rule for the path /api/inventory/status set to Bypass cache.
To support caching unique search terms, the CDN must cache every unique URL separately. To prevent caching of real-time inventory API responses, a custom bypass rule for the path is required.

Step-by-Step Solution

1
Analyze caching requirements for the search query parameters.
To cache each unique query string independently, the CDN needs to recognize query strings as unique assets. This requires setting the query string caching behavior to Cache every unique URL.
This configuration ensures that requests with different query parameter values are cached and served separately.
2
Analyze caching requirements for the real-time API endpoint.
The path `/api/inventory/status` must bypass the CDN cache entirely to ensure real-time inventory data is retrieved from the origin.
Creating a custom caching rule targeting the `/api/inventory/status` path with a Bypass cache setting prevents the CDN from caching any responses for this endpoint.

Key Concept

Azure CDN caching rules and query string caching behavior configuration
Question 574Question

You are developing a C# service that manages smart-home IoT devices using the Azure Cosmos DB .NET SDK v3. The container stores configuration settings and is partitioned by the `/deviceId` path. The database uses Session consistency. When a device's settings are updated, your service must replace the existing document, retrieve the resulting session token to pass to other reading clients, and ensure the write operation is routed to the correct partition. Which C# code segment should you use?

Show answer & explanation

Answer: ItemResponse<DeviceConfig> response = await container.ReplaceItemAsync<DeviceConfig>(config, config.Id, new PartitionKey(config.DeviceId));
string sessionToken = response.Headers.Session;

Answer

The correct option is the one that calls ReplaceItemAsync using config.Id and a PartitionKey instantiated with config.DeviceId, and then retrieves the session token using response.Headers.Session.
The correct code segment uses the ReplaceItemAsync method of the Container class to update the item. It correctly passes the unique document ID and a PartitionKey initialized with the deviceId. The session token is then successfully extracted from the Headers.Session property of the ItemResponse object.

Step-by-Step Solution

1
Select the correct Cosmos DB .NET SDK v3 item replacement method.
Use container.ReplaceItemAsync<T>, passing the item, its ID, and the partition key value.
This performs a point-update (replace) on the existing item.
2
Ensure the write operation is correctly partitioned.
Provide the deviceId value to the PartitionKey constructor (new PartitionKey(config.DeviceId)).
The container partition key path is /deviceId, so all operations on a device's settings must target its deviceId partition.
3
Retrieve the session token for consistency propagation.
Access response.Headers.Session.
The session token is returned in the HTTP headers of the SDK response.

Key Concept

Replacing items in Azure Cosmos DB using the .NET SDK v3 and capturing the Session consistency token.
Estimated Time:1m 30s
Question 575Question

Your company is developing a background service to process telemetry from an Azure Event Hub. The service is written in C# using the .NET SDK, and it utilizes the `EventProcessorClient` class. To coordinate partition ownership and perform checkpointing, the service uses an Azure Blob Storage container as its checkpoint store.

Which configuration or permission is required to ensure that the `EventProcessorClient` can successfully coordinate partition ownership between multiple running instances of the service?

Show answer & explanation

Answer: The service's identity must have permissions to read, write, and manage leases on the blobs within the specified Azure Blob Storage container.

Answer

The service's identity must have permissions to read, write, and manage leases on the blobs within the specified Azure Blob Storage container.
The correct answer is correct because the EventProcessorClient coordinates partition ownership by creating metadata blobs in the checkpoint store and acquiring leases on them. Thus, the client requires read, write, and lease management permissions on the container.

Step-by-Step Solution

1
Analyze how EventProcessorClient coordinates partition distribution.
The EventProcessorClient uses Azure Blob Storage as a checkpoint store, where each partition is represented by a blob.
Understanding the backend mechanism helps identify the required permissions and actions.
2
Determine the role of blob leases in partition coordination.
The processor instances acquire leases on these blobs to claim ownership of specific partitions.
This establishes that lease management permissions are essential for proper load balancing and ownership tracking.
3
Select the option that matches the required permissions.
Permissions to read, write, and manage leases are required on the target container.
Without these permissions, the client cannot check state, update checkpoints, or hold partition leases.

Key Concept

Azure Event Hubs EventProcessorClient checkpointing and partition coordination with Azure Blob Storage
Estimated Time:45s
Question 576Question

You are troubleshooting performance issues in an Azure web application. You need to write a Kusto Query Language (KQL) query in Application Insights to analyze external dependency calls.

The query must meet the following requirements:
- Retrieve data logged in the last 1212 hours.
- Identify dependency calls that took longer than 22 seconds to complete.
- Group the results by the target and type of the dependency.
- Calculate the 90th90\text{th} percentile of the duration for each group.
- Execute with optimal performance and minimize the volume of scanned telemetry data.

Which two of the following KQL queries should you use to satisfy these requirements?

Select all that apply

Show answer & explanation

Answer: dependencies
| where timestamp > ago(12h)
| where duration > 2000
| summarize percentiles(duration, 90) by target, type; dependencies
| where timestamp > ago(12h) and duration > 2000
| summarize percentiles(duration, 90) by target, type

Answer

The correct queries are the ones that filter by the timestamp within the last 1212 hours early in the pipeline, use 20002000 milliseconds as the duration threshold, and calculate the 90th90\text{th} percentile grouped by target and type.
The correct options filter the dataset by time range (`timestamp > ago(12h)`) and dependency duration (`duration > 2000`) before running the summarization function. In KQL, applying filtering early reduces the dataset size for down-pipeline operations, which satisfies the optimization requirement. In Application Insights telemetry, the dependency duration is measured in milliseconds, so a filter value of `2000` is required to match 22 seconds.

Step-by-Step Solution

1
Determine the telemetry source table and filter for the target time window.
Query the `dependencies` table and apply `where timestamp > ago(12h)` at the start of the query pipeline.
Applying the time filter first minimizes the partition scanning and optimizes overall query performance.
2
Convert the duration requirement into milliseconds and apply the filter.
Apply a filter of `where duration > 2000`.
The `duration` column in the Application Insights `dependencies` table is measured in milliseconds, meaning 22 seconds is equivalent to 20002000 milliseconds.
3
Group and calculate the required percentile.
Use `summarize percentiles(duration, 90) by target, type`.
The `percentiles()` aggregation calculates the specified percentile (in this case, the 90th90\text{th} percentile) for each unique combination of the grouping columns.

Key Concept

Optimizing Application Insights KQL queries by utilizing early time-range filtering and performing correct unit conversions on telemetry metrics.
Question 577Question

You are setting up monitoring for a multi-tier web application. You need to configure an Azure Monitor Log Search alert rule to detect critical database exceptions logged to Application Insights, and configure an Action Group to notify your DevOps team via their internal API endpoint. Which two configurations should you implement to achieve this?

Select all that apply

Show answer & explanation

Answer: Configure a Kusto Query Language (KQL) query targeting the exceptions table to identify the error, ensuring the query runs within the alert rule's configured evaluation time window.; Configure a Webhook action in the Action Group to send JSON payloads to the internal API endpoint when the alert triggers.

Answer

To implement this monitoring solution, you must configure a Kusto Query Language (KQL) query targeting the exceptions table within the alert's evaluation window, and configure a Webhook action in the Action Group to send JSON payloads to the internal API endpoint.
Writing a KQL query on the exceptions table within the lookback window ensures that the alert rule can detect errors. Adding a Webhook action to the Action Group allows the alert to post notifications to the team's internal API endpoint.

Step-by-Step Solution

1
Write the KQL query to run against Application Insights data.
The query targets the exceptions table and filters for database exceptions.
This is necessary for the Log Search alert to identify the specific error state.
2
Create an Azure Monitor Action Group.
An Action Group containing a Webhook receiver pointing to the internal API is created.
This enables automated notification to the DevOps team's endpoint.
3
Bind the Log Search alert rule to the Action Group.
The alert rule triggers the Action Group whenever the threshold is exceeded.
This links the detection mechanism to the notification mechanism.

Key Concept

Azure Monitor Log Search alerts utilize KQL queries to evaluate telemetry data (like exceptions) over a specific time window, and Action Groups route alerts to receivers such as Webhooks.
Estimated Time:2m 0s
Question 578Question

You provision a new Azure API Management (APIM) instance. You need to configure the APIM instance to authenticate securely to a backend Azure App Service API without storing any credentials, connection strings, or certificates in the APIM configuration. What should you configure first on the API Management instance?

Show answer & explanation

Answer: Enable a system-assigned managed identity on the API Management instance.

Answer

Enable a system-assigned managed identity on the API Management instance.
Enabling a system-assigned managed identity on the API Management instance creates a security identity in Microsoft Entra ID for the resource. APIM can then use this identity to obtain Microsoft Entra ID tokens and authenticate to the backend Azure App Service without requiring any credentials to be configured or stored in the policy files or APIM settings.

Step-by-Step Solution

1
Enable a system-assigned managed identity on the API Management (APIM) instance.
Azure creates an identity for the APIM instance in Microsoft Entra ID.
This allows the APIM instance to act as a security principal when authenticating to downstream services.
2
Configure the backend Azure App Service to accept Microsoft Entra ID token-based authentication.
The App Service is configured to require authentication and authorize the APIM identity.
This ensures that only authorized clients (like APIM) can call the backend API.
3
Use the authentication-managed-identity policy in APIM's inbound policy section.
APIM automatically requests a token from Entra ID using its identity and forwards it to the backend.
This dynamically authenticates requests sent to the backend without hardcoding any secrets.

Key Concept

Configuring a system-assigned managed identity on Azure API Management to securely connect to backend services without managing credentials.
Question 579Question

An organization plans to host a background task container in Azure Container Apps. The container image is stored in a private Azure Container Registry named `myregistry.azurecr.io`. A developer creates a user-assigned managed identity named `my-pull-identity` to allow secure access to the registry. The Bicep template includes the user-assigned managed identity in the top-level `identity` block of the Container App resource.

To ensure the container app can successfully authenticate and pull the image from the private registry during deployment, which code block must be included inside the `properties` section of the Container App resource definition?

Show answer & explanation

Answer: configuration: {
registries: [
{
server: 'myregistry.azurecr.io'
identity: myPullIdentity.id
}
]
}

Answer

The configuration block with registries specifying the server as 'myregistry.azurecr.io' and the identity as the user-assigned managed identity's resource ID (myPullIdentity.id) inside the properties.configuration section.
The correct configuration block uses the `properties.configuration.registries` array to define the registry server and references the resource ID of the user-assigned managed identity using `myPullIdentity.id`. This complies with Azure Resource Manager specifications for pulling container images from a private Azure Container Registry using a user-assigned managed identity.

Step-by-Step Solution

1
Identify the authentication mechanism required for the private registry pull.
The requirement specifies using a user-assigned managed identity.
This determines how the credentials or identity will be passed to the Container App configuration.
2
Determine the correct property path and values inside the Bicep template properties block.
Under properties.configuration.registries, the registry configuration requires the registry server and the identity property.
This ensures the deployment engine knows which identity to use for which registry server.
3
Verify the correct value type for the identity property.
The identity property must reference the full resource ID of the user-assigned managed identity (e.g., using the .id property in Bicep).
Passing the name of the identity is insufficient for Azure to resolve the resource globally.

Key Concept

Configuring private Azure Container Registry access for Azure Container Apps using user-assigned managed identities in a Bicep template.
Question 580Question

An organization hosts a web application where static assets are updated periodically. To force client browsers and CDN edge servers to retrieve the latest version of an asset, the application appends a version parameter as a query string to the asset URL, such as `/assets/logo.png?v=2`. You deploy an Azure CDN Standard from Akamai endpoint to distribute these assets. You need to ensure that when a new version of an asset is released with an updated query string parameter, the CDN retrieves the updated asset from the origin server. For subsequent requests with the same version query string, the CDN must serve the cached asset from the edge cache to minimize origin load. Which query string caching behavior should you configure on the Azure CDN endpoint?

Show answer & explanation

Answer: Cache every unique URL

Answer

Configure the query string caching behavior to 'Cache every unique URL'.
Configuring the CDN query string caching behavior to 'Cache every unique URL' ensures that each unique query string is treated as a separate asset. When a new version parameter is appended, the CDN recognizes it as a new asset, fetches the latest version from the origin, and caches it. Subsequent requests with the same version query string are then served directly from the CDN edge cache.

Step-by-Step Solution

1
Analyze the caching requirement for versioned query strings.
The CDN must fetch a new version of the asset when the query string parameter changes, but cache and serve it from the edge for identical subsequent requests.
This establishes that query strings must not be ignored (to avoid stale content) and must not bypass caching entirely (to minimize origin load).
2
Evaluate the Azure CDN query string caching settings.
'Cache every unique URL' treats each unique URL and query string combination as a unique asset with its own cache. 'Ignore query strings' serves the same cached asset regardless of the query string. 'Bypass caching' does not cache query string requests.
Mapping the requirements to standard Azure CDN features helps identify the correct configuration.
3
Select the behavior that meets all criteria.
'Cache every unique URL' is selected.
It ensures new versions (new query strings) trigger a pull from origin, while subsequent requests for the same version are cached and served from the CDN edge.

Key Concept

Azure CDN Query String Caching Behavior
PreviousPage 29 / 49Next
All practice questions — Microsoft Azure Developer (AZ-204) | Examkin