All practice questions

972 questions

Question 661Question

You configure an Azure Cache for Redis instance for an application. You want to ensure that no keys are ever automatically deleted when the cache reaches its memory limit, and that any write operations fail with an error instead.

Which two options describe the correct configuration parameter or behavior for this scenario?

Select all that apply

Show answer & explanation

Answer: The maxmemory-policy configuration setting must be set to noeviction.; Write commands (such as SET or HSET) will return an error when the memory limit is reached.

Answer

To prevent any key eviction under memory pressure and fail writes with an error, the maxmemory-policy must be set to noeviction, which causes write commands to return an out-of-memory error when the cache is full.
To prevent any data from being evicted from the cache under memory pressure, the maxmemory-policy must be set to noeviction. Under this policy, when the cache reaches its memory limit, any commands that attempt to write or add new data will fail and return an out-of-memory error to the application, while read-only requests continue to be served.

Step-by-Step Solution

1
Identify the memory behavior requirement.
The application requires that no keys are ever automatically deleted (evicted) under memory pressure and that write operations fail with an error when the cache is full.
This requirement determines the eviction policy needed for the Redis instance.
2
Select the appropriate maxmemory-policy setting.
Setting maxmemory-policy to noeviction ensures that Redis does not evict any data when full.
The noeviction policy is the only Redis policy that guarantees no keys will be evicted under memory pressure.
3
Determine the resulting application behavior under memory pressure.
Write commands will fail and return errors to the client application, while read-only commands continue to function normally.
This is the default and expected behavior of the noeviction policy when the cache memory limit is reached.

Key Concept

Azure Cache for Redis Eviction Policies
Question 662Question

An organization has deployed a set of backend microservices. You are provisioning a new Azure API Management (APIM) instance to act as a gateway for these services. You need to configure APIM to send diagnostic telemetry, including request and response details, to an Azure Application Insights instance. What should you do to configure the integration between API Management and Application Insights?

Show answer & explanation

Answer: Create an API Management logger resource that references the Application Insights instance, and then configure the diagnostics settings at the API or global level to use that logger.

Answer

Create an API Management logger resource that references the Application Insights instance, and then configure the diagnostics settings at the API or global level to use that logger.
To integrate Azure API Management with Application Insights, you must create a logger resource in API Management pointing to the Application Insights instance. Once the logger is created, you configure the API Management diagnostics settings to use the logger, which starts streaming request and response telemetry.

Step-by-Step Solution

1
Retrieve the instrumentation key or connection string of the target Application Insights instance.
The configuration details required for authentication are obtained.
API Management needs these details to authenticate and send telemetry to Application Insights.
2
Create a logger resource in Azure API Management pointing to the Application Insights instance.
A logger resource of type Microsoft.ApiManagement/service/loggers is created in APIM.
This registers the Application Insights telemetry channel within the APIM service.
3
Configure the diagnostics settings at either the global level or for individual APIs to use the created logger.
Telemetry logging is enabled and requests/responses are streamed to Application Insights.
This activates the streaming of gateway logs using the defined logger.

Key Concept

API Management Integration with Application Insights
Question 663Question

An organization runs a web API on an Azure App Service plan that currently has a capacity of 22 instances. You need to configure Azure Monitor autoscale rules to scale the application. The scale-out rule must add 22 instances when the average CPU percentage over a 1010-minute time window exceeds 80%80\%. To prevent resource flapping while optimizing costs, you must configure a scale-in rule that decreases the instance count by 11 when CPU usage drops. Which configuration successfully supports custom autoscale rules and prevents rule flapping?

Show answer & explanation

Answer: Host the application on a Standard (S1) App Service plan. Set the scale-out threshold to 80%80\% CPU to add 22 instances, and set the scale-in threshold to 30%30\% CPU to decrease the instance count by 11.

Answer

Host the application on a Standard (S1) App Service plan. Set the scale-out threshold to 80%80\% CPU to add 22 instances, and set the scale-in threshold to 30%30\% CPU to decrease the instance count by 11.
The correct configuration uses the Standard (S1) App Service plan, which supports custom autoscale rules. It also prevents autoscale flapping by setting the scale-in threshold to 30%30\%. At the scale-out threshold of 80%80\%, the 22 instances have a total CPU load of 160%160\%. Adding 22 instances increases the total to 44 instances, reducing the average CPU per instance to 40%40\%. A scale-in threshold of 30%30\% is below this post-scale average, ensuring that scaling in is not triggered immediately after scaling out.

Step-by-Step Solution

1
Identify the minimum App Service plan tier required to support custom autoscale rules.
The Standard (S1) tier or higher is required. The Basic (B1) tier does not support custom autoscale rules based on metrics.
Autoscale is a feature of Standard and Premium App Service plans, so any option using a Basic plan is incorrect.
2
Calculate the total CPU workload at the point of scale-out.
With 22 instances running at 80%80\% CPU, the total CPU workload is 2×80%=160%2 \times 80\% = 160\% of a single instance's capacity.
This total workload will be distributed among the new set of instances after the scale-out event.
3
Calculate the average CPU per instance immediately after the scale-out event.
The scale-out rule adds 22 instances, increasing the total count to 44. The average CPU per instance becomes 160%/4=40%160\% / 4 = 40\%.
Knowing the post-scale-out CPU load helps determine the maximum threshold for the scale-in rule to prevent flapping.
4
Determine a scale-in threshold that prevents immediate scale-in (flapping).
The scale-in threshold must be strictly less than 40%40\%. A threshold of 30%30\% satisfies this condition, while thresholds of 45%45\% or 50%50\% would trigger an immediate scale-in.
If the scale-in threshold is greater than or equal to 40%40\%, the autoscale engine will immediately scale back down after scaling up, causing an loop of scaling (flapping).

Key Concept

Preventing autoscale flapping and choosing the correct hosting tier for Azure Monitor autoscale rules.
Question 664Question

An organization hosts a critical Web API on an Azure App Service. You are tasked with implementing a monitoring and alerting strategy using Azure Monitor.

The API must trigger an alert whenever its average response time exceeds 500 milliseconds over a rolling 5-minute window. When the alert fires, it must notify the support team via email and automatically invoke an Azure Function app containing a custom diagnostics logging script. The solution must minimize administrative overhead and avoid hardcoded credentials or manual key rotation.

Which two configurations should you implement to meet these requirements? Select two.

Select all that apply

Show answer & explanation

Answer: Create an Azure Monitor Metric Alert rule targeting the App Service resource, and configure the condition to evaluate the Response Time metric with an aggregation type of Average, operator set to Greater Than, and threshold set to 500 milliseconds over a 5-minute granularity.; Create an Azure Monitor Action Group containing an Email receiver and an Azure Function receiver, configuring the Azure Function receiver by directly selecting the subscription, the target Function App, and the HTTP-triggered function name.

Answer

Configure an Azure Monitor Metric Alert rule evaluating the App Service Response Time metric with an Average aggregation, and an Action Group using the native Azure Function receiver to target the HTTP-triggered function.
To monitor average response times, a Metric Alert rule must be configured targeting the App Service resource with the Response Time metric aggregated as an Average over the desired time window. To trigger a function securely without managing credentials or rotation, the Action Group should utilize the native Azure Function receiver, which automatically connects to the resource via Azure Resource Manager.

Step-by-Step Solution

1
Identify the target resource and metric for response time monitoring.
The App Service resource is selected, and a Metric Alert rule is created using the Response Time metric.
Metric alerts are optimized for low-latency threshold monitoring of system metrics like response times.
2
Configure the metric evaluation criteria.
Set the aggregation type to Average, operator to Greater Than, threshold to 500 milliseconds, and granularity (period) to 5 minutes.
This aligns exactly with the business requirement to detect when the rolling average response time exceeds 500 ms.
3
Configure the Action Group actions.
Add an Email receiver and an Azure Function receiver, selecting the target Function App and HTTP-triggered function name via Azure Resource Manager.
The native Azure Function receiver integrates securely without requiring manual key rotation or storing secrets in webhook URIs.

Key Concept

Azure Monitor Alert Rules and Action Groups integration
Question 665Question

You are developing a .NET background service using the Azure Cosmos DB .NET SDK v3. The service uses the Change Feed Processor to monitor product catalog updates in a source container and synchronize them to an Azure Cognitive Search index. You need to provision a new lease container in Azure Cosmos DB to store the state of the Change Feed Processor. Which partition key path must you define when creating the lease container to ensure the Change Feed Processor can initialize and run?

Show answer & explanation

Answer: /id

Answer

The lease container must be created with the partition key path set to /id.
The correct answer is to use the /id partition key path. In the Azure Cosmos DB .NET SDK v3, the Change Feed Processor relies on a lease container partitioned specifically by /id. This layout allows the processor to acquire, renew, and distribute leases for different partition key ranges of the monitored container to one or more processing hosts.

Step-by-Step Solution

1
Determine the role of the lease container in the Cosmos DB Change Feed Processor architecture.
The lease container acts as a state storage mechanism that coordinates processing of the change feed across multiple consumer instances.
This helps identify if there are specific SDK-level structural requirements for this helper container.
2
Verify the partitioning requirement for the lease container under the .NET SDK v3.
The SDK v3 Change Feed Processor implementation expects the lease container to be partitioned by the /id path.
Choosing any other partition key path will cause the GetChangeFeedProcessorBuilder to throw an initialization exception.

Key Concept

Lease container partition key requirements for the Azure Cosmos DB Change Feed Processor
Question 666Question

You are designing a serverless solution in Azure. You have an Azure Cosmos DB container named Orders. You deploy two separate Azure Functions, ProcessInvoice and UpdateInventory, within the same Function App. Both functions are triggered by changes in the Orders container using the Azure Cosmos DB trigger (CosmosDBTrigger). You configure both triggers to share a single lease container named leases to minimize resource consumption.

During testing, you observe that the two functions compete for partition leases, resulting in each update being processed by only one of the functions, rather than both. You need to ensure that both functions independently process every change feed event from the Orders container.

Which configuration action should you perform?

Show answer & explanation

Answer: Configure a unique LeaseContainerPrefix (such as invoices_ and inventory_) for each function's trigger attribute.

Answer

Configure a unique LeaseContainerPrefix (such as invoices_ and inventory_) for each function's trigger attribute.
Configuring a unique LeaseContainerPrefix allows both functions to use the same lease container while maintaining separate lease tracking documents. Each function acts as an independent consumer group, processing every update in the change feed.

Step-by-Step Solution

1
Analyze the competing consumer behavior of the Azure Functions Cosmos DB trigger.
Identify that when multiple triggers share the same lease container and do not specify a unique prefix, they share the same lease documents and partition ownership, acting as a single consumer group.
This explains why only one function processes a given partition update instead of both functions receiving all updates.
2
Determine the parameter required to isolate lease scopes within the same container.
Identify LeaseContainerPrefix as the attribute property that appends a custom prefix to lease documents, creating separate logical partition tracking.
This allows both functions to run as independent consumer groups while sharing a single physical container.

Key Concept

Using LeaseContainerPrefix in CosmosDBTrigger to support multiple independent consumer groups sharing a lease container.
Estimated Time:1m 30s
Question 667Question

A digital publishing company is building a newsletter distribution system. They use an Azure Service Bus queue named `newsletter-campaigns` to manage subscriber email campaigns. They require that if a sending service instance fails while processing a newsletter message, the message must be automatically returned to the queue so that another instance can attempt to process it.

Which configuration or method should you use to meet this requirement?

Show answer & explanation

Answer: Configure the receiver to use `ServiceBusReceiveMode.PeekLock`.

Answer

Configure the receiver to use ServiceBusReceiveMode.PeekLock.
Configuring the receiver to use PeekLock mode is correct because it ensures that messages are locked during processing but remain in the queue. If the receiver fails or crashes before completing the message, the lock will time out and the message will automatically become available for processing again.

Step-by-Step Solution

1
Analyze the reliability requirement for the newsletter application.
The application requires that messages must not be lost if a receiver fails during processing, meaning at-least-once delivery is required.
Understanding the delivery guarantee is necessary to select the appropriate message receipt mode.
2
Compare Azure Service Bus receive modes for message processing.
PeekLock mode retrieves the message and locks it temporarily without deleting it, while ReceiveAndDelete mode deletes the message immediately from the queue upon retrieval.
This comparison helps identify which mode protects messages against receiver failures.
3
Select the configuration that guarantees message recovery.
Configuring the receiver to use ServiceBusReceiveMode.PeekLock ensures the message returns to the queue if the receiver fails before completing the processing.
This satisfies the requirement of returning the message to the queue for another instance to process.

Key Concept

Azure Service Bus receive modes (PeekLock vs. ReceiveAndDelete) and their impact on message durability and delivery guarantees.
Estimated Time:45s
Question 668Question

An independent software vendor (ISV) is registering a new multi-tenant line-of-business application in Microsoft Entra ID. The application is designed to allow employees from any enterprise customer to log in with their work credentials, but it must reject sign-in attempts from personal Microsoft accounts.

Which configuration should the developer apply to the application manifest and the application's authentication endpoint?

Show answer & explanation

Answer: Set `signInAudience` to `AzureADMultipleOrgs` and use the `/organizations` authority endpoint.

Answer

Set the signInAudience to AzureADMultipleOrgs and use the /organizations authority endpoint.
Setting the signInAudience to AzureADMultipleOrgs restricts sign-ins to work or school accounts. Using the /organizations authority endpoint enforces this constraint at the Entra ID sign-in screen, ensuring personal accounts cannot log in.

Step-by-Step Solution

1
Evaluate the required sign-in audience scope.
Determine that `AzureADMultipleOrgs` is required to allow users from any enterprise directory while excluding personal Microsoft accounts.
Choosing `AzureADMyOrg` would limit authentication to a single tenant, whereas `AzureADandPersonalMicrosoftAccount` would allow personal accounts.
2
Determine the optimal authority endpoint.
Select the `/organizations` endpoint instead of `/common`.
The `/organizations` endpoint restricts access to organizational accounts directly at the authentication gate, avoiding user confusion by not allowing personal accounts to enter credentials.

Key Concept

Microsoft Entra ID Multi-tenant Sign-in Audience and Endpoint Filtering
Estimated Time:1m 30s
Question 669Question

You are deploying a new Azure Cache for Redis instance to store session data. To ensure that the cache has sufficient memory allocated for replication and synchronization overhead between primary and replica nodes, you must configure a dedicated memory reserve. Which configuration setting should you adjust?

Show answer & explanation

Answer: maxmemory-reserved

Answer

maxmemory-reserved
The setting maxmemory-reserved determines the amount of memory (in MB) that is set aside for non-cache operations such as replication and failover overhead. Setting this appropriately prevents the cache from running out of memory during synchronization tasks.

Step-by-Step Solution

1
Identify the requirement to allocate memory for replication and synchronization overhead rather than active caching data.
Recognize that Azure Cache for Redis needs dedicated memory reserved for non-cache operations such as replication and failover.
Reserving memory prevents the Redis server from failing or experiencing high latency under heavy write loads due to overhead.
2
Select the configuration parameter that controls this memory reservation.
Identify maxmemory-reserved as the configuration setting that reserves memory in megabytes for non-cache operations.
Parameters like maxmemory-policy manage eviction policies, whereas maxmemory-reserved handles resource preservation.

Key Concept

Configuring maxmemory-reserved in Azure Cache for Redis to allocate space for replication and non-cache operations.
Question 670Question

You are designing a C# backend service to update a custom metadata tag on a blob in Azure Blob Storage. The target blob is currently protected by an active write lease. The operation must be authenticated using a Shared Access Signature (SAS) token adhering to the principle of least privilege, and the updated metadata value must be verified immediately after. Which C# code segment should you use to successfully perform this operation?

Show answer & explanation

Answer: var sas = new BlobSasBuilder { ExpiresOn = DateTimeOffset.UtcNow.AddMinutes(15) };
sas.SetPermissions(BlobSasPermissions.Read | BlobSasPermissions.Write);
var client = new BlobClient(blobUri, sas.ToSasQueryParameters(credential));
await client.SetMetadataAsync(new Dictionary<string, string> { { "Department", "Finance" } }, new BlobRequestConditions { LeaseId = leaseId });
var dept = (await client.GetPropertiesAsync()).Value.Metadata["department"];

Answer

The C# code segment that configures a SAS token with 15 minutes expiration and Read/Write permissions, includes the active Lease ID in the request conditions when calling SetMetadataAsync, and retrieves the metadata value using the lowercase key "department".
The correct implementation creates a SAS token with the minimum required permissions (Read and Write) and a short duration (15 minutes). When calling SetMetadataAsync, the active lease ID must be passed via the BlobRequestConditions parameter to prevent a lease-conflict failure. Finally, because Azure Blob Storage stores and returns metadata keys in lowercase, retrieving the value requires querying the Metadata dictionary with the lowercase key 'department'.

Step-by-Step Solution

1
Configure a SAS token with the minimum required permissions.
A SAS token is built with only Read and Write permissions, expiring in 15 minutes to follow least-privilege principles.
The client must write metadata and read it back, meaning both Read and Write permissions are required, while longer expiries or extra permissions like Delete must be avoided.
2
Call SetMetadataAsync with the active Lease ID.
The metadata dictionary is updated on the Azure Storage service successfully.
Since the blob has an active write lease, any attempt to modify its properties or metadata without passing the active Lease ID in the BlobRequestConditions object will fail with a 412 Precondition Failed status code.
3
Retrieve the metadata properties using a lowercase lookup key.
The string 'Finance' is correctly returned without throwing a KeyNotFoundException.
Azure Blob Storage converts all custom metadata keys to lowercase upon storage. Even if they are uploaded with uppercase characters, they must be accessed via lowercase keys when retrieving them from the SDK metadata dictionary.

Key Concept

Managing Blob Metadata, Lease Handling, and SAS Authorization in C#
Estimated Time:1m 30s
Question 671Question

You are deploying a set of containerized microservices to an on-premises Docker environment. You want to use an existing Azure API Management (APIM) instance in the cloud to manage and secure these on-premises microservices. You decide to provision a self-hosted gateway.

Which of the following actions must you perform to configure and run the self-hosted gateway? (Select TWO)

Select all that apply

Show answer & explanation

Answer: Create a Gateway resource in the Azure API Management instance and retrieve the configuration endpoint URL and an access token.; Deploy the official self-hosted gateway Docker container, passing the configuration endpoint URL and access token as environment variables.

Answer

To provision and run the self-hosted gateway, you must create a Gateway resource in the API Management instance to retrieve the configuration endpoint and access token, and then deploy the official gateway container using these values as environment variables.
To deploy a self-hosted gateway, you must first register it as a Gateway resource in your Azure API Management instance. This registration provides the configuration endpoint URL and an access token. You then run the gateway container (e.g., in Docker) and pass these values as environment variables (config.service.endpoint and config.service.auth) so the gateway can pull its configuration.

Step-by-Step Solution

1
Register the Gateway in Azure API Management
A configuration endpoint and an access token are generated.
The gateway container needs these credentials to authenticate and fetch its configuration from Azure.
2
Run the Gateway Container on-premises
The gateway container starts up and connects to the APIM control plane.
Providing the configuration endpoint and token as environment variables allows the containerized gateway to sync its API routing rules.

Key Concept

Provisioning and deploying an Azure API Management self-hosted gateway

Alternative Method

Alternatively, you can deploy the self-hosted gateway to a Kubernetes cluster using a Helm chart or YAML manifest, but you must still provision the Gateway resource in Azure and provide the endpoint and token as configuration secrets.
Estimated Time:1m 30s
Question 672Question

A telemetry processing application runs as a C# worker service on Azure Container Apps. The application uses the EventProcessorClient from the Azure.Messaging.EventHubs.Processor library to consume messages from an Azure Event Hub and uses an Azure Blob Storage container for checkpointing. The Container App is configured to use a user-assigned managed identity. During testing, you observe that partition ownership cannot be established, and checkpointing fails with access and lease errors. Which two actions must you perform to configure the storage client and resolve these issues? (Select two.)

Select all that apply

Show answer & explanation

Answer: Assign the Storage Blob Data Contributor role to the user-assigned managed identity on the storage container.; Initialize the BlobContainerClient using DefaultAzureCredential configured with the client ID of the user-assigned managed identity.

Answer

To resolve the checkpointing issues, you must assign the Storage Blob Data Contributor role to the user-assigned managed identity on the storage container and initialize the BlobContainerClient using DefaultAzureCredential configured with the client ID of the user-assigned managed identity.
To enable EventProcessorClient checkpointing, the user-assigned managed identity requires data-plane write access (Storage Blob Data Contributor) on the container to write lease and checkpoint metadata. Additionally, because the application utilizes a user-assigned managed identity, the developer must explicitly specify the client ID in DefaultAzureCredentialOptions to ensure the correct identity is resolved.

Step-by-Step Solution

1
Assign the appropriate data-plane role to the identity.
The user-assigned managed identity receives permission to read, write, and delete blobs inside the container.
The EventProcessorClient uses blobs inside the container to track ownership and store checkpoint markers.
2
Configure the token credential with the client ID of the user-assigned managed identity.
The identity is correctly resolved during runtime authentication rather than failing or reverting to a system-assigned identity.
User-assigned managed identities are not automatically selected by default credential configurations and must be targeted via their client ID.
3
Initialize the EventProcessorClient using the properly authenticated BlobContainerClient.
The processor successfully coordinates partition ownership across instances and records checkpoint offsets without lease or permission failures.
A properly configured container client provides the backend storage access required by the event processor.

Key Concept

Configuring EventProcessorClient storage checkpointing with user-assigned managed identities and Azure RBAC roles.
Question 673Question

An enterprise application stores user profile updates in an Azure Cosmos DB container named Profiles. You need to implement two separate microservices using the .NET SDK v3: one to update a search index, and another to send welcome emails. Both microservices must process all change feed notifications from the Profiles container independently. You plan to use a single shared container named leases to store the lease state.

Which two of the following configuration steps must you perform to ensure both microservices process all changes?

Select all that apply

Show answer & explanation

Answer: Configure each microservice's change feed processor with a unique processor name using the WithProcessorName method.; Configure both change feed processors to point to the leases container as their lease container.

Answer

Configure each microservice's change feed processor with a unique processor name using the WithProcessorName method, and configure both change feed processors to point to the leases container as their lease container.
To process change feed notifications independently for multiple distinct business requirements, each microservice must represent a separate logical consumer group. In the Azure Cosmos DB .NET SDK v3, this is achieved by assigning a unique processor name to each Change Feed Processor instance via the WithProcessorName method. When sharing a single lease container, the unique processor name acts as a prefix key namespace, allowing both microservices to store and manage their leases in the same container without interfering with each other.

Step-by-Step Solution

1
Determine the separation of concerns for the microservices.
Since the search index updater and the welcome email sender must process all updates independently, they represent two distinct consumer groups.
Independent processing requires separate lease tracking to ensure one service's progress doesn't affect the other's.
2
Configure the lease storage mechanism.
Initialize both processors using the same lease container named 'leases', but assign different processor names using the WithProcessorName builder method.
Unique processor names allow multiple independent consumer groups to share the same lease container without conflicts.
3
Verify lease container requirements.
Ensure the 'leases' container is provisioned with /id as the partition key, not matching the monitored container's partition key (/userId).
The Cosmos DB .NET SDK v3 Change Feed Processor specifically requires the lease container to have /id as its partition key.

Key Concept

Azure Cosmos DB Change Feed Processor Multi-Consumer Configuration
Question 674Question

You are deploying an ASP.NET Core web application to an Azure App Service. The application must securely retrieve a database password stored as a secret in Azure Key Vault. You decide to use a system-assigned managed identity and Key Vault references to configure the application.

Which sequence of steps should you perform to configure the Azure resources and the App Service to resolve the secret?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order of steps is: 1) Enable the system-assigned managed identity on the Azure App Service instance. 2) Assign the Key Vault Secrets User role to the App Service's managed identity on the Azure Key Vault. 3) Retrieve the Secret Identifier (URI) of the database password secret from the Key Vault. 4) Add a new application setting in the App Service with a value formatted as @Microsoft.KeyVault(SecretUri=...).
The correct order establishes the security identity first, then applies the necessary Key Vault role permissions to it, retrieves the required secret identifier, and finally sets up the application configuration using the Key Vault reference syntax.

Step-by-Step Solution

1
Enable the system-assigned managed identity on the Azure App Service instance.
A service principal representing the App Service is created in Microsoft Entra ID.
This establishes the identity that will be authorized to access the Key Vault.
2
Assign the Key Vault Secrets User role to the App Service's managed identity on the Key Vault.
The App Service's identity is authorized to read secrets from the Key Vault.
Permissions must be configured in advance so that the App Service can resolve the secret reference as soon as it is configured.
3
Retrieve the Secret Identifier (URI) of the secret from the Key Vault.
The target secret's URI is copied.
The URI is required to construct the Key Vault reference syntax used in the App Service configuration.
4
Add a new application setting to the App Service using the @Microsoft.KeyVault(SecretUri=...) syntax.
The Key Vault reference is saved to the App Service settings.
The App Service runtime automatically detects this setting pattern, resolves the reference using the managed identity, and exposes the decrypted secret to the application code.

Key Concept

To securely reference Azure Key Vault secrets from App Service without code changes, you must enable a managed identity on the app, grant it the Key Vault Secrets User role on the Key Vault, and configure the app setting using the @Microsoft.KeyVault(SecretUri=...) syntax.
Question 675Question

An operations engineer needs to implement a message consumer in C# for Azure Queue Storage using the modern Azure.Storage.Queues SDK. The consumer must acquire a message, process it, and then immediately delete it from the queue.

Complete the C# code snippet below by filling in the blanks. What are the correct asynchronous method names to retrieve and delete the message?

Fill in the blanks below

csharp
QueueClient queueClient = new QueueClient(connectionString, "work-items");

// Retrieve the message
QueueMessage[] messages = await queueClient.
(maxMessages: 1);

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

// Process the message...

// Permanently remove the message from the queue
await queueClient.
(message.MessageId, message.PopReceipt);
}
Show answer & explanation

Answer

The message must be retrieved using the ReceiveMessagesAsync method, and then permanently deleted from the queue using the DeleteMessageAsync method.
The ReceiveMessagesAsync method retrieves one or more messages and makes them invisible to other processors. It provides the PopReceipt which, along with the MessageId, must be passed to DeleteMessageAsync to successfully remove the message from the queue.

Step-by-Step Solution

1
Identify the method required to pull a message from the queue and mark it as invisible to other consumers.
ReceiveMessagesAsync is the standard asynchronous method to retrieve messages.
This method hides the message for a default visibility timeout and returns a PopReceipt required for later deletion.
2
Identify the method required to permanently delete the message once processing is complete.
DeleteMessageAsync removes the message using its ID and PopReceipt.
Explicitly deleting the message ensures it does not return to the queue when the visibility timeout expires.

Key Concept

Retrieving and deleting messages using the Azure.Storage.Queues SDK
Estimated Time:1m 0s
Question 676Question

You are developing a .NET application that will write data to a newly provisioned Azure Cache for Redis instance. You need to connect to the cache and write a test key-value pair using the StackExchange.Redis library. Which sequence of steps should you perform? To answer, arrange the actions in the correct order.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To connect to and write to Azure Cache for Redis using StackExchange.Redis, you must first add the StackExchange.Redis package to your project. Next, retrieve the connection string from the Azure portal. Third, initialize the ConnectionMultiplexer object by calling ConnectionMultiplexer.Connect. Fourth, get a database reference using the GetDatabase method. Finally, perform the write operation by calling StringSet.
Interacting with Azure Cache for Redis starts by installing the required StackExchange.Redis SDK package to make developer APIs available. Once installed, the application requires credentials, which are retrieved as a connection string from the Azure portal. Using this connection string, a ConnectionMultiplexer object is instantiated via ConnectionMultiplexer.Connect. This handles network socket multiplexing and configuration. A database instance is then obtained by calling GetDatabase, which provides the necessary context for commands. Finally, key-value operations like StringSet are executed on this database instance.

Step-by-Step Solution

1
Install NuGet package
The project gains access to the StackExchange.Redis namespaces and types.
The client library provides the necessary API for communicating with Redis.
2
Obtain connection credentials
The target host name, ports, and authorization keys are copied.
The connection credentials are required to authenticate client traffic.
3
Initialize ConnectionMultiplexer
The client establishes a long-lived socket connection to the server.
The ConnectionMultiplexer represents the shared gateway through which database operations flow.
4
Request Database reference
An IDatabase instance is returned.
Standard key-value commands are exposed through the IDatabase interface.
5
Call StringSet
The database registers the key and value.
StringSet stores the specified key and associated string value in the cache.

Key Concept

Connecting to and interacting with Azure Cache for Redis via StackExchange.Redis in a .NET application.
Question 677Question

An application named App1 needs to be configured in Microsoft Entra ID. The application will be consumed by multiple external business partners who use their own corporate Entra ID directories, alongside external consultants who will sign in using their personal Microsoft accounts.

Which two configurations are required to support this authentication requirement? (Select two.)

Select all that apply

Show answer & explanation

Answer: Set the signInAudience property in the application manifest to AzureADandPersonalMicrosoftAccount; Use the common endpoint in the authority URI for user authentication

Answer

To support authentication for users from any corporate Entra ID tenant as well as personal Microsoft accounts, you must set the signInAudience property in the application manifest to AzureADandPersonalMicrosoftAccount and use the common endpoint in the authority URI for user authentication.
To support both multi-tenant organizational users and personal Microsoft accounts, the signInAudience parameter in the application manifest must be set to AzureADandPersonalMicrosoftAccount. In addition, the application's authentication configuration must point to the common endpoint (https://login.microsoftonline.com/common) because it routes both organizational and personal accounts, unlike the organizations endpoint which only routes organizational accounts.

Step-by-Step Solution

1
Identify the target user base requirements.
The application must support both multi-tenant organizational users (Entra ID) and personal accounts (Microsoft Accounts).
This determines the required directory audience and authentication endpoint configuration.
2
Choose the correct manifest sign-in audience.
Select AzureADandPersonalMicrosoftAccount.
The AzureADandPersonalMicrosoftAccount audience is designed specifically to allow logins from any Entra ID directory and personal Microsoft accounts.
3
Configure the authority endpoint in the application code.
Use the common endpoint (https://login.microsoftonline.com/common).
The common endpoint routes requests dynamically for both organizational accounts and personal Microsoft accounts, whereas the organizations endpoint restricts access to organizational accounts only.

Key Concept

Configuring multi-tenant Microsoft Entra ID applications to support both organizational accounts and personal Microsoft accounts.
Question 678Question

An organization hosts a retail web application on an Azure Virtual Machine Scale Set (VMSS) with a minimum instance count of 22 and a maximum instance count of 1010. You configure a scale-out rule that increases the instance count by 22 instances when the average CPU Percentage is greater than 80%80\%. You need to configure a scale-in rule to reduce the instance count when demand drops. Which of the following scale-in configurations will prevent autoscale flapping? (Select two.)

Select all that apply

Show answer & explanation

Answer: A scale-in rule that decreases the instance count by 11 instance when the average CPU Percentage is less than 50%50\%.; A scale-in rule that decreases the instance count by 22 instances when the average CPU Percentage is less than 35%35\%.

Answer

The correct scale-in configurations are a decrease of 1 instance when the CPU is less than 50%, and a decrease of 2 instances when the CPU is less than 35%.
To prevent flapping, the average CPU percentage after a scale-in must be less than the scale-out threshold of 80%80\%. For a scale-in of 1 instance from 3 to 2, a scale-in threshold of 50%50\% ensures the new CPU is at most (3×50%)/2=75%<80%(3 \times 50\%) / 2 = 75\% < 80\%. For a scale-in of 2 instances from 4 to 2, a scale-in threshold of 35%35\% ensures the new CPU is at most (4×35%)/2=70%<80%(4 \times 35\%) / 2 = 70\% < 80\%. Both configurations are stable.

Step-by-Step Solution

1
Calculate the maximum workload just before the scale-in event triggers for each option.
For a threshold TinT_{in} at NN instances, the workload is N×TinN \times T_{in}.
This workload is redistributed across the remaining instances after the scale-in occurs.
2
Determine the post-scale-in average CPU percentage.
For scale-in by kk instances, the new average CPU is (N×Tin)/(Nk)(N \times T_{in}) / (N - k).
To avoid flapping, this new value must be strictly less than the scale-out threshold of 80%80\%.
3
Evaluate the worst-case scenario at the minimum instance count where scaling can occur (N=3N = 3 for k=1k=1, and N=4N = 4 for k=2k=2).
With k=1k=1, TinT_{in} must be <53.33%< 53.33\%. With k=2k=2, TinT_{in} must be <40%< 40\%.
Applying these limits shows that 50%50\% (for k=1k=1) and 35%35\% (for k=2k=2) are safe thresholds, while 55%55\% and 45%45\% trigger immediate scale-out loops.

Key Concept

Autoscale flapping prevention and metric threshold calculations
Question 679Question

A C# application updates the custom metadata of an Azure Blob Storage block blob that has an active write lease. You are using the Azure.Storage.Blobs SDK (version 12) to add a metadata key-value pair of 'status' and 'processed'. Which of the following actions are required to complete this operation successfully without triggering exceptions? (Select TWO)

Select all that apply

Show answer & explanation

Answer: Pass the lease ID within a BlobRequestConditions object to the SetMetadataAsync method.; Exclude the x-ms-meta- prefix from the key name in the metadata dictionary.

Answer

To successfully update the metadata of a leased blob, you must pass the lease ID within a BlobRequestConditions object to the SetMetadataAsync method, and you must exclude the x-ms-meta- prefix from the metadata dictionary key names.
Updating metadata on a leased blob requires verifying ownership of the lease by passing the lease ID in a BlobRequestConditions object to the SetMetadataAsync method. Additionally, the SDK automatically prepends the required 'x-ms-meta-' header prefix to keys in the metadata dictionary, so developers must define keys without this prefix.

Step-by-Step Solution

1
Identify the lease status of the target blob.
Since the blob is leased, any metadata update requires authentication of the lease.
An active lease blocks metadata updates unless the lease ID is supplied.
2
Create a BlobRequestConditions object and set its LeaseId property.
A BlobRequestConditions instance is prepared with the active lease ID.
This object is passed as a parameter to SetMetadataAsync to authorize the modification.
3
Populate the IDictionary<string, string> with metadata keys.
The metadata dictionary contains 'status' rather than 'x-ms-meta-status'.
The Azure.Storage.Blobs SDK automatically prefixes metadata keys with x-ms-meta- during transmission.

Key Concept

Updating metadata on leased blobs requires passing the active lease ID using BlobRequestConditions and specifying dictionary keys without the x-ms-meta- prefix.
Question 680Question

You are configuring a custom domain for the gateway endpoint of an Azure API Management (APIM) instance. The TLS certificate for the custom domain is stored in an Azure Key Vault. You want to use the system-assigned managed identity of the APIM instance to authorize access to the Key Vault. Which of the following describes the correct set of actions to configure the custom domain?

Show answer & explanation

Answer: Enable the system-assigned managed identity on the API Management instance. Grant the managed identity the Get secret permission in the Key Vault access policies. In API Management, add the custom domain and select the certificate from the Key Vault.

Answer

Enable the system-assigned managed identity on the API Management instance, grant the managed identity the Get secret permission in the Key Vault access policies, and configure the custom domain in API Management by selecting the certificate from Key Vault.
To secure a custom domain in Azure API Management using a certificate from Azure Key Vault, you must first enable the system-assigned managed identity on the API Management instance. Next, you must grant this identity the Get secret permission in the Key Vault's access policies (or assign an equivalent RBAC role such as Key Vault Secrets User), as API Management needs to read the secret representing the certificate to access the private key. Finally, the custom domain can be configured within the API Management instance by referencing the Key Vault certificate.

Step-by-Step Solution

1
Enable the system-assigned managed identity on the API Management instance.
The instance gets an identity registered in Microsoft Entra ID (Azure Active Directory).
This allows the API Management instance to authenticate directly against Azure resources like Key Vault without managing credentials.
2
Configure Azure Key Vault access policies to grant the API Management system-assigned managed identity the 'Get' permission for Secrets.
The managed identity is authorized to retrieve secrets from the Key Vault.
API Management requires the 'Get' permission for secrets (rather than just certificates) to retrieve the private key of the certificate stored in Key Vault.
3
In the API Management instance, go to Custom Domains, add a new gateway hostname, choose Key Vault as the certificate source, select the certificate, and save.
The custom domain is configured and bound to the TLS certificate retrieved from Key Vault.
This binds the custom domain to the gateway endpoint and enables TLS handshake using the certificate.

Key Concept

Key Vault integration for API Management custom domains using managed identity
PreviousPage 34 / 49Next
All practice questions — Microsoft Azure Developer (AZ-204) | Examkin