All practice questions

972 questions

Question 781Question

You are developing a .NET console application that processes payment transaction messages from an Azure Service Bus queue named `payments`. The application must retrieve messages one by one. To prevent transaction loss, messages must remain in the queue if processing fails or if the application crashes, and must be permanently removed only after successful processing. Which code snippet should you use to implement this message processing logic?

Show answer & explanation

Answer: csharp
ServiceBusReceiver receiver = client.CreateReceiver("payments", new ServiceBusReceiverOptions
{
ReceiveMode = ServiceBusReceiveMode.PeekLock
});
ServiceBusReceivedMessage message = await receiver.ReceiveMessageAsync();
if (message != null)
{
try
{
await ProcessPaymentAsync(message);
await receiver.CompleteMessageAsync(message);
}
catch (Exception)
{
await receiver.AbandonMessageAsync(message);
}
}

Answer

Initialize the ServiceBusReceiver with ServiceBusReceiveMode.PeekLock, then process the message in a try-catch block where you call CompleteMessageAsync on success and AbandonMessageAsync on failure.
The correct implementation configures the ServiceBusReceiver to use PeekLock mode. Under PeekLock, the message is locked from other receivers but remains in the queue. The application must explicitly call CompleteMessageAsync to remove the message from the queue when processing succeeds, or call AbandonMessageAsync to release the lock immediately if an exception is caught.

Step-by-Step Solution

1
Select the appropriate ServiceBusReceiveMode.
Use ServiceBusReceiveMode.PeekLock.
PeekLock ensures the message is locked during processing and remains in the queue if the process crashes, preventing message loss.
2
Determine the message settlement mechanism.
Explicitly call CompleteMessageAsync when processing succeeds.
Because ServiceBusReceiver does not support auto-completion, messages must be manually completed to delete them from the queue after successful processing.
3
Handle processing exceptions.
Catch exceptions and call AbandonMessageAsync.
Abandoning the message releases the lock immediately so another receiver instance can reprocess the message without waiting for the lock duration to expire.

Key Concept

Azure Service Bus receive modes and message settlement lifecycle.
Estimated Time:1m 30s
Question 782Question

A C# background service runs on an Azure Virtual Machine that is configured with a user-assigned managed identity. The service must decrypt sensitive application data using an asymmetric key named `app-decrypt-key` stored in an Azure Key Vault named `contoso-vault`. The Key Vault has Azure role-based access control (Azure RBAC) enabled as its authorization model. You need to grant the minimum necessary permissions to the managed identity and implement the decryption logic in the service's C# code using the Azure SDK for .NET. Which two actions should you perform? (Choose two.)

Select all that apply

Show answer & explanation

Answer: Assign the Key Vault Crypto User role to the user-assigned managed identity for the contoso-vault scope.; In the C# application code, instantiate a CryptographyClient using the key URI and call its DecryptAsync method.

Answer

Assign the Key Vault Crypto User role to the user-assigned managed identity for the contoso-vault scope, and in the C# application code, instantiate a CryptographyClient using the key URI and call its DecryptAsync method.
To decrypt data using a Key Vault key under the Azure RBAC model, you must assign a role that grants the data plane permission for cryptographic decryption (such as Key Vault Crypto User) to the identity used by the application (the user-assigned managed identity). In the Azure SDK for .NET, cryptographic operations must be executed using the CryptographyClient class rather than the KeyClient class, which is only used for management tasks.

Step-by-Step Solution

1
Assign the built-in Azure RBAC role for key cryptography.
The user-assigned managed identity is granted the Key Vault Crypto User role at the Key Vault scope.
This built-in role provides the minimum required data plane permissions (Microsoft.KeyVault/vaults/keys/decrypt/action) needed to decrypt data using keys in Azure Key Vault when Azure RBAC is used.
2
Implement the C# code using the correct client class in the Azure SDK for .NET.
The code uses CryptographyClient from the Azure.Security.KeyVault.Keys.Cryptography namespace to decrypt the cipher text.
In the modern Azure.Security.KeyVault SDK, KeyClient manages key lifecycles, whereas CryptographyClient is required to perform data plane cryptographic operations such as encrypting, decrypting, and wrapping.

Key Concept

Azure Key Vault key cryptography operations and RBAC role assignment using the Azure SDK for .NET.
Question 783Question

A team is migrating an on-premises web application to a C# .NET 8 Minimal API hosted on Azure Kubernetes Service (AKS). The containerized application includes the `Microsoft.ApplicationInsights.AspNetCore` package.

In the `Program.cs` file, the team registers telemetry using the following code:
csharp
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddApplicationInsightsTelemetry();

During testing in the AKS cluster, the team notices that no telemetry data is populated in the Azure Portal, although the application starts up and processes HTTP requests without any exceptions. The Kubernetes deployment manifest currently defines only the `APPINSIGHTS_INSTRUMENTATIONKEY` environment variable.

Which action must the team take to ensure telemetry is sent successfully?

Show answer & explanation

Answer: Define an environment variable named APPLICATIONINSIGHTS_CONNECTION_STRING in the Kubernetes deployment manifest containing the resource's connection string.

Answer

Define an environment variable named APPLICATIONINSIGHTS_CONNECTION_STRING in the Kubernetes deployment manifest containing the resource's connection string.
Defining the APPLICATIONINSIGHTS_CONNECTION_STRING environment variable is the correct approach. Modern Application Insights SDKs look for this specific environment variable when initializing via AddApplicationInsightsTelemetry without explicit code parameters. The connection string contains the target ingestion endpoint and instrumentation key, which are required for successful data transmission.

Step-by-Step Solution

1
Analyze the telemetry initialization pattern.
The code calls `builder.Services.AddApplicationInsightsTelemetry()` without arguments, which relies on standard environment variables or configuration keys to locate the connection string.
Understanding how the Application Insights SDK retrieves its target configuration is essential to finding the missing configuration point.
2
Identify the configuration source in the Kubernetes environment.
The Kubernetes manifest currently only defines the legacy `APPINSIGHTS_INSTRUMENTATIONKEY` variable, which is deprecated and not automatically mapped to the connection string required by modern .NET SDKs.
Since the connection string is not set, the telemetry SDK will initialize without a destination, resulting in no telemetry being sent to Azure Monitor.
3
Map the correct environment variable for modern Application Insights configuration.
Define `APPLICATIONINSIGHTS_CONNECTION_STRING` containing the full connection string from the Azure Portal.
Modern SDKs require a connection string to enable features like secure ingestion endpoints and regional endpoint routing.

Key Concept

Application Insights SDK requires a valid connection string to ingest telemetry, which is conventionally configured using the APPLICATIONINSIGHTS_CONNECTION_STRING environment variable in containerized environments like AKS.
Question 784Question

You are developing a C# service that processes inventory updates from a session-enabled Azure Service Bus queue named `inventory-queue`. The system must process updates for each store in strict chronological order. You need to implement the message retrieval and processing logic using the Azure.Messaging.ServiceBus SDK. Which sequence of actions must you perform to safely retrieve, process, and complete messages for a store session before releasing the session lock?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To process session-enabled Service Bus messages, you first instantiate a ServiceBusClient, call AcceptNextSessionAsync to lock a session and retrieve a ServiceBusSessionReceiver, use that receiver to call ReceiveMessageAsync, complete the message by calling CompleteMessageAsync, and finally call CloseAsync on the receiver to release the session lock.
The correct order establishes a client connection, locks a session to obtain a session-specific receiver, retrieves a message, completes it after processing, and finally closes the receiver to release the session lock.

Step-by-Step Solution

1
Initialize connection
ServiceBusClient is instantiated.
Connection to the Service Bus namespace must be established first.
2
Acquire session lock
ServiceBusSessionReceiver is created and the session is locked.
Session-enabled queues require locking the session to ensure ordered processing by a single receiver.
3
Receive message
ServiceBusReceivedMessage is retrieved.
Messages must be pulled from the queue via the session receiver.
4
Complete message
Message is deleted from the queue.
Completing the message prevents it from being reprocessed after the lock expires.
5
Release session lock
Session is unlocked and receiver is closed.
Closing the receiver allows other worker instances to pick up new messages for the session.

Key Concept

Session-based message processing and lifecycle management with the Azure Service Bus SDK
Question 785Question

You are developing a command-line interface (CLI) tool in C# that developers will run on Linux servers without a graphical user interface (GUI). The CLI tool must authenticate users against Microsoft Entra ID to access a secure downstream API on their behalf. You need to configure the Microsoft Entra ID application registration and implement the token acquisition logic in the C# code. Which two actions should you perform? (Select two.)

Select all that apply

Show answer & explanation

Answer: In the Microsoft Entra ID application registration, configure the application as a public client by setting the 'Allow public client flows' option to Yes.; In the C# code, instantiate the client using PublicClientApplicationBuilder and call AcquireTokenWithDeviceCode.

Answer

To authenticate a user from a headless CLI tool running on Linux, you must enable public client flows in the Entra ID application registration, and implement the token acquisition in C# using PublicClientApplicationBuilder and AcquireTokenWithDeviceCode.
To authenticate a user from a headless CLI tool running on a non-Azure environment, the application must be registered as a public client in Microsoft Entra ID with public client flows enabled. In the C# code, the application should be instantiated using the PublicClientApplicationBuilder, and the token should be acquired using the AcquireTokenWithDeviceCode method. This allows the user to complete authentication on another device that has a web browser.

Step-by-Step Solution

1
Identify the client application type and environment constraints.
The CLI tool runs on non-Azure Linux servers without a GUI, meaning it is a public client and cannot use interactive web browser redirects.
This determines that the Device Code flow is the appropriate OAuth 2.0 flow for user authentication.
2
Configure the Microsoft Entra ID application registration.
Enable the 'Allow public client flows' toggle (set to Yes) in the Authentication settings of the app registration.
Public clients like CLI tools must be explicitly allowed to use device code or username/password flows in Entra ID.
3
Implement the token acquisition logic in C#.
Use MSAL.NET's PublicClientApplicationBuilder to create the client and call AcquireTokenWithDeviceCode.
This invokes the device code flow, prompting the user to authenticate on another device using a verification URI and code.

Key Concept

Configuring Microsoft Identity Platform authentication for public client applications running on headless devices using the Device Code Flow.
Estimated Time:1m 30s
Question 786Question

You are developing an ASP.NET Core Web API with the Application Insights SDK. To optimize resource consumption in a containerized environment, you must programmatically disable the collection of performance counters and disable adaptive sampling. Complete the code snippet by filling in the correct properties of the ApplicationInsightsServiceOptions class.

Fill in the blanks below

csharp
builder.Services.AddApplicationInsightsTelemetry(options =>
{
options.ConnectionString = builder.Configuration["APPLICATIONINSIGHTS_CONNECTION_STRING"];
options.
= false; // Disables performance counter collection
options.
= false; // Disables adaptive sampling
});
Show answer & explanation

Answer

To programmatically disable performance counter collection, set the EnablePerformanceCounterCollectionModule property to false. To disable adaptive sampling, set the EnableAdaptiveSampling property to false.
The correct properties are EnablePerformanceCounterCollectionModule to toggle the OS performance counter collection module and EnableAdaptiveSampling to control the sampling logic applied to outbound telemetry data.

Step-by-Step Solution

1
Locate the configuration options class used by the Application Insights SDK in ASP.NET Core.
ApplicationInsightsServiceOptions is passed to the AddApplicationInsightsTelemetry extension method configuration lambda.
This class holds the properties to configure the default telemetry modules and telemetry collection behaviors.
2
Find the boolean property responsible for loading the PerformanceCollectorModule.
EnablePerformanceCounterCollectionModule
Setting this property to false stops the SDK from spinning up the module that collects CPU, memory, and garbage collection metrics from the host operating system.
3
Find the boolean property that controls adaptive sampling.
EnableAdaptiveSampling
Setting this property to false disables adaptive sampling, which ensures 100% of telemetry data is transmitted rather than being dynamically sampled.

Key Concept

Configuring default telemetry modules and behavior using ApplicationInsightsServiceOptions in ASP.NET Core.
Question 787Question

A company hosts a legacy REST service behind an Azure API Management (APIM) instance. To prepare the service for migration, you must configure APIM policies to meet the following requirements:
- Remove the '/api/v1' path prefix from all incoming request URLs before forwarding them to the backend service.
- Limit clients to a maximum rate of 500 requests per 60 seconds per subscription.

Which two of the following policy fragments should you add to the <inbound> section of the policy XML file to satisfy these requirements? (Choose two.)

Select all that apply

Show answer & explanation

Answer: <rewrite-uri template="@(context.Request.Url.Path.Replace("/api/v1", ""))" />; <rate-limit calls="500" renewal-period="60" />

Answer

The correct policy fragments are the rewrite-uri policy to modify the request path and the rate-limit policy to limit incoming request rates, both placed in the inbound section.
The rewrite-uri policy and the rate-limit policy are inbound-processing directives. Placing them in the inbound block allows APIM to strip the API version prefix and verify rate limit quotas before routing the request to the backend service.

Step-by-Step Solution

1
Identify the policy required to modify the incoming request path.
The rewrite-uri policy template expression correctly replaces '/api/v1' with an empty string.
Request path modification must happen before routing the request to the backend, placing this policy in the inbound section.
2
Identify the policy required to enforce a rate limit per subscription.
The rate-limit policy allows limiting calls to 500 per 60 seconds.
Rate limiting is an incoming request control policy that must reside in the inbound section to block calls before hitting the backend.
3
Eliminate options placing inbound policies in incorrect execution sections.
Outbound and on-error configurations are discarded.
Outbound policies run after backend execution, and on-error policies run only during execution errors, making them invalid sections for inbound request filtering and URI rewriting.

Key Concept

Azure API Management inbound policy execution and structure
Question 788Question

A developer deploys a C# API to an Azure App Service named api-prod. The API retrieves its database password from an Azure Key Vault named kv-prod. The Key Vault's permission model is configured to use Azure role-based access control (Azure RBAC).

To configure the App Service, the developer creates an application setting named DbPassword with the following value:
@Microsoft.KeyVault(SecretUri=https://kv-prod.vault.azure.net/secrets/DbPassword)

After enabling the system-assigned managed identity on api-prod, the developer observes that the API receives a 403 Forbidden error when trying to retrieve the secret.

Which of the following actions should you perform to resolve the secret retrieval failure?

Show answer & explanation

Answer: Assign the Key Vault Secrets User role to the api-prod system-assigned managed identity at the key vault or secret scope.

Answer

Assign the Key Vault Secrets User role to the api-prod system-assigned managed identity at the key vault or secret scope.
Since the Key Vault is configured to use the Azure RBAC permission model, you must use Azure role assignments to authorize access. Assigning the Key Vault Secrets User role to the App Service's system-assigned managed identity allows the application to read the secret value while maintaining least privilege.

Step-by-Step Solution

1
Identify the authorization model configured on the Azure Key Vault.
The Key Vault is configured to use the Azure role-based access control (Azure RBAC) permission model instead of access policies.
This determines how permissions must be granted to the client application.
2
Determine the correct identity to which permissions must be assigned.
The App Service api-prod has a system-assigned managed identity enabled, which must be granted access.
The client application uses its managed identity to authenticate against the Key Vault.
3
Select the appropriate Azure RBAC role and scope for least privilege secret retrieval.
Assign the Key Vault Secrets User role to the managed identity of the App Service at the key vault or individual secret scope.
Key Vault Secrets User is the built-in role that allows reading secret values, satisfying the least privilege requirement.

Key Concept

Azure Key Vault authorization using Azure RBAC vs Access Policies for App Service managed identities
Question 789Question

A logistics company implements a package dispatch system using an Azure Service Bus queue named `dispatch-queue`. You are writing a C# console application using the `Azure.Messaging.ServiceBus` SDK to process dispatch jobs. The application must guarantee that a dispatch job is only removed from the queue after it is successfully processed and saved to the database. If a database timeout or application crash occurs during processing, the message must become available for other receiver instances after the lock expires.

Which approach should you implement in your C# application to meet these requirements?

Show answer & explanation

Answer: Create a `ServiceBusReceiver` using default options, process the message, and call `CompleteMessageAsync` on the receiver after successful processing.

Answer

Create a ServiceBusReceiver using default options, process the message, and call CompleteMessageAsync on the receiver after successful processing.
The correct approach uses the default PeekLock mode. When a message is retrieved under PeekLock, it remains in the queue but is locked for other receivers. The receiving client must explicitly call CompleteMessageAsync to delete the message from the queue after successful processing. If the client crashes or fails to process the message before the lock duration expires, the lock is released, and the message becomes visible to other receivers, satisfying the durability requirement.

Step-by-Step Solution

1
Identify the appropriate Azure Service Bus receive mode for crash-safety requirements.
Determine that PeekLock mode must be used rather than ReceiveAndDelete, because PeekLock guarantees that messages are not lost if the receiver crashes during processing.
ReceiveAndDelete removes the message immediately upon receipt, causing message loss in the event of a crash, which violates the requirement.
2
Select the default receive mode or configure it explicitly as PeekLock.
A ServiceBusReceiver created with default options uses PeekLock mode by default.
Default configuration reduces code complexity while meeting the safety requirements.
3
Handle message settlement in the client code.
Call CompleteMessageAsync on the receiver instance once the processing succeeds.
With ServiceBusReceiver, PeekLock messages are not automatically settled; they must be explicitly completed to be removed from the queue.

Key Concept

Azure Service Bus Receive Modes and Message Settlement
Estimated Time:1m 30s
Question 790Question

You are troubleshooting an Azure API Management (APIM) instance. A backend API requires an API key, which is stored in Azure Key Vault. You have created an APIM named value named `BackendApiKey` that references the Key Vault secret using the APIM instance's system-assigned managed identity.

You apply the following policy to the inbound section of the API:

xml
<inbound>
<base />
<set-header name="X-Api-Key" exists-action="override">
<value>{{BackendApiKey}}</value>
</set-header>
</inbound>

When clients call the API, they receive an HTTP 500 Internal Server Error. The APIM trace logs show that the named value `BackendApiKey` could not be resolved from Key Vault.

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

Show answer & explanation

Answer: The system-assigned managed identity of the Azure API Management instance has not been granted GET permissions on secrets in the Key Vault access policies or Azure role-based access control (RBAC).

Answer

The system-assigned managed identity of the Azure API Management instance has not been granted GET permissions on secrets in the Key Vault access policies or Azure role-based access control (RBAC).
For Azure API Management to retrieve a secret from Key Vault using a system-assigned managed identity, the identity must have GET permission on secrets in the Key Vault. This can be configured either through Key Vault access policies or by assigning the Key Vault Secrets User RBAC role to the APIM instance's identity.

Step-by-Step Solution

1
Identify the mechanism used to fetch the secret.
The named value BackendApiKey is configured to fetch a secret from Azure Key Vault using the APIM system-assigned managed identity.
Understanding how the value is resolved helps pinpoint the security and access control boundaries.
2
Evaluate access requirements for managed identities reading from Key Vault.
The managed identity requires explicit GET permission on secrets in the target Key Vault's access policies or via Azure RBAC (Key Vault Secrets User role).
Without this permission, Key Vault will deny the request, causing the named value resolution to fail and return an HTTP 500 error.
3
Verify APIM policy syntax and section placement.
The syntax {{BackendApiKey}} is correct for named values, and the inbound section is the correct place to intercept and modify requests before they go to the backend.
This rules out syntactical or structural configuration issues in the APIM policy itself.

Key Concept

Azure API Management named values can reference secrets stored in Azure Key Vault. When using a managed identity to fetch these secrets, the identity must be granted GET permission in Key Vault.
Estimated Time:1m 30s
Question 791Question

You are developing a C# desktop application that will run on employee workstations. The application needs to retrieve user-specific records from an Azure SQL Database. You want to authenticate users via the Microsoft Identity Platform and access the database using the signed-in user's identity. Which authentication configuration should you implement?

Show answer & explanation

Answer: Register the application as a public client in Microsoft Entra ID and use the Microsoft Authentication Library (MSAL.NET) to acquire a token using interactive authentication.

Answer

Register the application as a public client in Microsoft Entra ID and use the Microsoft Authentication Library (MSAL.NET) to acquire a token using interactive authentication.
The correct answer correctly identifies that a desktop application running on local employee workstations is classified as a public client because it cannot keep application secrets confidential. Registering it as a public client and utilizing MSAL.NET to acquire a token interactively allows the app to authenticate the user and obtain a security token for Azure SQL Database under the user's active context.

Step-by-Step Solution

1
Analyze the application execution environment.
The application runs on local workstations, which makes it a public client application because it cannot secure confidential client credentials.
Identifying the client type determines the appropriate OAuth 2.0 flow and MSAL client configuration.
2
Determine the user authentication requirement.
The application must access the database under the signed-in user's identity.
This requires an interactive user authentication flow rather than service-level authentication.
3
Select the correct identity mechanism.
Register the app as a public client in Microsoft Entra ID and use MSAL.NET interactive token acquisition methods.
Managed identities are not supported on local development machines or employee workstations, necessitating MSAL-based user authentication.

Key Concept

Public client authentication with MSAL.NET
Question 792Question

You are developing a C# .NET 8 worker service hosted on Azure Container Apps. The service processes queue messages and is configured to send telemetry to Application Insights.

In Program.cs, you register the telemetry services:
csharp
var builder = Host.CreateApplicationBuilder(args);
builder.Services.AddApplicationInsightsTelemetryWorkerService(options =>
{
options.ConnectionString = builder.Configuration["APPLICATIONINSIGHTS_CONNECTION_STRING"];
});

Within a separate processor class, you instantiate the telemetry client manually to log custom events:
csharp
public class QueueProcessor
{
private static readonly TelemetryClient telemetryClient = new TelemetryClient();

public void ProcessMessage(string message)
{
// Processing logic
telemetryClient.TrackEvent("MessageProcessed");
}
}

During testing, you observe that standard system metrics and dependency telemetry are successfully recorded in Application Insights, but the custom MessageProcessed events are missing.

Which of the following describes the root cause of this behavior?

Show answer & explanation

Answer: The static TelemetryClient is initialized using its parameterless constructor, which does not resolve the configured TelemetryConfiguration from the dependency injection container.

Answer

The static TelemetryClient is initialized using its parameterless constructor, which does not resolve the configured TelemetryConfiguration from the dependency injection container.
The correct answer is correct because manually instantiating TelemetryClient via its parameterless constructor bypasses the dependency injection container. This results in the client using a default, empty TelemetryConfiguration without a connection string. Since the connection string is missing for this client instance, no custom events are tracked, while the system-registered services (which use the injected configuration) continue to function correctly.

Step-by-Step Solution

1
Identify the mechanism used to initialize TelemetryClient.
The code uses a parameterless constructor to manually create the TelemetryClient instance inside QueueProcessor.
To understand why custom events are missing, we must analyze how the client instance is configured.
2
Analyze the behavior of the parameterless TelemetryClient constructor in a DI-managed worker service.
The parameterless constructor does not automatically bind to the DI container's configured TelemetryConfiguration, defaulting to an unconfigured state with a missing connection string.
In modern .NET applications, dependencies should be injected; manually calling the constructor bypasses DI and leaves the instance without a valid destination for telemetry.
3
Compare this with the behavior of system telemetry.
System telemetry is registered via AddApplicationInsightsTelemetryWorkerService and correctly uses the DI container's configuration.
This explains why system metrics are successfully transmitted while custom metrics from the manual client are lost.

Key Concept

Dependency Injection and TelemetryClient configuration in .NET Core / .NET 8 Worker Services
Question 793Question

You are developing a secure C# web API that retrieves a database credential secret from Azure Key Vault. You need to automate the rotation of this secret using Azure Event Grid and a custom Azure Function. Which sequence of steps should you perform to configure the automated rotation?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

Deploy the Azure Function, enable its system-assigned managed identity and assign the Key Vault Secrets Officer role, create the Event Grid subscription for the SecretNearExpiry event targeting the function endpoint, and configure the secret's expiration and rotation policy parameters.
The correct order begins with deploying the function so that its endpoint is generated. Then, you enable the system-assigned managed identity and grant it Key Vault Secrets Officer permission to allow it to write new secret versions. Next, you link the function to Key Vault by creating the Event Grid subscription. Finally, you configure the rotation policy on the secret itself to schedule when the rotation sequence starts.

Step-by-Step Solution

1
Deploy the Azure Function containing rotation logic.
The HTTP trigger endpoint becomes active and accessible.
You cannot register an event subscription handler without a valid destination endpoint.
2
Enable system-assigned managed identity and assign Key Vault Secrets Officer role.
The Function App is authorized to perform write and update operations on Key Vault secrets.
The rotation function must write new secret versions to the vault, which requires the Secrets Officer role rather than the read-only Secrets User role.
3
Create an Event Grid subscription for the SecretNearExpiry event.
Key Vault secret expiry notifications are routed to the function.
This links the life cycle event of the secret directly to the custom handler function.
4
Configure the secret rotation policy parameters.
The secret starts automated lifecycle tracking.
The policy defines when the Key Vault will raise the SecretNearExpiry event before the actual secret expiration occurs.

Key Concept

Azure Key Vault automated secret rotation using Event Grid and Azure Functions.
Question 794Question

An offline data processing utility is written in C# and runs on an Azure Linux VM. You configure telemetry by writing the following code block to log lifecycle events:

csharp
var configuration = new TelemetryConfiguration();
var client = new TelemetryClient(configuration);
client.TrackEvent("JobStarted");

During testing, you notice that no events are captured in the Application Insights logs. You must update the code to ensure telemetry is transmitted correctly.

Which TWO actions should you take to resolve this issue? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Initialize the telemetry configuration object using TelemetryConfiguration.CreateDefault() instead of new TelemetryConfiguration().; Configure the Application Insights connection string by assigning it to the ConnectionString property of the TelemetryConfiguration instance.

Answer

Initialize the telemetry configuration object using TelemetryConfiguration.CreateDefault() and configure the Application Insights connection string by assigning it to the ConnectionString property of the TelemetryConfiguration instance.
To manually configure the Application Insights SDK in a non-web application, you must use TelemetryConfiguration.CreateDefault() to build the default telemetry pipeline, including the channel and default processors. Additionally, you must specify the ConnectionString of the Application Insights resource so the SDK knows where to send the telemetry.

Step-by-Step Solution

1
Change the initialization of TelemetryConfiguration to use the static CreateDefault() factory method.
The TelemetryConfiguration object is instantiated with the standard channel (InMemoryChannel) and default pipeline components.
The parameterless constructor of TelemetryConfiguration does not create the necessary background pipeline (such as the transmission channel) to serialize and send data.
2
Set the ConnectionString property on the configuration object with the connection string retrieved from your Azure environment.
The SDK is configured with the correct ingestion endpoints.
Azure Monitor requires connection strings to handle telemetry routing, endpoint overrides, and authentication securely.

Key Concept

Manual initialization of Application Insights SDK using TelemetryConfiguration and TelemetryClient in non-web environments.
Estimated Time:1m 30s
Question 795Question

An enterprise application uses Azure API Management (APIM). You need to configure an inbound policy that evaluates the 'X-Client-Type' request header. If the header value is 'Internal', the request must route to an internal backend service. Otherwise, it should route to the default backend service. Which XML element names must be used to complete the conditional logic in the policy snippet?

Fill in the blanks below

xml
<inbound>
<base />
<
>
<
condition="@(context.Request.Headers.GetValueOrDefault('X-Client-Type') == 'Internal')">
<set-backend-service base-url="https://internal-api.service.local" />
</
>
</
>
</inbound>
Show answer & explanation

Answer

blank_1: choose, blank_2: when
The choose element evaluates nested when elements sequentially from top to bottom. The first when element with a condition that evaluates to true is applied. This conditional routing structure allows policies to dynamically change backend targets or execute specific operations based on headers.

Step-by-Step Solution

1
Identify the policy structure needed for conditional execution.
The choose block is the correct control-flow policy in Azure API Management.
Azure API Management uses the <choose> element to act as a switch-case statement for evaluating conditions sequentially.
2
Determine the conditional branch element.
The <when> element represents a specific condition to evaluate.
Inside a <choose> element, one or more <when> elements must be defined to evaluate expressions and run nested policies if true.

Key Concept

Conditional policy execution in Azure API Management
Estimated Time:1m 30s
Question 796Question

You are developing a C# background daemon service that will run on an on-premises server. The service must periodically authenticate to the Microsoft Identity Platform without user interaction and retrieve files from a protected web API. You decide to use a client certificate stored in Azure Key Vault for authentication. The daemon service has an application registration in Microsoft Entra ID. Which two actions must you perform to configure the authentication flow and permissions? (Select two.)

Select all that apply

Show answer & explanation

Answer: In the Microsoft Entra ID application registration, upload the public key (.cer file) of the client certificate.; Create an Azure Key Vault access policy that grants the application's service principal Get Secret and Get Certificate permissions.

Answer

To configure the authentication flow, you must upload the public key (.cer file) of the client certificate to the application registration in Microsoft Entra ID, and create an Azure Key Vault access policy that grants the application's service principal Get Secret and Get Certificate permissions.
To set up certificate authentication for a daemon application, you must upload the public key (.cer file) of the certificate to the application registration in Microsoft Entra ID. The application then uses the private key to sign the client assertion. Because the private key is stored securely in Azure Key Vault, you must grant the application's service principal Get Secret and Get Certificate permissions in the Key Vault access policy to retrieve the certificate at runtime.

Step-by-Step Solution

1
Register the client certificate's public key with Microsoft Entra ID.
The public key (.cer file) is associated with the app registration.
Microsoft Entra ID requires the public key to validate token requests signed with the corresponding private key.
2
Authorize the daemon service to retrieve the certificate from Azure Key Vault.
The application's service principal is granted Get Secret and Get Certificate permissions in the Key Vault access policy.
The C# application must load the certificate (containing the private key) from the Key Vault at runtime to construct the client assertion.

Key Concept

Daemon applications are confidential clients that authenticate to the Microsoft Identity Platform using client credentials, such as certificates. This configuration requires registering the public key in Microsoft Entra ID and securely granting access to the private key in Key Vault.
Estimated Time:1m 30s
Question 797Question

You are developing a .NET background worker application that processes messages from an Azure Service Bus queue named sensor-telemetry using the Azure.Messaging.ServiceBus SDK. The messages contain environmental data that must be successfully saved to an external SQL database. If the database is offline, the message must not be lost and must remain in the queue to be retried later. Which approach should you use to receive and process the messages?

Show answer & explanation

Answer: Receive messages using the default PeekLock mode, process the telemetry data, and then call CompleteMessageAsync on the receiver.

Answer

Receive messages using the default PeekLock mode, process the telemetry data, and then call CompleteMessageAsync on the receiver.
Receiving messages using the default PeekLock mode ensures that the message is locked on the queue and invisible to other receivers during processing. Calling CompleteMessageAsync only after the database write succeeds guarantees that the message is safely removed from the queue only when processing is fully successful. If the database is offline, the operation fails before completion, the lock eventually expires, and the message returns to the queue to be processed again.

Step-by-Step Solution

1
Analyze the reliability requirement for message processing.
Identify that the message must remain in the queue for a retry if processing fails.
This rules out any modes that delete the message before successful processing is confirmed.
2
Evaluate the correct Service Bus receive mode.
Select PeekLock mode over ReceiveAndDelete.
PeekLock mode ensures the message remains locked in the queue until either completed or the lock expires, preventing message loss during processing failures.
3
Determine the proper method call for retrieving and finalizing messages.
Use ReceiveMessageAsync to lock the message, then CompleteMessageAsync after processing.
PeekMessageAsync does not lock the message and cannot be followed by a completion call, whereas calling CompleteMessageAsync after successful processing guarantees correct queue cleanup.

Key Concept

Azure Service Bus Receive Modes and SDK message lifecycle management
Question 798Question

An organization hosts a backend service that mandates mutual TLS (mTLS) authentication. You register the backend service in Azure API Management (APIM). You upload the client certificate to the APIM instance and want to configure the APIM gateway to present this certificate to the backend service when routing requests. Which policy configuration must you apply to meet this requirement?

Show answer & explanation

Answer: Place the `authentication-certificate` policy inside the `<inbound>` policy block, referencing the certificate's thumbprint or ID.

Answer

Place the `authentication-certificate` policy inside the `<inbound>` policy block, referencing the certificate's thumbprint or ID.
The correct answer configuration correctly places the `authentication-certificate` policy in the inbound section. This policy configures Azure API Management to present the specified client certificate (referenced by its thumbprint or ID) to the backend service during the TLS handshake, satisfying the mutual TLS requirements of the backend API.

Step-by-Step Solution

1
Analyze the authentication requirements of the backend service.
The backend service requires mutual TLS (mTLS), meaning a client certificate must be provided during the handshake.
This determines that identity-based authentication or header injections are not appropriate for this TLS-level connection.
2
Select the correct Azure API Management policy for certificate-based backend authentication.
The `authentication-certificate` policy is selected.
This policy explicitly instructs the gateway to use a client certificate from the certificate store when establishing a connection to the backend.
3
Determine the proper policy section to apply the selected configuration.
The policy must be applied in the `<inbound>` section.
Inbound policies process the request and configure credentials before the gateway makes the HTTP call to the backend service.

Key Concept

Securing backend connectivity from Azure API Management (APIM) using client certificates (mutual TLS).
Estimated Time:1m 30s
Question 799Question

You are developing a .NET 8 console application that will run as a WebJob on a Linux Azure App Service. The application must track custom operational metrics by using the Application Insights SDK.

You write the following code to initialize the telemetry tracking:

csharp
using Microsoft.ApplicationInsights;
using Microsoft.ApplicationInsights.Extensibility;

class Program
{
static void Main(string[] args)
{
var config = TelemetryConfiguration.CreateDefault();
var client = new TelemetryClient(config);

client.TrackEvent("WebJobStarted");
client.Flush();
}
}

When you run the WebJob, the application executes without throwing any exceptions, but no custom events are visible in your Application Insights resource.

Which of the following changes must you make to ensure that the telemetry data is sent successfully to Azure Monitor?

Show answer & explanation

Answer: Set the ConnectionString property of the TelemetryConfiguration instance to your Application Insights connection string before instantiating the TelemetryClient.

Answer

Set the ConnectionString property of the TelemetryConfiguration instance to your Application Insights connection string before instantiating the TelemetryClient.
Setting the connection string directly on the TelemetryConfiguration instance ensures that the TelemetryClient knows where to send the telemetry. In modern Application Insights SDKs, setting the connection string is mandatory for routing telemetry data, and manually initializing a TelemetryConfiguration without setting this property results in telemetry being silently dropped.

Step-by-Step Solution

1
Identify how the TelemetryClient is initialized in the code snippet.
The code creates a TelemetryConfiguration using TelemetryConfiguration.CreateDefault() and passes it to the TelemetryClient constructor.
Analyzing the initialization flow is necessary to see where telemetry routing configuration is missing.
2
Determine why no telemetry is being sent to Azure Monitor.
The TelemetryConfiguration instance does not have its ConnectionString property set, which means the client has no endpoint to send the telemetry to.
Establishing the root cause of the silent telemetry failure.
3
Configure the connection string in the application code.
Assign the target Application Insights connection string to the ConnectionString property of the config object before creating the TelemetryClient instance.
This supplies the required destination endpoint for the Application Insights SDK to successfully transmit custom event telemetry.

Key Concept

Manually configuring Application Insights TelemetryConfiguration with a Connection String
Question 800Question

You are developing a C# console application that processes FIFO (first-in, first-out) messages from a session-enabled Azure Service Bus queue. The application must guarantee that messages in a session are processed in order and that the session lock is released only after all processing is complete.

Arrange the steps in the correct order to implement this message processing workflow using the Azure.Messaging.ServiceBus SDK.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins by instantiating a ServiceBusClient, followed by calling AcceptNextSessionAsync on it to obtain a session receiver. Next, call ReceiveMessageAsync on the receiver, process the message payload, call CompleteMessageAsync to remove the message, and finally call CloseAsync to release the session lock.
To process session-enabled messages in FIFO order, the application must first establish a connection using the ServiceBusClient, then call AcceptNextSessionAsync to lock the session and obtain a receiver. Once the receiver is obtained, it can fetch a message with ReceiveMessageAsync, process it, complete the message with CompleteMessageAsync, and finally close the receiver using CloseAsync to release the session lock.

Step-by-Step Solution

1
Create a ServiceBusClient instance.
An initialized ServiceBusClient object is ready to communicate with Azure Service Bus.
The client is the entry point for all SDK operations.
2
Call AcceptNextSessionAsync on the ServiceBusClient.
A ServiceBusSessionReceiver is created, locking the next available session.
Session processing requires locking the session to ensure ordered, exclusive delivery.
3
Call ReceiveMessageAsync on the receiver.
A ServiceBusReceivedMessage is fetched from the queue.
Retrieves the message payload within the scope of the locked session.
4
Execute the application business logic on the message.
The data is processed successfully by the system.
Processing must happen before completion to maintain PeekLock safety.
5
Call CompleteMessageAsync on the receiver.
The message is permanently deleted from the Service Bus queue.
Confirms successful processing and prevents reprocessing.
6
Call CloseAsync on the session receiver.
The receiver is closed and the session lock is released.
Enables other processing instances to lock and process the session.

Key Concept

Session-based message processing and locking lifecycle using the Azure Service Bus SDK
Estimated Time:1m 30s
PreviousPage 40 / 49Next
All practice questions — Microsoft Azure Developer (AZ-204) | Examkin