All practice questions

972 questions

Question 401Question

You are configuring policies in Azure API Management (APIM) to expose an internal backend REST service hosted on Azure App Service. The backend service requires Microsoft Entra ID authentication and expects a token with the audience https://api.contoso.com.

The API gateway must satisfy the following requirements:
1. Authenticate to the backend App Service using the APIM instance's system-assigned managed identity.
2. Limit the incoming request rate to no more than 100 calls per 60 seconds per individual client IP address to prevent denial-of-service attempts.

Which of the following policy configurations correctly meets these requirements?

Show answer & explanation

Answer: <policies>
<inbound>
<base />
<rate-limit-by-key calls="100" renewal-period="60" counter-key="@(context.Request.IpAddress)" />
<authentication-managed-identity resource="https://api.contoso.com" />
</inbound>
<backend>
<base />
</backend>
<outbound>
<base />
</outbound>
<on-error>
<base />
</on-error>
</policies>

Answer

The correct configuration applies both the rate-limit-by-key policy (using the client's IP address) and the authentication-managed-identity policy (omitting client-id to default to system-assigned identity) within the inbound section of the API policy definition.
The correct configuration applies both the rate-limit-by-key policy and the authentication-managed-identity policy in the inbound section. The rate-limit-by-key policy restricts calls per client IP using context.Request.IpAddress, and omitting client-id in authentication-managed-identity ensures the system-assigned managed identity is used.

Step-by-Step Solution

1
Identify the correct policy tag and key configuration for limiting calls by client IP address.
Use <rate-limit-by-key> with counter-key="@(context.Request.IpAddress)". The standard <rate-limit> policy only restricts calls per subscription, which does not meet the per-IP requirement.
To limit calls by individual client IP, APIM requires the by-key policy with the Request.IpAddress variable as the counter key.
2
Determine the proper configuration for the system-assigned managed identity authentication.
Use <authentication-managed-identity> with the resource attribute set to the audience, and omit any client-id or identity-id attributes.
Omitting the client-id attribute instructs Azure API Management to use its system-assigned managed identity rather than attempting to resolve a user-assigned one.
3
Identify the correct policy sections for both policies.
Place both policies in the <inbound> section of the API management policy.
Both rate-limiting and backend authentication must occur before the gateway forwards the request to the backend service, which requires inbound execution.

Key Concept

API Management policies must be placed in the appropriate evaluation section (inbound vs outbound), and the correct attributes must be supplied to distinguish between system-assigned managed identity and user-assigned managed identity, as well as subscription-based and IP-based rate limiting.
Question 402Question

An organization is designing several applications that will use Azure Cosmos DB API for NoSQL. You must select the appropriate default consistency level for each application based on its specific requirements.

Match each application requirement on the left to its optimal Azure Cosmos DB consistency level on the right.

Click a left item, then click its matching right item

Items

A collaborative document editor where a user must always see their own modifications immediately, while other users may observe the changes after a replication lag.
A financial transaction ledger where reads must always return the absolute latest committed version of a record across all globally distributed regions.
A sports live score tracker where updates must be read in the order they occurred (e.g., scoring a goal must not appear before starting the match), but a slight delay in receiving updates is acceptable.
A weather monitoring system where reads from global read regions can lag behind the single write region, but by no more than 100 updates or 5 minutes.

Matches

Show answer & explanation

Answer

Match the collaborative document editor to Session consistency, the financial transaction ledger to Strong consistency, the sports live score tracker to Consistent Prefix consistency, and the weather monitoring system to Bounded Staleness consistency.
Matching the requirements to their respective consistency levels aligns with their architectural guarantees: Strong consistency guarantees real-time global updates; Session consistency guarantees read-your-own-writes within the client connection context; Consistent Prefix consistency ensures that updates are never observed out of order; and Bounded Staleness consistency restricts staleness to a defined time or version threshold.

Step-by-Step Solution

1
Analyze the financial transaction ledger requirement for absolute latest committed version globally.
Identify that only Strong consistency guarantees that reads always return the most recent committed version of an item across all regions.
Strong consistency offers linearizability, ensuring reads are guaranteed to return the latest committed write.
2
Analyze the collaborative document editor requirement for a user reading their own modifications immediately.
Identify that Session consistency is the optimal choice as it guarantees read-your-own-writes (RYOW) within a client session.
Session consistency provides monotonic reads and writes, scoping consistency guarantees to the client session.
3
Analyze the sports live score tracker requirement for ordered reads with acceptable lag.
Identify that Consistent Prefix consistency guarantees that reads never see out-of-order writes.
Consistent Prefix ensures that readers see updates in the exact order they were written, even if there is propagation delay.
4
Analyze the weather monitoring system requirement for lag limits of 100 updates or 5 minutes.
Identify that Bounded Staleness consistency is designed specifically to restrict staleness to a defined window of operations or time.
Bounded Staleness allows defining staleness bounds in terms of version lag (K) or time interval (T).

Key Concept

Selecting and configuring the correct Azure Cosmos DB consistency level based on application latency, throughput, and consistency requirements.
Question 403Question

You are developing a C# backend service for a smart home energy monitoring application that stores device configurations in Azure Cosmos DB using the NoSQL API. You need to implement Optimistic Concurrency Control (OCC) using the Azure Cosmos DB .NET SDK v3 to ensure that updates to a device configuration are not overwritten by concurrent processes.

Which sequence of actions should you perform to complete the update?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

Initialize the CosmosClient and obtain a Container reference, retrieve the item using ReadItemAsync along with its partition key, retrieve the ETag from the response headers, create an ItemRequestOptions instance with the IfMatchEtag property set to the retrieved ETag, and call ReplaceItemAsync with the updated document, its ID, PartitionKey, and the request options.
To implement Optimistic Concurrency Control (OCC) in Azure Cosmos DB using the C# .NET SDK v3, you must follow a read-before-write pattern. First, retrieve a reference to the container via `CosmosClient` and `Database`. Next, fetch the target document using `ReadItemAsync<T>` specifying the item ID and its `PartitionKey`. You then extract the `ETag` metadata property from the response headers. Next, create a new `ItemRequestOptions` instance and assign the extracted `ETag` string to its `IfMatchEtag` property. Finally, invoke `ReplaceItemAsync<T>` passing the updated object, its ID, its `PartitionKey`, and the custom `ItemRequestOptions`. If another process has modified the document in the meantime, the ETag on the server will not match, and the SDK will throw a `CosmosException` with a `412 Precondition Failed` status code, preventing the overwrite.

Step-by-Step Solution

1
Acquire container reference
A Container instance is obtained using CosmosClient.
An active SDK client and container reference are prerequisites for executing any database operations.
2
Read the item
The existing document is read into memory along with its ETag.
You must obtain the current state of the document and its unique ETag value to perform conditional validation.
3
Read ETag from response headers
The ETag string is extracted.
The Cosmos DB SQL API returns metadata, including ETag, in response headers (ItemResponse.Headers.ETag).
4
Configure Request Options
An ItemRequestOptions object with IfMatchEtag configured.
Setting IfMatchEtag ensures the server validates that the item has not been updated since it was read.
5
Call ReplaceItemAsync
The item is updated in Cosmos DB, or a 412 Precondition Failed status code is thrown if the ETag has changed.
The replacement writes the modifications back to the container under the OCC constraint.

Key Concept

Implementing Optimistic Concurrency Control (OCC) using the Cosmos DB .NET SDK v3 with ETag validation.
Estimated Time:2m 30s
Question 404Question

An enterprise inventory application uses Azure Service Bus to coordinate message routing. A developer is implementing a transaction-based message processing flow in C# using the Azure.Messaging.ServiceBus SDK. The application must receive a message from an input queue named orders-input, send a related message to an output queue named orders-output (within the same namespace), and then complete the original message. The entire sequence must occur inside a single atomic transaction.

The developer writes the following implementation:

csharp
using System.Transactions;
using Azure.Messaging.ServiceBus;

// ... client initialization ...

var options = new ServiceBusReceiverOptions
{
ReceiveMode = // [Configuration here]
};
ServiceBusReceiver receiver = client.CreateReceiver("orders-input", options);
ServiceBusSender sender = client.CreateSender("orders-output");

using (var ts = new TransactionScope(TransactionScopeAsyncFlowOption.Enabled))
{
ServiceBusReceivedMessage message = await receiver.ReceiveMessageAsync();
// processing logic...

var response = new ServiceBusMessage("Order Processed");
await sender.SendMessageAsync(response);
await receiver.CompleteMessageAsync(message);

ts.Complete();
}

Which of the following configurations is required to ensure that if the send or complete operation fails, the transaction rolls back and the original message remains in the input queue?

Show answer & explanation

Answer: Configure the `ReceiveMode` to `ServiceBusReceiveMode.PeekLock`.

Answer

The correct configuration is to configure the `ReceiveMode` to `ServiceBusReceiveMode.PeekLock`.
Configuring the receive mode to `PeekLock` ensures that the Service Bus message is not deleted from the queue immediately upon receipt. Instead, the message is locked for a duration, allowing the application to process the payload and send the output message. When enclosed within a `TransactionScope`, the message settlement (complete) is committed atomically with the send operation. If any operation within the scope fails and the transaction rolls back, the lock is released, and the original message remains safely in the input queue.

Step-by-Step Solution

1
Understand the transactional requirement.
The operation must atomically receive a message, send a message, and complete the original message.
Ensures that if any part of the process fails, the original message is not lost.
2
Analyze the Service Bus receive modes.
Identify that `PeekLock` keeps the message on the queue with a lock, while `ReceiveAndDelete` deletes it immediately.
Only `PeekLock` supports explicit settlement (like completion) that can be committed or rolled back within a transaction.
3
Verify security and credential requirements.
Ensure that the client has Send/Listen permissions and Key Vault access is authorized.
Any misconfiguration in permissions or key retrieval would prevent client initialization and block processing.

Key Concept

The core concept being tested is implementing transactional message processing in Azure Service Bus by selecting the correct receive mode (`PeekLock`) to enable atomic send and complete operations.
Question 405Question

You are developing a command-line interface (CLI) application that will run on Linux servers without a graphical user interface or local web browser. The application must authenticate individual users against Microsoft Entra ID before executing commands. Which MSAL.NET method should you use to perform the authentication?

Show answer & explanation

Answer: AcquireTokenWithDeviceCode

Answer

The correct option is AcquireTokenWithDeviceCode, which initiates the Device Code Flow for environments without a local web browser.
The method AcquireTokenWithDeviceCode executes the OAuth 2.0 Device Authorization Grant. This flow provides the user with an verification URL and a code to perform authentication on a separate, browser-equipped device, making it ideal for headless command-line interfaces.

Step-by-Step Solution

1
Analyze the execution environment constraints.
The CLI application runs on a headless Linux server with no GUI or local web browser.
This rules out standard interactive flows that rely on launching a local system browser.
2
Identify the authentication subject.
The application must authenticate individual users (delegated permissions), not the application itself.
This rules out client credential flows meant for daemon/service identity.
3
Select the appropriate OAuth 2.0 flow for headless user authentication.
The Device Code Flow is designed for this scenario, allowing the user to sign in on a separate device using a code and a browser.
The MSAL.NET library implements this flow using the AcquireTokenWithDeviceCode method.

Key Concept

Microsoft Identity Platform Device Code Flow
Question 406Question

You are developing a V4 Azure Function App. A function within the app is triggered by messages from an Azure Queue Storage queue named incoming-orders. The function is configured with a connection property value of OrderStorageConnection.

You want to configure the Function App to use its system-assigned managed identity to connect to the queue in a storage account named orderstore instead of using a connection string.

Which application setting should you add to the Function App?

Show answer & explanation

Answer: OrderStorageConnection__queueServiceUri with the value https://orderstore.queue.core.windows.net

Answer

OrderStorageConnection__queueServiceUri with the value https://orderstore.queue.core.windows.net
The correct option is the one specifying OrderStorageConnection__queueServiceUri with the service endpoint. For Azure Queue Storage triggers and bindings, identity-based connections require the application setting key to consist of the connection name prefix followed by the service-specific suffix '__queueServiceUri'. Since the system-assigned managed identity is used by default when no credential property is set, providing the endpoint URL is sufficient to establish the connection.

Step-by-Step Solution

1
Identify the logical connection name used in the trigger configuration.
The logical connection name is OrderStorageConnection.
The connection property of the trigger attribute points to this application setting prefix.
2
Determine the required suffix for an identity-based Azure Queue Storage trigger connection.
The required suffix is __queueServiceUri.
Azure Functions uses service-specific suffixes to identify the type of service endpoint for identity connections.
3
Combine the connection name, suffix, and endpoint to form the configuration key-value pair.
The configuration key is OrderStorageConnection__queueServiceUri and the value is the queue service endpoint: https://orderstore.queue.core.windows.net.
This structure directs the Azure Functions runtime to use the managed identity to connect to the specific Queue Storage endpoint.

Key Concept

Configuring Identity-Based Connections for Azure Functions Triggers and Bindings
Question 407Question

An organization is setting up a secure containerized API in Azure Container Apps. The container image is stored in a private Azure Container Registry (ACR). When deploying the Container App for the first time using a Bicep template, the deployment fails during the container creation phase because the registry authentication is not established. You need to configure the Bicep template to successfully authenticate to the private registry during this initial deployment using a managed identity. Which configuration strategy should you implement to ensure the initial deployment succeeds?

Show answer & explanation

Answer: Configure a user-assigned managed identity, grant it the AcrPull role on the registry, and reference this identity in both the identity and registries configuration blocks of the Bicep template.

Answer

Configure a user-assigned managed identity, grant it the AcrPull role on the registry, and reference this identity in both the identity and registries configuration blocks of the Bicep template.
The correct configuration strategy involves using a user-assigned managed identity. Since the user-assigned identity is a standalone Azure resource, it can be created and granted the AcrPull role on the private Azure Container Registry (ACR) before the Container App is deployed. When the Bicep template runs, referencing this identity in both the identity block and the registries configuration allows the Container Apps platform to authenticate and pull the image successfully on the initial deployment.

Step-by-Step Solution

1
Create a user-assigned managed identity resource in Azure.
The identity is provisioned with a principal ID and client ID.
This identity must exist independently of the Container App so that it can be assigned permissions prior to the app's deployment.
2
Assign the AcrPull role to the user-assigned managed identity on the Azure Container Registry.
The identity receives read access to the private registry.
This allows the identity to pull container images from the registry.
3
Reference the user-assigned managed identity in the identity block and specify it under the registries array in the Container App Bicep configuration.
The Container App is configured to use the user-assigned identity to authenticate against the private ACR.
This ensures the Azure Container Apps service can authenticate as this identity to pull the image during the initial deployment.

Key Concept

Deploying Azure Container Apps with private registry authentication using a user-assigned managed identity.
Question 408Question

You manage a .NET web application that is hosted on Azure App Service. The application is configured to send telemetry to an Application Insights instance.

You regularly receive email notifications from Application Insights regarding 'Dependency Latency Degradation' anomalies. You verify that these latency spikes are expected because they occur during a third-party database's scheduled daily maintenance window. You want to stop receiving these specific proactive email notifications without stopping the collection of dependency response time telemetry or affecting other anomaly detection rules.

Which action should you perform to meet this requirement?

Show answer & explanation

Answer: Navigate to the Application Insights resource in the Azure portal, select Smart Detection under the Investigate section, select the Dependency Latency Degradation rule, and click Disable.

Answer

Navigate to the Application Insights resource in the Azure portal, select Smart Detection under the Investigate section, select the Dependency Latency Degradation rule, and click Disable.
The correct action is to disable the Dependency Latency Degradation rule in the Smart Detection blade of the Application Insights resource in the Azure portal. Smart Detection rules run proactively on telemetry collected by Application Insights and can be disabled or configured individually to avoid unnecessary alerts during known maintenance windows without stopping raw telemetry ingestion.

Step-by-Step Solution

1
Locate the monitoring resource in the Azure portal.
You access the Application Insights resource linked to your web application.
Smart Detection rules are configured and managed at the Application Insights resource level, not within the hosting App Service.
2
Navigate to the Smart Detection settings.
You view the list of proactive detection rules, including Dependency Latency Degradation.
Smart Detection is located under the Investigate section of the Application Insights menu.
3
Disable the target rule.
The Dependency Latency Degradation rule is disabled.
This stops Application Insights from running the anomaly detection algorithm and sending emails for this specific metric while leaving other rules and telemetry collection intact.

Key Concept

Application Insights Smart Detection proactively monitors telemetry for performance anomalies and can be configured or disabled per-rule in the Azure Portal.
Question 409Question

You manage an inventory synchronization service named InventoryProcessor that runs on an Azure App Service Web App. The web app currently uses a Basic (B1) App Service plan.

The application experiences intermittent CPU spikes during inventory updates. You must configure the application to automatically scale out when CPU utilization exceeds 80%80\%, and scale in when CPU utilization drops. You must also ensure that the autoscale configuration does not cause rapid, repeated scale-out and scale-in actions (flapping).

Which two actions should you perform to meet these requirements?

Select all that apply

Show answer & explanation

Answer: Scale up the App Service plan to the Standard (S1) tier.; Configure a scale-out rule with a CPU threshold of 80%80\% and a scale-in rule with a CPU threshold of 30%30\%.

Answer

Scale up the App Service plan to the Standard (S1) tier, and configure a scale-out rule with a CPU threshold of 80%80\% and a scale-in rule with a CPU threshold of 30%30\%.
Scaling up the App Service plan to the Standard (S1) tier is necessary because autoscale rules are not supported on the Basic tier. Additionally, configuring the scale-out rule at 80%80\% and the scale-in rule at 30%30\% ensures that the thresholds are separated by a margin wide enough to prevent autoscale flapping.

Step-by-Step Solution

1
Determine the minimum App Service tier required for autoscale rules.
The Basic (B1) tier does not support autoscale rules. Scaling up to the Standard (S1) tier or higher is required to configure scale-out and scale-in rules.
Autoscale features in App Service are only available in Standard, Premium, and Isolated pricing tiers.
2
Define autoscale rules to handle load and prevent flapping.
Create a scale-out rule at 80%80\% CPU and a scale-in rule at a significantly lower value, such as 30%30\%.
Keeping a wide margin between the scale-out and scale-in thresholds prevents the system from entering an loop of constant scaling actions (flapping) when capacity changes.

Key Concept

App Service plan pricing tiers and autoscale flapping prevention
Question 410Question

You are developing a microservice using the Azure Cosmos DB .NET SDK v3. You need to configure a Change Feed Processor to process document updates from a monitored container and coordinate state using a lease container. Which sequence of steps must you perform to initialize and run the Change Feed Processor?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

Retrieve container references, call GetChangeFeedProcessorBuilder on the monitored container, chain builder configuration methods (WithInstanceName and WithLeaseContainer), call Build, and then call StartAsync on the processor.
To successfully configure and run the Change Feed Processor, you must follow the correct lifecycle sequence: first obtain the container references, then initialize the builder on the monitored container, chain configuration methods such as the lease container and instance name, build the processor, and finally start it asynchronously.

Step-by-Step Solution

1
Obtain Container references from the Cosmos client.
Two Container instances representing the monitored source container and the lease storage container.
The processor builder requires references to both the data source and the lease coordinator containers to establish communication.
2
Invoke GetChangeFeedProcessorBuilder on the monitored container.
A ChangeFeedProcessorBuilder instance is initialized.
This starts the fluent configuration chain on the monitored container where the data changes originate.
3
Configure the builder with WithInstanceName and WithLeaseContainer.
The builder is configured with the specific worker host ID and lease container tracking.
The lease container is required for tracking checkpoints, and the instance name uniquely identifies this host for scale-out distribution.
4
Call Build on the builder.
A ChangeFeedProcessor instance is created.
This instantiates the engine that coordinates partition ownership and reads feed batches.
5
Call StartAsync on the processor instance.
The background change processing loop begins executing.
The processor requires an explicit start signal to allocate partition leases and begin streaming updates to the delegate.

Key Concept

Azure Cosmos DB .NET SDK v3 Change Feed Processor lifecycle and builder sequence
Question 411Question

An organization is deploying a set of APIs as .NET-based Azure Functions. They want to implement both Application Insights Profiler to identify performance bottlenecks and Snapshot Debugger to analyze unhandled exceptions in production. Which of the following requirements must be met to ensure that both services are supported and that developers can inspect the diagnostic data? (Select TWO).

Select all that apply

Show answer & explanation

Answer: Host the Function App on an Azure Functions Premium or Dedicated (App Service) plan.; Assign the Application Insights Snapshot Debugger role to developers who need to view the captured snapshots in the Azure portal.

Answer

To successfully configure and view data for both Application Insights Profiler and Snapshot Debugger, you must host the Function App on a Premium or Dedicated plan and assign the Application Insights Snapshot Debugger role to developers who need to view the captured snapshots.
The correct requirements are hosting the Function App on a Premium or Dedicated (App Service) plan and assigning the Application Insights Snapshot Debugger role to developers. Profiler requires dedicated compute resources to capture trace profiles periodically, making it unsupported on the serverless Consumption plan. Additionally, because debug snapshots capture in-memory variable values that may contain sensitive data, users must be explicitly granted the Application Insights Snapshot Debugger role to view them.

Step-by-Step Solution

1
Evaluate the hosting plan requirements for Application Insights Profiler.
Identify that the Profiler background agent requires the compute resources of a Premium or Dedicated (App Service) plan and is unsupported on the standard Consumption plan.
This determines the minimum hosting plan needed to support the Profiler.
2
Evaluate the access control requirements for viewing Snapshot Debugger data.
Identify that standard Reader or Contributor roles are insufficient to access sensitive call stack and variable state data; the specialized Application Insights Snapshot Debugger role must be assigned.
This ensures developers have the necessary permissions to inspect the debug snapshots in the Azure portal.

Key Concept

Application Insights Profiler requires Premium/Dedicated hosting plans, while Snapshot Debugger requires the specialized Snapshot Debugger RBAC role to view collected snapshots.
Question 412Question

An organization is designing a V4 Azure Function App to process large datasets. The functions have the following requirements:

* Individual function executions can take up to 2525 minutes to complete.
* The functions must connect securely to an Azure SQL Database using a private endpoint within an Azure Virtual Network (VNet).
* The hosting configuration must support scale-out to handle high-demand periods.

Which hosting plans can you use to meet these requirements? (Select all that apply.)

Select all that apply

Show answer & explanation

Answer: Premium plan; Dedicated (App Service) plan (Standard tier or higher)

Answer

The Premium plan and the Dedicated (App Service) plan (Standard tier or higher) meet all requirements.
The Premium plan and the Dedicated (App Service) plan (Standard tier or higher) are correct. The Premium plan offers VNet integration, dynamic scaling, and supports an execution duration up to 6060 minutes (or unbounded). The Dedicated plan (Standard tier or higher) also supports VNet integration, has no execution duration limits, and supports autoscale rules.

Step-by-Step Solution

1
Evaluate the execution duration requirement against Azure Functions hosting plans.
The execution duration is 2525 minutes, which exceeds the 1010-minute maximum limit of the Consumption plan but is supported by the Premium and Dedicated plans.
Hosting plans must support long-running processes without timing out.
2
Evaluate the network connectivity requirement.
The Premium plan and the Dedicated plan (Standard tier or higher) support regional VNet integration, whereas the Consumption plan and Free/Shared Dedicated tiers do not.
VNet integration is required to access the private endpoint of the Azure SQL Database.
3
Evaluate scaling capabilities for high-demand periods.
Both the Premium plan (event-based scaling) and the Dedicated plan (via autoscale rules) support scaling out.
The system must handle high-demand scale-out scenarios.

Key Concept

Azure Functions hosting plans and features
Question 413Question

A developer is deploying a Java-based API using Azure Functions. The API occasionally experiences intermittent latency spikes during high-load periods. The developer wants to capture detailed CPU and memory allocation profiles using Application Insights Profiler to identify the hot code paths. Currently, the Function App is hosted on a Consumption plan. Which of the following actions must the developer perform first to enable the Profiler?

Show answer & explanation

Answer: Upgrade the Function App hosting plan to a Premium plan or a Dedicated App Service plan.

Answer

Upgrade the Function App hosting plan to a Premium plan or a Dedicated App Service plan.
The correct answer states that the hosting plan must be upgraded to a Premium plan or a Dedicated App Service plan. This is because Application Insights Profiler needs to run on a dedicated worker with continuous compute resources, which is not supported on the default serverless Consumption plan for Azure Functions.

Step-by-Step Solution

1
Analyze the current hosting plan for the Azure Functions application.
The Function App is currently hosted on a serverless Consumption plan.
Application Insights Profiler requires continuous worker resources to perform trace collection, which is unsupported on the serverless Consumption plan.
2
Determine the supported hosting plans for Application Insights Profiler in Azure Functions.
Identify that the Elastic Premium plan or a Dedicated App Service plan is required to enable the Profiler.
These plans provide dedicated compute instances where the Profiler agent can continuously run and record performance traces.
3
Upgrade the hosting plan of the Function App to a Premium or Dedicated plan.
The compute tier is scaled up, enabling the runtime environment to support the background Profiler agent.
Upgrading the plan provides the necessary continuous background processing capability to run the Profiler.

Key Concept

Application Insights Profiler requires a compatible compute hosting plan that supports continuous background execution (such as Premium or Dedicated plans for Azure Functions).
Question 414Question

You need to secure the connection between an Azure API Management (APIM) instance and a backend API hosted on Azure App Service. The backend API requires Azure Active Directory (Azure AD) authentication. You want to use a user-assigned managed identity named apim-backend-identity to authenticate the APIM instance against the backend API. Which of the following configuration steps should you perform? Select two.

Select all that apply

Show answer & explanation

Answer: Associate the user-assigned managed identity named apim-backend-identity with the API Management instance.; In the inbound section of the API Management policy, add the authentication-managed-identity policy, specifying the backend API's resource identifier and the client ID of apim-backend-identity.

Answer

Associate the user-assigned managed identity named apim-backend-identity with the API Management instance, and add the authentication-managed-identity policy in the inbound section of the API Management policy, specifying the backend API's resource identifier and the client ID of apim-backend-identity.
To secure backend connections using a user-assigned managed identity, you must first associate the identity with the API Management instance. Next, you must configure the inbound policy section using the authentication-managed-identity policy. Since user-assigned managed identities are not the default, you must explicitly specify the client ID of the user-assigned identity within the policy configuration so that the correct token is obtained and attached to the request.

Step-by-Step Solution

1
Associate the user-assigned managed identity with the API Management resource.
The identity is linked to the APIM instance, allowing the gateway to request tokens on its behalf.
An identity must be associated with the Azure resource before it can be referenced in any configuration or policy.
2
Add the authentication-managed-identity policy to the inbound policy pipeline.
The gateway is configured to request an Azure AD token for the backend API and add it to the outgoing Authorization header.
Authentication policies must run during the inbound phase to modify the request before it is forwarded to the backend service.
3
Set the client-id attribute of the authentication-managed-identity policy to the client ID of the user-assigned managed identity.
The gateway uses the specified user-assigned managed identity rather than the system-assigned managed identity.
If the client-id attribute is omitted, the gateway defaults to using the system-assigned managed identity, which would cause authentication to fail.

Key Concept

Securing backend services using Managed Identity in Azure API Management
Question 415Question

You are developing a C# background service that processes flight ticket booking transactions from an Azure Service Bus queue. Each booking transaction involves multiple external API calls to airlines and payment gateways, which takes up to 90 seconds to complete under peak load. If the service crashes or loses connectivity while processing a booking, the transaction message must not be lost and must be made available for reprocessing by another service instance. You need to configure the `ServiceBusProcessor` using the C# Azure SDK (`Azure.Messaging.ServiceBus`). Which configuration settings must you apply to meet these requirements?

Show answer & explanation

Answer: Configure ServiceBusProcessorOptions with ReceiveMode set to ServiceBusReceiveMode.PeekLock and MaxAutoLockRenewalDuration set to 2 minutes.

Answer

Configure ServiceBusProcessorOptions with ReceiveMode set to ServiceBusReceiveMode.PeekLock and MaxAutoLockRenewalDuration set to 2 minutes.
The correct configuration uses PeekLock mode to guarantee that the message is not lost if processing fails, and sets MaxAutoLockRenewalDuration to 2 minutes to ensure the processor maintains the lock for the duration of the 90-second operation.

Step-by-Step Solution

1
Select the correct ReceiveMode to prevent message loss on failure.
ServiceBusReceiveMode.PeekLock must be selected so that the message remains in the queue and is only marked for deletion upon successful settlement.
ReceiveAndDelete deletes the message immediately upon receipt, which risks losing the message if the application crashes during execution.
2
Ensure the message lock duration covers the maximum processing time of 90 seconds.
Configure MaxAutoLockRenewalDuration to a duration (e.g., 2 minutes) greater than the maximum expected processing time.
By default, the queue lock duration is shorter (often 30 seconds). If the lock expires while the process is still running, another worker instance might retrieve and try to process the same message, leading to duplicate processing.
3
Ensure appropriate completion settlement behavior.
Leave AutoCompleteMessages to its default value of true (or manually complete the message using CompleteMessageAsync if set to false).
Failing to complete the message means it will never be settled successfully, leading to reprocessing loops and eventual dead-lettering.

Key Concept

Message locking and settlement modes in Azure Service Bus SDK
Question 416Question

A developer is writing a .NET background worker using the `Azure.Storage.Blobs` SDK (version 12) to process medical images. During the image upload process, a custom metadata key named `PatientID` was successfully set on each blob. The developer writes the following C# code to retrieve this metadata value:

csharp
BlobClient blobClient = blobContainerClient.GetBlobClient("image1.jpg");
BlobProperties properties = await blobClient.GetPropertiesAsync();
string patientId = properties.Metadata["PatientID"];

At runtime, this code throws a `KeyNotFoundException` when attempting to read the dictionary value, even though the metadata exists on the blob.

Which of the following describes the root cause of this exception and the correct resolution?

Show answer & explanation

Answer: The Azure Blob Storage service returns all user-defined metadata keys in lowercase via HTTP headers, which causes the SDK to populate the dictionary with lowercase keys; the developer should access the key using `properties.Metadata["patientid"]`.

Answer

The Azure Blob Storage service returns all user-defined metadata keys in lowercase via HTTP headers, which causes the SDK to populate the dictionary with lowercase keys; the developer should access the key using properties.Metadata["patientid"].
The correct option is correct because the Azure Blob Storage REST API returns custom metadata keys as lowercase HTTP headers. The .NET SDK parses these headers, removes the prefix, and exposes them in the Metadata dictionary exactly as received (lowercase). Consequently, a case-sensitive dictionary lookup using mixed-case keys throws a KeyNotFoundException. The developer must use lowercase keys for retrieval.

Step-by-Step Solution

1
Analyze how custom metadata is transferred from Azure Storage to the client application.
Metadata is sent via HTTP response headers prefixed with 'x-ms-meta-', such as 'x-ms-meta-patientid'.
HTTP headers are case-insensitive, and Azure Blob Storage normalizes header names to lowercase during transmission.
2
Determine how the .NET SDK (Azure.Storage.Blobs) processes these HTTP headers.
The SDK strips the 'x-ms-meta-' prefix and populates the Metadata dictionary using the lowercase keys directly from the header names.
This behavior maps the HTTP header keys to dictionary keys, preserving the casing returned by the service.
3
Identify the correct key to retrieve the metadata value from the dictionary.
The correct key is 'patientid' in all lowercase, rather than the original mixed-case 'PatientID'.
Using 'PatientID' causes a KeyNotFoundException because C# dictionary lookups are case-sensitive by default.

Key Concept

Azure Blob Storage custom metadata keys are returned in lowercase by the REST API, resulting in lowercase keys in the .NET SDK Metadata dictionary.
Question 417Question

You are configuring security for an API hosted on an Azure API Management (APIM) gateway. The business requirement states that all incoming client requests must be authenticated using client certificates (mutual TLS). The allowed certificate thumbprints must be stored securely in an Azure Key Vault rather than hardcoded in the policy. The APIM instance has a system-assigned managed identity enabled.

Which two of the following configuration steps must you perform to meet these requirements?

Select all that apply

Show answer & explanation

Answer: Create a Named Value in the API Management instance that references the Azure Key Vault secret containing the allowed certificate thumbprint.; In the inbound section of the API policy, add a conditional policy that validates the incoming client certificate's thumbprint against the Named Value.

Answer

Create a Named Value in the API Management instance that references the Azure Key Vault secret containing the allowed certificate thumbprint, and in the inbound section of the API policy, add a conditional policy that validates the incoming client certificate's thumbprint against the Named Value.
To secure the API Management gateway with client certificates, the APIM instance must validate the certificate incoming in the request. Storing the certificate thumbprints in Azure Key Vault ensures security and maintainability. A Named Value in API Management can be configured to fetch the secret using the system-assigned managed identity. The inbound policy section must then contain a conditional check (such as using the choose policy) to inspect the client certificate thumbprint from the context and ensure it matches the thumbprint retrieved from Key Vault. This blocks unauthorized requests before reaching the backend.

Step-by-Step Solution

1
Enable Managed Identity on the APIM instance and grant it access to the Key Vault.
The APIM instance's system-assigned managed identity is configured with Secret Get permission in the Key Vault access policies.
This allows the APIM instance to authenticate and retrieve secret values from the Key Vault dynamically.
2
Create a Named Value referencing the Key Vault secret.
A Named Value is defined in APIM, linked to the Key Vault secret containing the certificate thumbprint.
This keeps the sensitive thumbprint out of the policy code and centralizes configuration in Key Vault.
3
Add an inbound policy to inspect the client certificate.
An inbound policy check evaluates context.Request.Certificate.Thumbprint and compares it with the Named Value.
Validating the certificate inbound ensures that unauthorized requests are rejected before reaching the backend services.

Key Concept

Securing APIM endpoints with client certificate validation and Key Vault integration
Question 418Question

Your company is developing a custom availability monitoring solution for an internal microservice that is not accessible from the public internet. You create an Azure Function App with a Timer trigger configured to run every 5 minutes. The function must execute a health check against the microservice and send the availability results to Application Insights so that they appear in the Availability dashboard.

You need to implement the monitoring solution.

Which two actions should you perform? Select two.

Select all that apply

Show answer & explanation

Answer: Instantiate a TelemetryClient and invoke the TrackAvailability method passing an AvailabilityTelemetry instance.; Add the APPLICATIONINSIGHTS_CONNECTION_STRING setting to the Function App's configuration settings.

Answer

To implement custom availability monitoring, you should instantiate a TelemetryClient and invoke the TrackAvailability method passing an AvailabilityTelemetry instance, and configure the APPLICATIONINSIGHTS_CONNECTION_STRING setting in the Function App's configuration settings.
The correct solution involves two main steps: first, utilizing the specialized SDK method for availability telemetry, which is TrackAvailability with an AvailabilityTelemetry object, to ensure the data is parsed correctly by the Application Insights dashboard. Second, configuring the APPLICATIONINSIGHTS_CONNECTION_STRING application setting in the Function App ensures that the SDK can connect and upload telemetry to Azure Monitor.

Step-by-Step Solution

1
Select the correct SDK method for reporting availability.
Identify that the TrackAvailability method must be called to send availability telemetry that populates the Availability tab in Application Insights.
Other telemetry methods like TrackEvent or TrackMetric do not register as availability tests in the portal dashboard.
2
Configure the connectivity to the Application Insights resource.
Define the APPLICATIONINSIGHTS_CONNECTION_STRING configuration setting in the Azure Function App settings.
The Application Insights SDK relies on the connection string to authenticate and send telemetry to the correct endpoint.

Key Concept

Custom availability monitoring in Application Insights using TrackAvailability and Azure Functions requires proper initialization of the SDK using the Application Insights connection string.
Question 419Question

You are developing a secure background daemon application in C# that runs as an on-premises scheduled task. The application must periodically retrieve records from a secured downstream Azure Web API. The organization's security policy strictly prohibits the use of client secrets (passwords) for authentication. Instead, you must authenticate using a client certificate. You have already registered the daemon application in Microsoft Entra ID.

Which two of the following actions must you perform to configure the application registration and implement the authentication flow using MSAL.NET? (Select two.)

Select all that apply

Show answer & explanation

Answer: In the C# application code, retrieve the certificate and instantiate the client using ConfidentialClientApplicationBuilder.Create(clientId).WithCertificate(certificate).WithAuthority(AzureCloudInstance.AzurePublic, tenantId).Build().; In the Microsoft Entra admin center, select the registered application, navigate to Certificates & secrets, select the Certificates tab, upload the public key file (.cer) of the certificate, and save.

Answer

The application must be configured in Microsoft Entra ID by uploading the public key (.cer) to the Certificates tab of the Certificates & secrets page, and implemented in C# by instantiating the client using ConfidentialClientApplicationBuilder.Create(clientId).WithCertificate(certificate).WithAuthority(AzureCloudInstance.AzurePublic, tenantId).Build().
For a daemon application to authenticate securely using a certificate, it must register the public key in Microsoft Entra ID under the application's Certificates & secrets section, and the application code must use the ConfidentialClientApplicationBuilder class with the WithCertificate method to sign the client assertion and acquire tokens.

Step-by-Step Solution

1
Upload the public key file (.cer) of the certificate to the daemon application registration in Microsoft Entra ID.
Microsoft Entra ID has the public key needed to verify assertions signed by the application.
This establishes trust between Microsoft Entra ID and the daemon application without relying on a password-like client secret.
2
Use ConfidentialClientApplicationBuilder in the C# code, passing the private key certificate using the WithCertificate method.
The application is configured as a confidential client and is ready to generate signed client assertions for authentication.
Daemon applications run in secure server environments and are capable of maintaining credentials, which requires the confidential client application model rather than the public client application model.

Key Concept

Daemon applications using MSAL.NET and Microsoft Identity Platform must act as confidential client applications and authenticate using client credentials (either client secrets or client certificates). In Entra ID, the public key of the certificate is registered, while the private key is used in C# code with the ConfidentialClientApplicationBuilder to acquire a token.
Question 420Question

You are designing a telemetry archival pipeline in C# using the `Azure.Storage.Blobs` SDK. The pipeline processes log files that have an active write lease. You need to transition a specific block blob named `logs_2026.csv` to the Cool access tier and update its custom metadata with a tag of `Status` set to `Archived`. The active lease must not be broken or released during these operations. Which code snippet should you use to successfully update the access tier and metadata of the leased blob?

Show answer & explanation

Answer: csharp
string leaseId = "d5b9f935-862a-436f-87be-23e5124dbf4d";
var metadata = new Dictionary<string, string> { { "Status", "Archived" } };

await blobClient.SetAccessTierAsync(AccessTier.Cool, leaseId: leaseId);
var conditions = new BlobRequestConditions { LeaseId = leaseId };
await blobClient.SetMetadataAsync(metadata, conditions);

Answer

The correct option is the C# code snippet that provides the lease ID directly to SetAccessTierAsync and via BlobRequestConditions to SetMetadataAsync, using the dictionary key 'Status'.
The correct snippet successfully updates both the access tier and metadata by passing the lease ID in the appropriate parameters required by the Azure SDK for .NET (as a direct parameter to SetAccessTierAsync and via BlobRequestConditions to SetMetadataAsync). It also specifies the metadata key 'Status' without the redundant 'x-ms-meta-' prefix.

Step-by-Step Solution

1
Analyze lease requirements for Blob Storage write operations.
Since the blob is leased, both setting the access tier and updating metadata are write actions that require the active lease ID.
Azure Blob Storage enforces write locks via leases to prevent concurrent modifications.
2
Determine how to pass the lease ID in the Azure SDK for .NET.
For SetAccessTierAsync, the lease ID is passed as a string parameter. For SetMetadataAsync, the lease ID is passed within a BlobRequestConditions object.
The SDK defines different signatures for updating access tiers versus general properties and metadata.
3
Verify metadata naming conventions in the SDK dictionary.
Keys in the metadata dictionary must not contain the 'x-ms-meta-' prefix.
The .NET SDK automatically prepends 'x-ms-meta-' to custom metadata keys during HTTP request serialization.

Key Concept

Modifying leased blob properties, metadata, and access tiers using the Azure SDK for .NET requires specifying the lease ID through distinct parameter signatures without manually adding HTTP metadata prefixes.
Estimated Time:2m 0s
PreviousPage 21 / 49Next
All practice questions — Microsoft Azure Developer (AZ-204) | Examkin