Examkin

All practice questions

171 questions

All types972Multiple choice497Multiple select269Matching9Ordering171Fill in the blank26
Question 101Question →

You are preparing to deploy a secure backend microservice to Azure Container Apps. The container image for the microservice is stored in a private Azure Container Registry (ACR). You must configure the Container App to pull the image from the private ACR using a user-assigned managed identity. Which four actions should you perform in sequence? To answer, arrange the actions in the correct order.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence of actions is: 1) Create a user-assigned managed identity in Azure Active Directory / Microsoft Entra ID; 2) Assign the AcrPull role to the user-assigned managed identity at the scope of the Azure Container Registry; 3) Create an Azure Container Apps environment; 4) Deploy the Container App, configuring it to use the user-assigned managed identity for registry authentication.
The correct sequence begins by creating the user-assigned managed identity so that its identity credentials exist in Azure. Next, the AcrPull role must be assigned to this identity on the Azure Container Registry to authorize image retrieval. After ensuring the Azure Container Apps environment is created, the Container App can be deployed using the managed identity configuration to authenticate with the registry and pull the image.

Step-by-Step Solution

1
Create a user-assigned managed identity.
The identity is provisioned with a unique principal ID and resource ID.
The identity must exist first so its credentials can be authorized on the registry and referenced during the Container App deployment.
2
Assign the AcrPull role to the managed identity.
The identity has read permissions to pull images from the registry.
Azure Container Apps requires the AcrPull role to authenticate with the private registry.
3
Create an Azure Container Apps environment.
The environment hosting container apps is provisioned.
An environment must exist before any Container Apps can be created inside it.
4
Deploy the Container App.
The Container App is running with the pulled image.
The final step configures the Container App to use the user-assigned identity for pulling the container image from the private ACR.

Key Concept

Deploying Azure Container Apps with Private Registry Authentication using Managed Identities
Question 102Question →

You are developing a serverless workflow using Azure Durable Functions. You need to sequence the execution and replay steps of a basic orchestration that starts, runs a single activity function, and completes. Move the events to the correct order in which they occur during this execution lifecycle.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order of events is: client function initiates the orchestrator instance, the orchestrator executes and schedules the activity function, the orchestrator yields control and suspends execution, the activity function executes and stores its result, and the orchestrator replays history to restore state and continue.
The correct order follows the standard Durable Functions event sourcing replay pattern: the client initiates the orchestrator; the orchestrator executes, schedules the activity, and yields control; the activity executes on a worker; and finally, the orchestrator wakes up, replays history, and continues execution with the activity result.

Step-by-Step Solution

1
Initiate the orchestration instance.
The client function calls StartNewAsync, placing a start message in the control queue.
Durable Functions orchestrations must be started by a client function using the client binding.
2
Execute the orchestrator and schedule the activity.
The orchestrator begins execution and runs until the await statement, scheduling the activity in the work-item queue.
The orchestrator runs single-threaded code up to the first asynchronous operation, creating execution history.
3
Yield and sleep the orchestrator.
The orchestrator yields control, writes its state to the storage table, and goes to sleep.
Durable Functions optimize resource usage by not keeping orchestrators active while waiting for activities to complete.
4
Execute the activity function.
A worker picks up the activity, executes it, and writes the output back to the history storage.
Activities run separately from the orchestrator, and their output must be persisted to allow the orchestrator to rebuild state.
5
Wake up and replay the orchestrator.
The orchestrator is re-enqueued, restarts execution from the beginning, and uses history to reconstruct state and skip re-executing the completed activity.
The orchestrator relies on event sourcing (replay) to ensure determinism and recover local variables/state without repeating activities.

Key Concept

The execution replay lifecycle of Durable Functions ensures state persistence and scalability by suspending and reconstructing the orchestrator state from execution history.
Question 103Question →

You are implementing an Azure Event Grid solution. You need to configure dead-lettering for an Event Grid subscription that routes events from a custom topic to an Azure Queue Storage queue. The dead-lettered events must be securely stored in an Azure Blob Storage container using a system-assigned managed identity.

Which four actions should you perform in sequence to configure and test this dead-lettering solution? To answer, arrange the actions in the correct order.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To configure dead-lettering with a system-assigned managed identity, you must first create the Azure Storage account and Blob Storage container. Next, assign the Storage Blob Data Contributor role to the Event Grid system-assigned managed identity on the Storage account. Then, create the Event Grid subscription, specifying the Queue Storage queue as the endpoint and configuring the Blob container for dead-lettering. Finally, test the configuration by publishing events that fail delivery to verify they are dead-lettered.
The correct sequence starts with creating the Storage account and Blob container. Next, permissions must be configured by assigning the Storage Blob Data Contributor role to the Event Grid system-assigned managed identity on the Storage account, which allows Event Grid to write the dead-lettered events. After permissions are established, you create the Event Grid subscription, specifying the Queue Storage queue as the endpoint and configuring the dead-letter destination. Finally, you publish test events that fail delivery to verify that they are correctly written to the Blob container.

Step-by-Step Solution

1
Create the target Storage account and Blob container.
The destination storage resources are provisioned.
The dead-letter container must exist before permissions can be granted or the configuration is applied.
2
Assign the Storage Blob Data Contributor role to the Event Grid system-assigned managed identity on the Storage account.
Event Grid is authorized to write blobs to the storage account.
Event Grid requires write permissions to the storage account to upload dead-lettered events. Without this step, subscription creation will fail validation.
3
Create the Event Grid subscription and define both the endpoint and dead-letter settings.
The Event Grid subscription is created and active.
The subscription links the custom topic to the Queue Storage queue and references the Blob container for dead-lettering.
4
Publish events designed to fail delivery (e.g., targeting a non-existent handler or exceeding retry limits).
The failed events appear in the Blob Storage container.
This verifies that the entire pipeline, including routing and security configuration, works correctly.

Key Concept

Configuring dead-lettering with managed identity authorization in Azure Event Grid subscriptions.
Question 104Question →

You need to update a specific metadata tag on an existing Azure Blob Storage blob using the Azure.Storage.Blobs SDK (v12) for C# while ensuring that all other existing metadata key-value pairs on the blob are preserved. Which sequence of steps should you perform?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To update a specific metadata key on a blob while preserving existing metadata using the Azure.Storage.Blobs SDK (v12) for C#, you must first instantiate a BlobClient, call GetPropertiesAsync() to retrieve the current Metadata dictionary, modify or add the key-value pairs in memory, and then call SetMetadataAsync() with the updated dictionary.
The correct order requires first initializing the BlobClient to communicate with the service, then calling GetPropertiesAsync() to fetch the existing metadata so it is not lost. Next, the metadata dictionary is modified in memory, and finally, SetMetadataAsync() is called to upload the entire updated dictionary.

Step-by-Step Solution

1
Instantiate BlobClient
A client object targeting the specific blob is created.
All SDK operations on the blob require a configured client instance.
2
Call GetPropertiesAsync()
The current blob properties, including the existing metadata dictionary, are retrieved.
Since the SDK's metadata update operation is a full overwrite, you must retrieve existing values first to avoid losing them.
3
Modify the metadata dictionary
The target key-value pairs are added or updated in the dictionary in memory.
Modifying the dictionary in memory prepares the complete payload for the update. Keys do not need the HTTP prefix.
4
Call SetMetadataAsync()
The updated metadata dictionary is sent to Azure Storage and applied to the blob.
This persists the updated collection of metadata on the blob.

Key Concept

Preserving metadata during updates with Azure.Storage.Blobs SDK
Question 105Question →

You have a private Azure Blob Storage account named `storeorigin` containing static web assets in a container named `images`. You deploy an Azure CDN Standard from Microsoft endpoint to deliver these assets. You must configure the solution so that the CDN endpoint can retrieve the assets using a Shared Access Signature (SAS) token, while ensuring clients can access the assets using clean URLs that do not expose the SAS token. Which sequence of actions should you perform?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To configure Azure CDN with a private Blob Storage origin, you must first generate a SAS token for the storage container. Next, modify the CDN endpoint's Origin path to append the container name and the SAS token. Follow this by setting the query string caching behavior to ignore query strings, which allows clients to bypass sending the token. Finally, purge the CDN endpoint to apply the changes.
The correct sequence begins with securing origin access by generating a SAS token for the private container. This token must then be configured on the CDN side via the Origin path so that the CDN can authenticate requests to the backend. To hide the SAS token from the end users, the query string caching policy is set to ignore query strings, ensuring that clean client URLs are cached and mapped to the backend requests that include the Origin path token. A cache purge is the final step to make the configuration immediately effective.

Step-by-Step Solution

1
Generate a SAS token for the container.
A SAS token is created that authorizes read access to the private blob assets.
The CDN needs authentication to access private blob storage.
2
Configure the CDN endpoint Origin path.
The Origin path is configured as '/{container_name}?{sas_token}'.
This automatically appends the SAS credentials to all origin requests initiated by the CDN.
3
Configure query string caching to 'Ignore query strings'.
The CDN caches files based on the file path alone and does not pass client query strings to the origin.
This allows clients to request files using clean URLs without containing the SAS token.
4
Purge the CDN cache.
The cached content is invalidated on all edge nodes.
Ensures that old, unauthenticated request errors or outdated cache results are removed.

Key Concept

Integrating Azure CDN with private storage origins using Shared Access Signature (SAS) tokens and query string caching behavior configurations.
Question 106Question →

You are developing an integration solution that uses Azure Event Grid to route custom events to a Webhook endpoint. To secure the webhook, you must implement Microsoft Entra ID authentication so that the Webhook only accepts authorized requests from Event Grid. You need to configure the authentication and the subscription.

Which sequence of steps should you perform to complete the configuration?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence of steps is: Register a new application in Microsoft Entra ID to represent the webhook endpoint, define an application role within the registered webhook application, grant the Azure Event Grid Service Principal the defined application role on the webhook application, and finally create the Event Grid subscription, specifying the webhook endpoint and configuring the Microsoft Entra ID authentication details.
To secure an Event Grid Webhook using Microsoft Entra ID, you must register the Webhook application first to establish its identity. Next, you define an application role inside the registration. You then grant the Azure Event Grid Service Principal this role. Finally, you create the subscription using the Webhook's Entra ID application details. This order ensures that the validation handshake succeeds because Event Grid is already authorized to call the endpoint.

Step-by-Step Solution

1
Register the webhook application in Microsoft Entra ID.
An application registration is created with a unique Application (Client) ID.
This establishes the identity of the webhook endpoint in the Microsoft Entra ID tenant.
2
Expose an application role in the webhook application registration.
An authorized role (e.g., AzureEventGridSecureWebhookSubscriber) is defined.
The role must exist before it can be assigned to the caller service principal.
3
Assign the defined application role to the Azure Event Grid Service Principal.
Event Grid is granted permission to call the secure webhook endpoint.
The service must have permission to call the endpoint to complete the upcoming validation handshake.
4
Create the Event Grid subscription with Entra ID endpoint authentication properties.
The event subscription is created, and the validation handshake completes successfully.
This is the final step where Event Grid validates the webhook endpoint using the authorized identity context.

Key Concept

Microsoft Entra ID secured webhook endpoints in Azure Event Grid
Question 107Question →

You need to download the diagnostic log files from a Windows-based Azure App Service named `contoso-web` by using the Kudu REST API. You want to retrieve all log files compiled into a single compressed ZIP file.

Arrange the actions in the correct order to configure the request, authenticate, and download the logs.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

Retrieve the deployment credentials, construct the SCM endpoint URL targeting the zip API, execute the authenticated HTTP GET request, and extract the downloaded ZIP file.
To download logs using the Kudu API, you must first obtain valid publishing credentials to satisfy authentication requirements. Then, you construct the endpoint URL using the app's SCM site name and the `/api/zip/LogFiles/` directory path. Next, you send the authenticated GET request to receive the compressed log archive. Finally, you extract the ZIP locally to view the logs.

Step-by-Step Solution

1
Obtain the deployment credentials from the Azure portal or CLI.
You have the publishing username and password required for Kudu authentication.
The Kudu REST API endpoint is secured and requires authentication.
2
Formulate the URL using the format: `https://contoso-web.scm.azurewebsites.net/api/zip/LogFiles/`.
You have the target URL pointing to the LogFiles zip API.
The SCM endpoint is separate from the production site and hosts the Kudu service tools.
3
Make an HTTP GET request to the URL using the publishing credentials in the Authorization header.
The server returns a binary stream representing the zipped LogFiles directory.
This initiates the download process from the Azure server.
4
Save the binary stream to a local file and extract its contents.
You have access to files like web server logs, application logs, and detailed errors locally.
Extracting the ZIP is required to read the text-based log files directly.

Key Concept

Accessing App Service diagnostic logs via the Kudu (SCM) REST API zip endpoint.
Question 108Question →

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

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

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

Drag items to arrange them in the correct order

Show answer & explanation

Answer

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

Step-by-Step Solution

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

Key Concept

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

You are developing a logistics monitoring solution in C# that tracks cargo container shipments. The container data is stored in Azure Cosmos DB. You need to write a method using the Azure Cosmos DB .NET SDK v3 that configures the connection, accesses the database and container, and performs a point read of a shipment item. In which order should you execute the steps to initialize the client and perform the point read?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To perform a point read using the Azure Cosmos DB .NET SDK v3, you must first create and configure the CosmosClientOptions, instantiate the CosmosClient with those options, obtain a Database reference, obtain a Container reference, and finally call ReadItemAsync on the container specifying the item ID and its partition key.
The correct sequence begins with configuring CosmosClientOptions. Next, you instantiate the CosmosClient passing these options. Once the client is active, you navigate down the resource hierarchy by first retrieving the Database object via GetDatabase and then the Container object via GetContainer. Finally, you execute the point read on the Container object using ReadItemAsync with the item ID and partition key.

Step-by-Step Solution

1
Configure client options.
A CosmosClientOptions object is initialized with configurations like preferred regions.
This object is required during the client initialization step if custom settings are needed.
2
Instantiate the CosmosClient.
A thread-safe CosmosClient instance is created to manage connection pooling.
The client is the root object used to interact with the Azure Cosmos DB service.
3
Obtain Database reference.
A Database object is returned.
You must reference the database containing the target container.
4
Obtain Container reference.
A Container object is returned.
Item operations are executed against a specific container, so a container reference is necessary.
5
Perform the point read.
An ItemResponse is returned containing the deserialized shipment item.
ReadItemAsync executes the point read, which requires the item ID and the partition key.

Key Concept

Initializing the Cosmos DB SDK v3 client hierarchy and executing point reads with the Container class.
Question 110Question →

You need to import an Azure Function App as a new API in an existing Azure API Management (APIM) instance using the Azure portal. In which order should you perform the configuration steps?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

First, navigate to the API Management instance in the Azure portal and open the APIs section. Second, click Add API and choose Function App. Third, browse and select the Function App along with the specific functions. Fourth, configure the API URL suffix and click Create.
The correct sequence begins by navigating to the API Management service in the portal and opening the APIs blade. You then select Add API and choose Function App to configure the integration. Next, you browse and select the specific Function App and its functions. Finally, you set the URL suffix and display name, and click Create to complete the import.

Step-by-Step Solution

1
Open the API Management instance in the Azure portal and click APIs.
Displays the API management workspace.
Before configuring or importing an API, you must navigate to the specific API Management service instance where the API will reside.
2
Select Add API and click Function App.
Initiates the import workflow specifically for Azure Functions.
Choosing the correct resource type tells APIM to read from Azure Function App configurations.
3
Browse for the target Function App and select its functions.
Selects the source functions to be exposed as API operations.
You must map specific backend function endpoints to API operations in APIM.
4
Set the URL suffix and click Create.
Completes the import and publishes the API.
Configuring the URL suffix ensures unique routing for the API within the APIM gateway before creation.

Key Concept

Importing and configuring Azure Functions as APIs in Azure API Management
Question 111Question →

You are implementing an Azure Durable Functions workflow in C# to handle a human approval process with a 2424-hour escalation timeout. Order the steps in the sequence they occur during a successful execution where a manager approves the request within the 2424-hour window.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence of events is: the orchestrator sets up the timer and event listener tasks, yields execution using Task.WhenAny to persist state, receives the external event raised by the client function, wakes up to replay history and cancel the timer, and finally executes the activity to process the decision.
The correct sequence begins with the orchestrator defining the approval notification and wait tasks. Next, it yields control by awaiting Task.WhenAny, which saves state. A client function then raises the event using the orchestration client. The orchestrator wakes up, replays state to recognize the event completion, cancels the timer, and finally executes the final approval activity.

Step-by-Step Solution

1
Identify the initialization step of the Human Interaction pattern in the orchestrator.
The orchestrator initiates tasks for both the event listener (WaitForExternalEvent) and the escalation timer (CreateTimer).
Both tasks must be defined before the orchestrator can wait on them.
2
Identify how the orchestrator pauses execution while waiting for either event to complete.
The orchestrator awaits Task.WhenAny on the timer and event tasks, yielding control and saving state.
Awaiting Task.WhenAny prevents active blocking and ensures the current state is saved to storage.
3
Determine the mechanism by which the orchestrator is notified of user approval.
An external client function calls RaiseEventAsync with the decision.
Since the orchestrator is asleep, an external process must push the event to resume execution.
4
Analyze the behavior of the orchestrator upon receiving the event.
The orchestrator wakes up, replays its history to restore state, evaluates the completed event, and cancels the timer.
Replaying history ensures the orchestrator rebuilds state deterministically, and canceling the timer avoids unnecessary escalation.
5
Determine the final step in the workflow.
The orchestrator executes the activity to process the decision and completes.
The workflow logic is finished once the final processing activity completes.

Key Concept

Orchestrating human interaction patterns and managing state lifecycle in Azure Durable Functions
Estimated Time:1m 30s
Question 112Question →

You are deploying an Azure Container App named `payment-processor` that needs to securely access a database connection string stored in an Azure Key Vault named `kv-vault`.

You want the Container App to authenticate to the Key Vault using a system-assigned managed identity and expose the secret to the application container as an environment variable named `DB_CONNECTION`.

Which four actions should you perform in sequence? To answer, move the appropriate actions from the list of actions to the answer area and arrange them in the correct order.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

First, enable a system-assigned managed identity on the `payment-processor` Container App. Second, in the Azure Key Vault `kv-vault`, assign the Key Vault Secrets User role to the Container App's managed identity principal. Third, add a secret named `db-secret` to the Container App that references the Azure Key Vault secret URI. Fourth, update the container configuration of the Container App to map the environment variable `DB_CONNECTION` to the `db-secret` secret.
To secure secrets in an Azure Container App using Key Vault, the application must first have an identity. Enabling the system-assigned managed identity creates a principal in Microsoft Entra ID. Next, this identity must be granted the Key Vault Secrets User role so that the Container App is authorized to read the secret. Once authorized, the secret is mapped at the Container App resource level using the Key Vault secret URI. Finally, the container template within the Container App references this App-level secret to expose it as an environment variable to the application code.

Step-by-Step Solution

1
Enable the system-assigned managed identity on the Container App.
A service principal representing the Container App is created in Microsoft Entra ID.
An identity must exist before you can assign roles or permissions to it.
2
Assign the Key Vault Secrets User role to the system-assigned managed identity on the Key Vault.
The identity principal is granted permission to read secret values.
The Container App environment must be authorized to pull secret values from Key Vault at runtime.
3
Create a secret at the Container App level that references the Key Vault secret URI.
A secret reference is registered in the Container App environment.
Container Apps act as the secure store that bridges the Key Vault secret and the application container.
4
Map the Container App secret to the container's environment variable.
The container configuration is updated with the environment variable definition.
This injects the decrypted secret value into the container's environment space.

Key Concept

Configuring Key Vault Secret References in Azure Container Apps using Managed Identities

Alternative Method

You can also perform this configuration using a Bicep template by defining the identity block, setting up the Microsoft.Authorization/roleAssignments resource, defining the secrets array in the container app resource, and referencing the secret in the env block of the container definition.
Estimated Time:2m 0s
Question 113Question →

You need to secure static content delivered via an Azure CDN endpoint by configuring a custom domain named `media.contoso.com` with HTTPS. You want to use a free certificate managed by Azure CDN. Which sequence of actions must you perform to configure the custom domain and enable HTTPS? Arrange the steps in the correct order.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To configure and secure a custom domain with an Azure CDN-managed certificate, you must first create a DNS CNAME record mapping the custom domain to your CDN endpoint hostname. Then, add the custom domain to the CDN endpoint in the Azure portal. Next, enable HTTPS on the custom domain, select CDN-managed certificate type, and save the settings. Finally, wait for the domain validation, certificate provisioning, and global propagation steps to complete.
The correct sequence begins with establishing the DNS CNAME record so that Azure CDN's domain ownership validation succeeds when adding the custom domain. After adding the domain, HTTPS can be enabled. Setting the certificate management type to CDN-managed allows Azure to handle the certificate lifecycle. The final phase involves waiting for the automated validation, certificate issuance, and edge replication to complete.

Step-by-Step Solution

1
Create a DNS CNAME record.
The custom domain points to the CDN endpoint hostname.
Azure CDN requires the CNAME record to exist to validate domain ownership when adding the custom domain, preventing unauthorized domain associations.
2
Add the custom domain to the CDN endpoint in the Azure Portal.
The custom domain is registered with the CDN endpoint.
Enabling HTTPS requires the custom domain to be linked to the endpoint first.
3
Enable the HTTPS feature on the custom domain.
The HTTPS configuration panel is opened.
This begins the security provisioning process for the domain.
4
Select the CDN-managed certificate management type.
Azure CDN is authorized to request and manage the SSL certificate.
Allows Azure CDN to handle the certificate lifecycle without user intervention.
5
Wait for validation, provisioning, and propagation.
The HTTPS status transitions to Enabled and traffic is secured.
DNS propagation and certificate deployment across edge POPs takes time to complete.

Key Concept

Configuring custom domains and enabling CDN-managed HTTPS on Azure CDN endpoints.
Estimated Time:2m 0s
Question 114Question →

You are developing a solution that routes resource group lifecycle events to an Azure Storage Queue. The storage account is secured, and public access is restricted. You need to configure Azure Event Grid to deliver these events securely using a user-assigned managed identity. Which sequence of steps should you perform to complete the configuration? To answer, arrange all actions from the list of actions in the correct order.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To configure secure Event Grid delivery to an Azure Storage Queue using a user-assigned managed identity, you must first create the identity, associate it with the Event Grid system topic, grant it the Storage Queue Data Message Sender role on the queue, and then create the event subscription specifying the queue endpoint and the identity for delivery.
First, the user-assigned managed identity must be created in Microsoft Entra ID. Next, this identity must be associated with the Event Grid system topic so that the topic can leverage it. Then, the identity must be granted the Storage Queue Data Message Sender role at the scope of the target storage queue to allow message writing. Finally, the event subscription can be created, referencing the target queue as the endpoint and using the user-assigned managed identity for delivery.

Step-by-Step Solution

1
Create the user-assigned managed identity
A standalone user-assigned managed identity resource is created in Microsoft Entra ID.
The identity must exist before it can be assigned permissions or associated with other Azure resources.
2
Associate with system topic
The Event Grid system topic is configured with the user-assigned managed identity.
Azure Event Grid requires the identity to be associated with the topic from which the event subscription is created.
3
Assign RBAC role
The identity is granted the Storage Queue Data Message Sender role on the target queue.
Event Grid must have authorization to write to the queue, and the minimum privilege role for this action is Storage Queue Data Message Sender.
4
Create the subscription
The event subscription is created and successfully validated.
During creation, Event Grid validates that the endpoint is reachable and that the configured identity has the necessary permissions to write to it.

Key Concept

Configuring managed identities for Event Grid delivery
Question 115Question →

An Azure integration workflow must modify the metadata of a blob while preventing write conflicts. Using the .NET SDK (`Azure.Storage.Blobs`), write operations to the blob must be temporarily locked.

Order the steps required to programmatically lock the blob, apply the metadata changes, and release the lock.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins by instantiating a lease client using GetBlobLeaseClient, followed by acquiring the lease using AcquireAsync. Next, SetMetadataAsync is invoked on the BlobClient with the acquired lease ID supplied within BlobRequestConditions, and finally, the lease is freed by calling ReleaseAsync on the lease client.
To modify a blob safely under a concurrency lock, a client must first obtain a BlobLeaseClient to coordinate lease actions. Second, the lease must be explicitly acquired to retrieve the lease ID. Third, the metadata update is committed using the lease ID inside BlobRequestConditions. Finally, the lease must be released to clean up the lock and make the blob available to other clients.

Step-by-Step Solution

1
Instantiate the lease client.
A BlobLeaseClient object bound to the target BlobClient is created.
The Azure SDK structures lease operations under a specialized lease client rather than the main blob client.
2
Acquire the lease.
The blob is locked for write operations, and a unique lease ID is returned.
Acquiring the lease establishes the lock and generates the identifier required for subsequent modifications.
3
Apply the metadata with the lease ID.
The metadata is successfully updated on the blob.
Passing the lease ID in BlobRequestConditions ensures the write operation is permitted on the leased blob.
4
Release the lease.
The lease lock is removed, returning the blob to an unlocked state.
Releasing the lease promptly allows other processes to interact with the blob without waiting for the lease duration to expire.

Key Concept

Acquiring, using, and releasing a lease during blob metadata modifications to prevent concurrency issues using the Azure Storage SDK.
Question 116Question →

You are developing a .NET application using the Azure Cosmos DB .NET SDK v3. The application must process changes from a source container using the Change Feed Processor and send real-time notifications. You need to configure and start the Change Feed Processor. How should you sequence the steps to initialize, configure, and start the Change Feed Processor?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To initialize the Change Feed Processor using the .NET SDK v3, you must first define the delegate that will handle the changes, retrieve the Container references for the monitored and lease containers, invoke GetChangeFeedProcessorBuilder on the monitored container, configure the builder with the lease container and instance name, and finally build and start the processor asynchronously.
The correct sequence begins by defining the change processing delegate and acquiring the required Container SDK instances. You then initialize the builder using the source container, configure the leases and host identity using fluent methods on the builder, and complete the process by invoking Build and starting the processor.

Step-by-Step Solution

1
Define the delegate.
The delegate that processes document changes is declared.
The delegate is a required parameter for the builder factory method.
2
Get container references.
Container objects for both source and lease containers are obtained.
The monitored container starts the builder, and the lease container is passed during configuration.
3
Initialize the builder.
A ChangeFeedProcessorBuilder instance is created.
Calling GetChangeFeedProcessorBuilder on the source container begins the builder pattern.
4
Configure parameters.
The builder is configured with lease and instance parameters.
The Change Feed Processor requires a lease container to track state and an instance name to scale out across hosts.
5
Build and start the processor.
The ChangeFeedProcessor is instantiated and starts listening.
Build creates the processor object, and StartAsync begins reading notifications.

Key Concept

The initialization sequence of the Azure Cosmos DB Change Feed Processor requires setting up dependencies (delegate, containers) before configuring the builder and starting the background reader.
Question 117Question →

You are developing a C# console application to process customer support tickets from an Azure Service Bus queue named `support-tickets`. You need to retrieve a single message from the queue, process it, and remove it from the queue using the `Azure.Messaging.ServiceBus` SDK.

Arrange the steps in the correct order to implement this logic.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

First, instantiate a ServiceBusClient. Second, call CreateReceiver on the client. Third, call ReceiveMessageAsync on the receiver. Finally, call CompleteMessageAsync on the receiver.
The correct sequence begins with establishing the connection via the ServiceBusClient. From there, a ServiceBusReceiver is created for the specific queue. You then retrieve the message using ReceiveMessageAsync, and after processing, settle the message by calling CompleteMessageAsync to remove it from the queue.

Step-by-Step Solution

1
Instantiate a ServiceBusClient using the namespace connection string.
A connection to the Service Bus namespace is initialized.
The client is the entry point for interacting with all Service Bus entities in the namespace.
2
Call client.CreateReceiver("support-tickets") to create a receiver.
A ServiceBusReceiver instance scoped to the 'support-tickets' queue is obtained.
Specific message operations like receiving and completing are performed by a receiver.
3
Call receiver.ReceiveMessageAsync().
A ServiceBusReceivedMessage is fetched from the queue.
The message payload must be retrieved into application memory to perform processing.
4
Call receiver.CompleteMessageAsync(message).
The message is settled and permanently removed from the Service Bus queue.
Completing the message informs Service Bus that processing succeeded and the lock should be released and the message deleted.

Key Concept

Message receiver lifecycle and message settlement in Azure Service Bus
Question 118Question →

You are configuring a secure ASP.NET Core web application hosted in an Azure App Service to load configuration settings from an Azure App Configuration store. The configuration store contains key-values that reference secrets stored in an Azure Key Vault. You want to use a system-assigned managed identity to authenticate and authorize all access between these resources without storing credentials. In which order should you perform the steps to configure the security and connection between these services?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To configure the security and connection, you must first enable a system-assigned managed identity on the Azure App Service. Next, assign the 'App Configuration Data Reader' role to the App Service's managed identity on the App Configuration store. Then, assign the 'Key Vault Secrets User' role to the App Service's managed identity on the Key Vault. Finally, configure the App Service application settings to specify the App Configuration endpoint, and update the application startup code to initialize the configuration provider using DefaultAzureCredential.
The correct order requires establishing the system-assigned managed identity first. Once the identity exists, permissions must be assigned to it on both the Azure App Configuration store (App Configuration Data Reader) and the Azure Key Vault (Key Vault Secrets User). Finally, the App Service configuration must be updated with the endpoint, and the code updated to load configuration via DefaultAzureCredential.

Step-by-Step Solution

1
Enable system-assigned managed identity on the App Service.
A service principal is registered in Microsoft Entra ID for the App Service instance.
You must establish the identity principal in the tenant before assigning role-based access control permissions to it.
2
Grant 'App Configuration Data Reader' to the App Service identity on the App Configuration store.
The App Service is authorized to read keys and values from the configuration store.
This permission is necessary for the App Configuration provider to read settings and identify Key Vault references.
3
Grant 'Key Vault Secrets User' to the App Service identity on the Key Vault.
The App Service is authorized to read secret values directly from the Key Vault.
Key Vault references in App Configuration are resolved on the client side by the application itself; therefore, the App Service identity needs direct read access to Key Vault.
4
Add the endpoint configuration and modify startup code to use DefaultAzureCredential.
The application successfully connects to the App Configuration store at startup and resolves secrets using its managed identity.
This connects all configured security settings to the running application code.

Key Concept

Secure App Configuration and Key Vault References using Managed Identity
Estimated Time:2m 0s
Question 119Question →

You are configuring a custom domain for a publicly accessible Azure Container App. You want to secure the custom domain with an SSL/TLS certificate.

In which sequence must you perform the steps to successfully configure and secure the custom domain?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence is: first retrieve the domain verification code and FQDN from the Container App, next configure the TXT verification and CNAME records in your DNS provider, then add and verify the custom domain in the Container App, and finally bind the SSL/TLS certificate.
To successfully configure and secure a custom domain on Azure Container Apps, you must start by retrieving the unique verification code (asuid) and default FQDN. This allows you to create the required TXT verification and CNAME routing records in your DNS provider. Once the DNS records are active, you add the custom domain to the Container App, which triggers ownership verification. Finally, you secure the configuration by binding an SSL/TLS certificate.

Step-by-Step Solution

1
Retrieve verification details
Obtained the asuid verification code and FQDN from the Container App.
Azure requires these details to map your custom domain and verify your control over it.
2
Create DNS records
Created TXT and CNAME records at your DNS registrar.
Enables Azure's validation checks and ensures internet traffic routes to the Container App's default domain.
3
Add and verify the custom domain
Successfully associated the custom domain with the Container App.
The Container App checks for the presence of the TXT record to verify ownership before registration.
4
Bind the SSL certificate
Enabled HTTPS traffic securely on the custom domain.
Finalizes the setup to ensure secure, encrypted communication to the custom domain.

Key Concept

Custom domain configuration and verification sequence on Azure Container Apps
Estimated Time:2m 0s
Question 120Question →

You are configuring an existing Azure API Management instance to be deployed inside an Azure Virtual Network in Internal mode. You need to ensure that internal clients can successfully resolve and access the API gateway. Which sequence of steps should you perform?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To configure API Management in an internal virtual network, first create the subnet and configure NSG rules. Next, update the API Management network settings to Internal and select the subnet. After the deployment updates, retrieve the private Virtual IP (VIP) address. Finally, configure DNS records in a Private DNS Zone pointing to the VIP.
The correct sequence ensures that prerequisites (subnet and NSG rules) are satisfied first to prevent deployment failures. Then, the API Management configuration is updated. After the private VIP is allocated and retrieved, the DNS records are created to enable hostname resolution.

Step-by-Step Solution

1
Prepare the subnet and NSG rules.
A dedicated subnet is created with rules allowing traffic on necessary ports (like port 3443 for management).
API Management checks for network connectivity to dependencies during subnet association; incorrect NSG rules cause deployment failure.
2
Associate API Management with the subnet.
The connectivity status changes to Internal, initiating the deployment update.
This updates the configuration and deploys the gateway components inside the virtual network.
3
Obtain the private Virtual IP.
The private VIP address is retrieved from the API Management properties.
The VIP is needed to configure DNS routing to the internal gateway.
4
Configure DNS records.
DNS resolution is configured using an Azure Private DNS Zone.
Azure does not host DNS for private VIPs automatically, so manual records are required for resolution.

Key Concept

Internal Virtual Network Integration for Azure API Management
Estimated Time:2m 0s
PreviousPage 6 / 9Next
All practice questions — Microsoft Azure Developer (AZ-204) | Examkin