All practice questions

171 questions

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

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

Initialize connection

ServiceBusClient is instantiated.

Connection to the Service Bus namespace must be established first.

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.

Receive message

ServiceBusReceivedMessage is retrieved.

Messages must be pulled from the queue via the session receiver.

Complete message

Message is deleted from the queue.

Completing the message prevents it from being reprocessed after the lock expires.

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 142Question →

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

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.

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.

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.

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 143Question →

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

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.

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.

Call ReceiveMessageAsync on the receiver.

A ServiceBusReceivedMessage is fetched from the queue.

Retrieves the message payload within the scope of the locked session.

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.

Call CompleteMessageAsync on the receiver.

The message is permanently deleted from the Service Bus queue.

Confirms successful processing and prevents reprocessing.

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

Question 144Question →

You need to upload a locally built container image to a private Azure Container Registry (ACR) named contosoacr. Arrange the following commands in the correct sequence to authenticate your session and push the image to the registry.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence of commands is to first run `az login` to authenticate with Azure, then run `az acr login --name contosoacr` to authenticate with the specific registry, and finally run `docker push contosoacr.azurecr.io/myimage:v1` to upload the image.

The correct order requires first authenticating with Azure via `az login` to set up the CLI credentials context. Next, `az acr login --name contosoacr` uses that context to log the Docker daemon into the target registry. Finally, `docker push contosoacr.azurecr.io/myimage:v1` uploads the image now that authentication is successful.

Step-by-Step Solution

Run `az login`.

Establishes an active Azure session in the Azure CLI.

This is required so subsequent Azure CLI commands can access subscription details and credentials.

Run `az acr login --name contosoacr`.

Authenticates the local Docker client daemon with the `contosoacr` registry.

This command retrieves registry credentials using the active Azure CLI session to allow Docker operations.

Run `docker push contosoacr.azurecr.io/myimage:v1`.

Transfers the container image to the Azure Container Registry.

Since the local Docker CLI is authenticated, the push command can upload the image to the login server without authorization errors.

Key Concept

To push local container images to a private Azure Container Registry (ACR), you must first authenticate with Azure using `az login`, authenticate the local Docker client to the registry using `az acr login`, and then execute `docker push` with the registry's login server path.

Question 145Question →

You need to create a new Azure Function App on an Elastic Premium plan using the Azure CLI. Which sequence of commands should you execute? To answer, arrange the steps in the correct order.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order of commands is to first create the resource group, then create the storage account, followed by creating the Elastic Premium App Service plan, and finally creating the Function App.

The resource group must exist first. Then, the storage account and the App Service plan are created as they have no mutual dependencies but both require the resource group. Finally, the function app is created because it depends on the resource group, the storage account, and the App Service plan.

Step-by-Step Solution

Create the Resource Group

az group create --name myResourceGroup --location eastus

All other resources require a resource group to be defined first.

Create the Storage Account

az storage account create --name mystorageaccount --location eastus --resource-group myResourceGroup --sku Standard_LRS

The function app relies on standard storage for state and key management.

Create the App Service Plan

az appservice plan create --name myPremiumPlan --resource-group myResourceGroup --sku EP1 --is-linux

An Elastic Premium plan (EP1 SKU) is required before assigning the function app to it.

Create the Function App

az functionapp create --name myFunctionApp --resource-group myResourceGroup --storage-account mystorageaccount --plan myPremiumPlan --runtime dotnet-isolated --functions-version 4

The function app links the previously created storage account and hosting plan.

Key Concept

Azure Functions resources have creation dependencies: a resource group must exist first, followed by storage and hosting plan resources, before the function app itself can be initialized.

Question 146Question →

You are configuring a lifecycle management policy for a Standard General Purpose v2 (GPv2) storage account to minimize costs for log blobs. The policy will transition blobs through various access tiers and eventually delete them.

Arrange the following lifecycle policy events in the correct chronological order of execution for a newly created blob, starting from the earliest event to the latest.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct chronological order starts with uploading the blob to the Hot tier, followed by transitioning it to the Cool tier (`tierToCool`), then transitioning it to the Archive tier (`tierToArchive`), and finally permanently deleting the blob (`delete`).

The correct chronological sequence for optimizing costs moves the blob from the Hot tier (initial upload) to the Cool tier (`tierToCool`), then to the Archive tier (`tierToArchive`), and lastly to the deleted state (`delete`). This aligns with the progressive decline in storage tier costs and access frequencies.

Step-by-Step Solution

Identify the initial state of the blob.

The blob starts in the Hot tier upon upload.

Standard GPv2 accounts default to the Hot tier for new blob writes unless specified otherwise.

Determine the first cost-tier transition.

Transition to the Cool tier (`tierToCool`).

Cool tier is the next progressive tier offering lower storage costs than Hot but higher than Archive.

Determine the second cost-tier transition.

Transition to the Archive tier (`tierToArchive`).

Archive tier offers the lowest storage costs but has high retrieval latency and cost, suitable for historical data before deletion.

Identify the final lifecycle action.

Permanent deletion (`delete`).

Deleting the blob removes it permanently to prevent any further storage charges.

Key Concept

Azure Storage Lifecycle Management allows automatic transitioning of blobs to cooler storage tiers (Hot to Cool, Cool to Archive) and deletion based on age rules.

Question 147Question →

An administrator needs to configure an Azure CDN Standard from Microsoft endpoint to use a custom domain secured with a custom TLS certificate stored in Azure Key Vault. The configuration must be completed successfully with minimum delay, and all validation checks must succeed. What is the correct order of steps to configure the custom domain and TLS certificate?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order is: (1) Register the Azure CDN service principal in Microsoft Entra ID. (2) Configure the Key Vault access policy to grant the service principal permissions. (3) Create the DNS CNAME record. (4) Add the custom domain to the CDN endpoint. (5) Enable HTTPS on the custom domain and select the certificate from Key Vault.

The configuration must follow a strict dependency path: The Azure CDN service principal must be registered in Microsoft Entra ID first so that it can be granted access to the Key Vault. The DNS CNAME record must be created prior to adding the custom domain to the CDN endpoint to pass the domain ownership validation check. Finally, once the custom domain is registered and Key Vault permissions are established, HTTPS can be enabled using the custom certificate.

Step-by-Step Solution

The Azure CDN service principal identity is created and recognized within the tenant.

The service principal must exist in the directory before you can reference it in Key Vault access policies.

Create a Key Vault access policy that grants the Azure CDN service principal Get permissions for certificates and secrets.

Azure CDN is authorized to retrieve certificates from the Key Vault.

Azure CDN needs these permissions to fetch and install the custom TLS certificate on the CDN edge servers.

Create a CNAME record with your DNS provider mapping the custom domain to the CDN endpoint.

DNS requests for the custom domain are routed to the CDN endpoint.

Azure CDN performs validation against the DNS CNAME record when adding the custom domain to ensure domain ownership.

Add the custom domain to the Azure CDN endpoint in the Azure Portal.

The custom domain is associated with the endpoint.

The domain must be associated with the endpoint before HTTPS can be configured for it.

Enable HTTPS on the custom domain, select 'Use my own certificate', and select the Key Vault, secret, and version.

The custom domain is secured with the custom TLS certificate.

This is the final step where Azure CDN retrieves the TLS certificate from Key Vault and deploys it to the edge nodes.

Key Concept

Configuring custom domains and TLS certificates from Azure Key Vault on Azure CDN endpoints.

Question 148Question →

You are configuring a custom domain with HTTPS enabled for an Azure CDN endpoint. You plan to use a CDN-managed certificate to secure the custom domain.

Arrange the steps in the correct order to configure and enable HTTPS for the custom domain on your Azure CDN endpoint.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins with creating the CNAME record, adding the custom domain to the CDN endpoint, enabling HTTPS with CDN-managed certificate, allowing the automated domain validation to complete, and finally waiting for the provisioning and activation status to show Active.

The correct order requires creating the CNAME mapping first, registering the custom domain, enabling HTTPS with CDN-managed configuration, validating domain ownership, and waiting for the final propagation. This ensures that validation succeeds at each step without errors.

Step-by-Step Solution

Create a CNAME record mapping the custom domain to the CDN endpoint.

DNS propagation of the mapping to the endpoint.

Ensures Azure CDN can verify the domain association in the next step.

Add the custom domain to the endpoint in the Azure portal.

The custom domain is registered and associated with the CDN endpoint.

Enables the domain to receive traffic routed through the CDN.

Enable Custom Domain HTTPS and select CDN managed certificate.

The HTTPS configuration workflow is initiated.

Tells Azure CDN to automatically manage the SSL/TLS certificate creation and renewal.

Let Azure CDN validate the domain ownership via CNAME.

Domain ownership is verified.

Necessary security check before issuing a public certificate.

Wait for the certificate to propagate and status to transition to Active.

HTTPS traffic to the custom domain is successfully encrypted.

Completes the SSL binding process across all global edge servers.

Key Concept

Configuring custom domain HTTPS using CDN-managed certificates on Azure CDN endpoints.

Question 149Question →

You are implementing an integration using Azure Event Grid. You have created an Azure Storage account named logstor with a blob container named deadletter to store events that cannot be delivered.

You need to configure a new Event Grid custom topic and an event subscription. The setup must meet the following requirements:
- All events that fail to deliver must be sent to the deadletter container.
- The custom topic must authenticate to the storage account using a system-assigned managed identity.
- No storage account access keys or connection strings can be stored in the configuration.

Which sequence of steps should you perform to configure the custom topic and subscription?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence of steps is to first create the Event Grid custom topic, configure it to use a system-assigned identity, assign the Storage Blob Data Contributor role to the topic's identity at the scope of the storage account, and finally create the event subscription specifying the dead-letter container and selecting the system-assigned identity.

To securely configure dead-lettering using a system-assigned managed identity, the custom topic must be created first to act as the host for the identity. The system-assigned identity is then enabled on the custom topic, which creates its corresponding enterprise application representation in Microsoft Entra ID. Next, this identity must be granted the Storage Blob Data Contributor role on the destination storage account scope to permit writing events. Finally, the event subscription is created, referencing the dead-letter container and designating the system-assigned managed identity for authentication.

Step-by-Step Solution

Create the Event Grid custom topic.

A new custom topic resource is provisioned in Azure.

The custom topic is the parent resource that hosts the managed identity.

Configure the custom topic to use a system-assigned identity.

Azure creates an identity for the custom topic in Microsoft Entra ID.

The identity must exist in Microsoft Entra ID before RBAC roles can be assigned to it.

Assign the Storage Blob Data Contributor role to the custom topic's identity at the scope of the storage account.

The custom topic's managed identity receives write permissions to the blob storage.

Azure Event Grid validates access to the dead-letter container when the event subscription is created.

Create the event subscription on the custom topic, specifying the dead-letter container and selecting the system-assigned identity.

The subscription is successfully created and active.

The subscription is the final resource configured to route events and handle dead-lettering.

Key Concept

Configuring Event Grid dead-lettering with managed identities requires creating the parent resource, establishing its identity, granting appropriate storage roles, and then creating the subscription referencing both the dead-letter destination and the identity.

Question 150Question →

You are developing a telemetry ingestion solution in .NET that uses the Azure.Messaging.EventHubs.Processor library. The application must consume events, manage partition load balancing using Azure Blob Storage, perform checkpointing to prevent processing duplicate messages from the last known state, and shut down gracefully. You need to implement the lifecycle of the EventProcessorClient. In which order should you perform the tasks?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts with initializing the client and storage containers, followed by assigning the event and error delegates, launching the processing thread, checkpointing during active event consumption, and finally stopping processing to release leases.

The correct order ensures that the necessary storage and processor clients are instantiated first. Next, handlers must be assigned before the client starts processing, as starting without handlers throws an exception. Checkpoints are recorded during the processing stage as events are consumed. Finally, stopping the processor releases partition leases and terminates the client lifecycle cleanly.

Step-by-Step Solution

Initialize the EventProcessorClient and BlobContainerClient.

Connections to Azure Event Hubs and the checkpoint store are prepared.

Establishes connection details and links the processor to the Blob Storage container that manages ownership leases and offsets.

The processor is configured with the logic required to handle incoming messages and errors.

The SDK requires both event and error handler delegates to be defined before the client is started, otherwise an InvalidOperationException is thrown.

Start event processing and lease acquisition.

The background thread starts reading events and claiming partition leases.

Invoking StartProcessingAsync initiates partition load balancing and events start flowing to the handler.

Perform checkpoints inside the event processing handler.

The current partition state is persisted to Blob Storage.

Invoking UpdateCheckpointAsync on the event arguments saves progress, allowing the processor to resume from this point in case of failure.

Stop the processor and release partition leases.

Event consumption stops and partition leases are released cleanly.

Invoking StopProcessingAsync ensures that other consumer instances can immediately assume ownership of the partitions without waiting for lease timeouts.

Key Concept

Lifecycle management and checkpointing configuration for the Azure.Messaging.EventHubs EventProcessorClient SDK.

Question 151Question →

You are implementing an event-driven solution that uses Azure Event Grid. You have an Event Grid system topic named `kv-system-topic` associated with an Azure Key Vault instance.

You need to configure an event subscription that routes events to an Azure Service Bus queue. The subscription must meet the following requirements:
- Any undelivered events must be written to a private blob container named `dlq-container` in an Azure Storage account named `saeventgridlogs`.
- The system topic must authenticate to the storage account using its system-assigned managed identity.
- Least privilege access must be enforced.

Which sequence of actions should you perform to configure the identity and create the subscription? Arrange the actions in the correct order.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

Enable the system-assigned managed identity on the system topic, retrieve its principal ID, assign the Storage Blob Data Contributor role to the identity at the storage account scope, and then create the event subscription specifying the Service Bus queue endpoint, the dead-letter blob container, and the system-assigned identity.

To configure an Event Grid subscription with dead-lettering using a system-assigned managed identity, the managed identity must first be enabled on the system topic. Next, the principal ID of that managed identity must be retrieved to allow role assignment. The Storage Blob Data Contributor role must then be assigned to that principal ID at the scope of the destination storage account so that Event Grid has permission to write dead-letter events. Finally, the event subscription can be created referencing the dead-letter container and configuring the dead-letter identity to use the system-assigned identity. Performing these steps in any other order will fail, as Event Grid validates write access to the dead-letter destination at subscription creation time.

Step-by-Step Solution

Enable the system-assigned managed identity on the Event Grid system topic.

A service principal is created in Microsoft Entra ID representing the kv-system-topic.

This establishes the identity that will be granted access to the storage account.

Obtain the principal ID of the newly created managed identity.

The principal ID GUID is retrieved.

The principal ID is required for the subsequent role assignment command.

Assign the Storage Blob Data Contributor role to the principal ID at the scope of the saeventgridlogs storage account.

The managed identity is authorized to write blobs to the storage account.

Event Grid must have write permissions to the storage account to successfully validate and write dead-letter events.

Create the event subscription, configuring the dead-letter destination and setting the dead-letter identity to system-assigned.

The subscription is validated and created successfully.

Since the identity has the correct permissions, Event Grid's validation check passes and the event subscription is established.

Key Concept

Configuring dead-lettering with managed identities in Azure Event Grid subscription creation.

Question 152Question →

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

Drag items to arrange them in the correct order

Show answer & explanation

Answer

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

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

Step-by-Step Solution

Instantiate the client.

An active EventHubProducerClient is initialized with the endpoint details.

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

Create the batch buffer.

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

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

Append events.

The telemetry events are safely loaded into the batch storage.

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

Transmit the batch.

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

SendAsync handles serialization and physical network transit.

Dispose the client.

The underlying AMQP connections are closed.

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

Key Concept

EventHubProducerClient batch publishing pattern using Azure.Messaging.EventHubs SDK

Question 153Question →

You are developing a C# backend application that retrieves product inventory data. You must implement the Cache-Aside data pattern to cache inventory status using an Azure Cache for Redis instance and the StackExchange.Redis SDK. The cache connection must be initialized lazily and thread-safely.

Order the steps to implement the sequence of operations for retrieving product inventory data on a request.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts with initializing the ConnectionMultiplexer using a Lazy thread-safe singleton, querying the cache via StringGetAsync, returning the data immediately if a cache hit occurs, retrieving data from the backend database on a cache miss, writing the data back to the cache asynchronously using StringSetAsync with an expiration time, and finally returning the database-retrieved data to the caller.

The correct order follows the standard implementation of the Cache-Aside data pattern. First, the connection must be established thread-safely (Lazy ConnectionMultiplexer). Next, the application attempts to read from the cache. If the key exists, the cached value is deserialized and returned immediately. If a cache miss occurs, the application queries the persistent SQL database, writes the result to the cache with an expiration time, and returns the data.

Step-by-Step Solution

Initialize the ConnectionMultiplexer thread-safely.

A single connection instance is created lazily.

StackExchange.Redis uses a single ConnectionMultiplexer designed to be shared and reused. Initializing it thread-safely avoids socket exhaustion and race conditions.

Query the Redis cache.

The Redis database is queried for the key.

The Cache-Aside pattern prioritizes checking the fast memory cache first to minimize database load.

Evaluate the cache response.

Data is returned if it is a cache hit.

If the key exists, the cached data is deserialized and returned directly, fulfilling the Cache-Aside pattern.

Fetch from the SQL database on cache miss.

Data is retrieved from the database.

When the cache is empty for the requested key, the application must query the authoritative system of record.

Write the fetched data back to the cache.

The cache is updated with a TTL.

To ensure subsequent reads are served from the cache, the data is written back to Redis with a TTL to prevent stale data.

Return the data to the client.

The fresh database data is returned.

The request is completed with the authoritative database data.

Key Concept

The Cache-Aside pattern caches data on-demand from a data store, improving performance and database scalability while maintaining consistency via TTL.

Question 154Question →

You are developing a background worker application that runs in Azure Container Apps. The application must scale dynamically based on the message count of an Azure Service Bus queue. You plan to use a user-assigned managed identity to authenticate the container app's scale rules with the Service Bus namespace.

Which sequence of steps should you perform to configure the scaling and security?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

Create the user-assigned managed identity, assign the Service Bus Data Receiver role to it, associate the identity with the Container App, and then configure the Service Bus scale rule referencing the identity.

The correct sequence begins with creating the user-assigned managed identity. Next, you must grant it the permissions needed to read from the queue by assigning the Azure Service Bus Data Receiver role. You then associate the identity with the Container App resource. Finally, you configure the azure-servicebus scale rule, referencing the associated identity.

Step-by-Step Solution

Create the user-assigned managed identity.

The identity is provisioned in Azure, generating a unique principal ID and client ID.

You must have a physical identity resource before you can assign roles or link it to other Azure resources.

Assign the Azure Service Bus Data Receiver role to the managed identity at the queue scope.

The identity is granted permissions to read from the target Service Bus queue.

The Container App's scaling mechanism (KEDA) runs on the host environment and uses this identity to authenticate and read the queue depth.

Associate the user-assigned managed identity with the Container App.

The Container App resource definition is updated to include the identity in its identity block.

The Container App must explicitly own or be associated with the user-assigned identity before it can reference it in configuration settings.

Add the azure-servicebus scale rule referencing the associated identity.

The scaling engine uses the associated identity to read queue depth and scale the container instances.

The scale rule configures the actual KEDA scaler, which depends on the identity association and role permissions setup in the preceding steps.

Key Concept

Azure Container Apps scale rules (KEDA) require a managed identity associated with the Container App and granted appropriate permissions on the target resource (like Service Bus) to monitor metrics for autoscaling.

Estimated Time:1m 30s

Question 155Question →

You manage a web application named EduLearn that is currently hosted on a Free ( $F1$ ) App Service plan. During peak hours, the application experiences high CPU utilization and becomes slow. You want to implement an automated scaling solution to handle the load and ensure the application remains responsive, while also preventing autoscale flapping. You plan to configure these settings via the Azure CLI.

How should you order the steps to configure the autoscaling solution?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts with upgrading the App Service plan to Standard (

S1

), creating the autoscale setting container, adding the scale-out rule, and finally adding the scale-in rule.

The correct order requires first scaling up the App Service plan from the Free (

F1

) tier to the Standard (

S1

) tier. Autoscaling is not supported on Free or Shared plans. Once upgraded, you must create the autoscale setting container using `az monitor autoscale create`. Only after the autoscale setting is created can you add specific rules to it. The scale-out rule (CPU >

80\%

) should be added first to define the upper performance boundary, followed by the scale-in rule with a threshold of

30\%

. Setting the scale-in threshold to

30\%

(which is significantly lower than the scale-out threshold of

80\%

) prevents autoscale flapping.

Step-by-Step Solution

Upgrade the hosting plan of the web app to Standard (

S1

The App Service plan is scaled up to a tier that supports custom autoscale settings.

Free (

F1

) and Basic (

B1

) plans do not support automatic scale-out; a Standard (

S1

) or Premium tier is required.

Create the custom autoscale setting container.

An autoscale profile with minimum, maximum, and default capacity is defined for the App Service plan.

Autoscale rules cannot be created without an existing autoscale setting to attach them to.

Define a scale-out rule with a CPU threshold of

80\%

The application scales out by adding instances when under high CPU load.

Establishing the scale-out rule ensures that capacity increases when CPU utilization exceeds the threshold.

Define a scale-in rule with a CPU threshold of

30\%

The application scales in by removing instances when CPU load decreases, without triggering flapping.

Setting the scale-in threshold sufficiently lower than the scale-out threshold prevents the application from repeatedly scaling in and out (flapping).

Key Concept

To configure autoscale on Azure App Service, the App Service plan must be scaled up to a supported tier (Standard or higher) before creating the autoscale setting and defining the scale-out and scale-in rules. To prevent autoscale flapping, the scale-in threshold must be significantly lower than the scale-out threshold.

Question 156Question →

You are managing a CPU-intensive web API named TelemetryProcessor that runs on an Azure App Service Web App. The application is currently hosted on a Shared (D1) App Service plan. During peak hours, the application experiences performance degradation due to CPU spikes. You need to configure the App Service plan to scale out automatically during CPU spikes, ensure the configuration is cost-effective, and prevent autoscale flapping.

Which sequence of steps should you perform to configure the scaling behavior?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To configure autoscaling for the application, first upgrade the App Service plan from the Shared (D1) tier to the Standard (S1) tier. Then, enable autoscale and configure the instance capacity limits. Next, add a scale-out rule that increases the instance count when the CPU Percentage metric exceeds 80%. Finally, add a scale-in rule that decreases the instance count when the CPU Percentage metric falls below 40% to prevent flapping.

The correct sequence ensures that you first scale up the plan to a tier that supports autoscaling, initialize the autoscale setting container, establish the scale-out rule to manage high utilization, and finally establish the scale-in rule with a safe threshold to prevent resource flapping.

Step-by-Step Solution

Upgrade the App Service plan from the Shared (D1) tier to the Standard (S1) tier.

The App Service plan is moved to a tier that supports scaling out and autoscale configurations.

The Shared (D1) tier has shared infrastructure and cannot scale out. Upgrading to the Standard (S1) tier is required to support autoscaling.

Enable autoscale on the App Service plan and define the minimum, maximum, and default instance capacity limits.

An autoscale profile is created with the specified instance boundaries.

You must establish the autoscale setting container and its capacity boundaries before adding individual metric-based rules.

Configure a scale-out rule that increases the instance count by 1 when the CPU Percentage metric exceeds 80%.

A metric-based trigger is added to increase resources during high-traffic CPU spikes.

This rule targets the CPU spikes and adds instances to distribute the load during peak utilization.

Configure a scale-in rule that decreases the instance count by 1 when the CPU Percentage metric falls below 40%.

A metric-based trigger is added to scale back down when load decreases, using a safe threshold to prevent immediate rescaling.

To prevent autoscale flapping, the scale-in threshold must be set to a level where the remaining instances can absorb the redistributed load without immediately violating the scale-out rule. A threshold of 40% is safe when scaling out at 80%.

Key Concept

Autoscaling in Azure App Service requires a supported pricing tier (Standard or higher). Once upgraded, the autoscale setting must be created to define capacity boundaries, followed by scale-out rules for performance and scale-in rules with a proper buffer threshold to prevent autoscale flapping.

Estimated Time:2m 0s

Question 157Question →

You are developing a C# (.NET Isolated process) Durable Function to transcode and analyze video files. The workflow implements a Fan-out/Fan-in pattern: it first calls a transcoding activity, then launches parallel analysis activities on the transcoded video, and finally aggregates the results.

To ensure the durability of the execution, the Durable Functions runtime uses event sourcing and replays the orchestrator function.

You need to sequence the lifecycle and replay steps of this workflow from the initial client request to the completion of the orchestration.

In which order do these events occur during the execution of this workflow?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order of events starts with the client launching the orchestration, followed by the orchestrator initiating execution and yielding at the transcoding task. Once completed, the orchestrator replays to resolve the transcoding result and then invokes the parallel analysis activities, yielding on their concurrent execution. Finally, after all analysis tasks finish, the orchestrator replays a last time to retrieve their values, runs the aggregation activity, and finishes.

The execution begins with the client starting the orchestration. The orchestrator runs and yields at the first await (transcoding). After the transcode completes, the orchestrator replays the function, retrieves the transcoding result from history, runs the parallel tasks, and yields again. Once the parallel tasks complete, the orchestrator replays to obtain all analysis results, runs the final aggregation activity, and completes.

Step-by-Step Solution

Trigger the orchestration.

An orchestration instance is created and a status response is returned.

The client function initiates the orchestration lifecycle using the Durable Task client.

Execute the orchestrator up to the first await point.

The transcoding activity is scheduled and the orchestrator yields.

The orchestrator executes sequentially until it encounters an await on an asynchronous activity task.

Replay the orchestrator after the transcode completes.

The transcoding result is read from the execution history.

Durable Functions use event sourcing; the orchestrator replays from the start to reconstruct its state.

Schedule parallel tasks and yield.

Parallel activities are scheduled, and the orchestrator yields on Task.WhenAll.

For the Fan-out pattern, multiple tasks are scheduled concurrently and awaited together.

Replay and complete the orchestration.

The aggregation activity runs and the orchestrator completes.

After all parallel tasks finish, the orchestrator replays one last time, processes the aggregated data, and completes.

Key Concept

Durable Functions Orchestrator Replay and Execution Lifecycle

Question 158Question →

You are developing a C# background service that must safely update the content of an existing blob named config.json in Azure Blob Storage. To prevent concurrency conflicts, your service must lock the blob using a lease before performing the upload and release the lease immediately afterward. You are using the Azure.Storage.Blobs (v12) SDK.

Order the steps required to implement this lease-based upload workflow.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order of operations is to first create the BlobClient, then instantiate the BlobLeaseClient, acquire the lease, upload the blob content with the lease ID included in the request conditions, and finally release the lease.

To safely modify a leased blob, you must establish client references, acquire the lock to obtain a lease ID, supply that lease ID with the upload request, and release the lock when the operation is complete.

Step-by-Step Solution

Instantiate the BlobClient client.

A BlobClient object representing config.json is created.

This object is the starting point for interacting with the blob.

Instantiate the BlobLeaseClient client.

A BlobLeaseClient object linked to the BlobClient is created.

The lease client manages all lock-related actions on that blob.

Acquire the lease.

A Lease object is returned containing the unique LeaseId.

This locks the blob against unauthorized updates.

Upload content with the lease ID.

The blob is updated with the new content.

Passing the lease ID in the request conditions authorizes the update.

Release the lease.

The lease is removed from the blob.

Releasing the lease unlocks the blob for subsequent operations.

Key Concept

Lease management workflow in Azure Storage Blobs C# SDK

Estimated Time:1m 30s

Question 159Question →

A smart home IoT solution uses Azure Service Bus to route command messages to individual smart devices. The commands for each device must be processed in the exact order they are received to prevent state conflicts. You are configuring a .NET application using the Azure.Messaging.ServiceBus SDK to process these command messages for one device session at a time, settle the processed messages, and release the session so that other workers can pick up different device sessions.

In which order should you execute the code steps to achieve this?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct logical order is: first, instantiate the client; second, accept the next available session; third, receive the message; fourth, complete the message; and fifth, close the session receiver.

Establishing a connection via the client is a prerequisite for creating any receiver. For sessionful entities, a session receiver must be obtained using the client to lock the session before messages can be received. After receiving and processing a message, it must be completed before the session lock is released by closing the receiver.

Step-by-Step Solution

Create the ServiceBusClient using the namespace connection string.

An active ServiceBusClient instance is initialized.

The client is the primary object used to communicate with the Service Bus service and must be created first.

Request a session-specific receiver by calling AcceptNextSessionAsync.

A ServiceBusSessionReceiver instance is obtained and the next available session is locked.

To consume messages from a session-enabled queue, a receiver must bind to and lock a specific session ID.

Receive a message by calling ReceiveMessageAsync.

A ServiceBusReceivedMessage object representing the next message in the session is returned.

Messages can only be fetched from the queue once a session-specific receiver has successfully locked the session.

Settle the message by calling CompleteMessageAsync.

The message is permanently deleted from the queue.

The message must be completed to confirm successful processing and prevent it from being reprocessed.

Release the session by calling CloseAsync on the receiver.

The session lock is released, and the receiver resources are cleaned up.

Closing the session receiver is necessary to release the exclusive lock on the session ID, allowing other instances of the worker to process messages for this session.

Key Concept

Session-based message processing and lifecycle management using the Azure Service Bus SDK.

Question 160Question →

A C# financial auditing application needs to update the custom metadata on an existing block blob containing a transaction ledger. To prevent concurrent write operations from other clients, the application must implement lease-controlled metadata updates using the Azure SDK for .NET. Which of the following sequences represents the correct order of steps the application must execute to perform this update securely?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order of operations begins with instantiating a `BlobClient` to reference the target blob. Next, a `BlobLeaseClient` is created and `AcquireAsync` is invoked to secure a lease. Once the lease is acquired, `GetPropertiesAsync` is called with the lease ID in the request conditions to read the current state. Afterward, `SetMetadataAsync` is executed with the updated metadata and the lease ID in the request conditions. Finally, the lease is released using `ReleaseAsync` on the lease client.

The correct order requires establishing the client connection first, obtaining a write lock (lease) to ensure concurrency control, fetching the current properties under that lease, applying the metadata change using the lease ID, and finally releasing the lease so others can access the blob.

Step-by-Step Solution

Instantiate a `BlobClient` object.

Establishes a connection to the target blob resource in Azure Storage.

All subsequent operations, including lease acquisition and metadata updates, require a reference to the target blob.

Create a `BlobLeaseClient` and call `AcquireAsync`.

Obtains a unique lease ID and places a write lock on the blob.

The lease must be acquired before reading the current state or applying updates to prevent race conditions.

Call `GetPropertiesAsync` passing the lease ID.

Retrieves the current metadata and properties of the leased blob.

Accessing the blob's properties requires passing the lease ID in `BlobRequestConditions` since the blob is now locked.

Call `SetMetadataAsync` passing the updated metadata and the lease ID.

Updates the custom metadata on the block blob.

Writing metadata to a leased blob requires the active lease ID in the `BlobRequestConditions` to authorize the modification.

Call `ReleaseAsync` on the lease client.

Releases the write lock on the blob.

Releasing the lease allows other instances of the application or other clients to obtain a lease and make modifications.

Key Concept

Lease-controlled blob operations in Azure Blob Storage using the .NET SDK.

Estimated Time:2m 0s

PreviousPage 8 / 9Next

All practice questions

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept