All practice questions

171 questions

Question 81Question

A developer needs to configure a local development environment for a lightweight Go application using the Azure Functions Core Tools custom handler feature and test the function locally. Which sequence of steps should the developer perform?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence is: Run 'func init --worker-runtime custom' in the command line, run 'func new --template "HTTP trigger" --name GoHandler' to add a new function trigger, compile the Go application source code into an executable file named 'handler', modify the 'host.json' file to set the 'defaultExecutablePath' property under the 'customHandler.description' section to 'handler', and finally run 'func start' to launch the Azure Functions host locally.
The correct sequence flows from establishing the local directory layout (init), creating the function trigger metadata (new), generating the executable from Go code (compile), mapping the host to this executable (host.json configuration), and executing the Functions runtime host (start).

Step-by-Step Solution

1
Initialize the project using 'func init --worker-runtime custom'.
Creates the project folder structure containing host.json and local.settings.json configured for a custom worker.
You must establish the Azure Functions project structure before you can add functions or configure handlers.
2
Create the function trigger using 'func new'.
Creates a function directory with a function.json defining the triggers and bindings.
A custom handler still relies on standard function.json metadata to determine which events should trigger the custom process.
3
Compile the Go source code.
Produces a standalone executable binary file (e.g., 'handler').
Go is a compiled language; the custom handler requires a compiled binary to receive requests forwarded by the host.
4
Configure the 'defaultExecutablePath' in host.json.
Points host.json to the compiled Go binary.
The Functions host reads host.json at startup to know the filename and location of the custom handler process to start.
5
Run 'func start'.
Launches the runtime and handler locally to accept requests.
Running the host requires all config and binaries to be in place, allowing you to test the HTTP execution locally.

Key Concept

Azure Functions Custom Handlers configuration and local development lifecycle
Question 82Question

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

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

Drag items to arrange them in the correct order

Show answer & explanation

Answer

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

Step-by-Step Solution

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

Key Concept

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

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

Drag items to arrange them in the correct order

Show answer & explanation

Answer

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

Step-by-Step Solution

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

Key Concept

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

You are developing a C# ASP.NET Core web application that will be hosted on an Azure App Service. The application must securely query data from an Azure SQL Database. You decide to use a user-assigned managed identity to authenticate the App Service to the database to ensure that database credentials are not hardcoded. Which sequence of steps should you perform to provision the identity, associate it with the App Service, and configure the database access permissions?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order of operations is to first create the user-assigned managed identity, then associate it with the App Service, establish an administrative connection to the SQL Database, create a database user mapped to the external provider identity, and lastly assign the database user to the db_datareader role.
The correct sequence begins with provisioning the user-assigned managed identity so it exists in Microsoft Entra ID. Next, this identity is associated with the App Service resource. To configure permissions, an administrator must log into the target database, create a containment user representing the identity, and finally add that user to the db_datareader role.

Step-by-Step Solution

1
Create the user-assigned managed identity.
A managed identity is registered as a standalone resource in Microsoft Entra ID.
This establishes a security principal that can be associated with resources and granted permissions.
2
Associate the user-assigned managed identity with the App Service.
The App Service is configured to run under the context of the user-assigned managed identity.
The hosting environment requires the identity association to make the identity's credentials available to the application's runtime.
3
Connect to the database using a Microsoft Entra ID admin account.
An administrative database session is initialized.
Creating external database users requires administrator-level access to the database.
4
Run the CREATE USER statement with the EXTERNAL PROVIDER clause.
A containment database user is created inside the SQL database.
This maps the database security principal to the external Microsoft Entra ID identity resource.
5
Add the containment user to the db_datareader database role.
The mapped database user receives read access to the database.
Role membership establishes the actual permissions needed by the application.

Key Concept

Configuring user-assigned managed identities involves registering the identity in the directory, associating it with the computing host, and mapping it to a database principal prior to assigning permissions.
Question 85Question

You need to use the Azure CLI to create a new Azure Key Vault, store a database connection string as a secret, and then retrieve that secret. What is the correct sequence of Azure CLI commands to achieve this?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence is to first create the resource group with `az group create`, then create the Key Vault with `az keyvault create`, next store the secret with `az keyvault secret set`, and finally retrieve the secret with `az keyvault secret show`.
To store and retrieve a secret using the Azure CLI, you must progress from global resource containers to the specific secret value. First, the resource group is created. Next, the Key Vault is provisioned within that resource group. Once the vault exists, the secret is written using the set command, and finally, the secret is retrieved using the show command.

Step-by-Step Solution

1
Create the resource group.
A resource group is provisioned in Azure.
Azure Key Vault requires a resource group to hold the resource.
2
Create the Key Vault.
The Key Vault instance is created inside the resource group.
Secrets must be stored within a specific Key Vault instance.
3
Set the secret.
The secret is successfully written to the Key Vault.
The connection string must be written to Key Vault storage before it can be referenced or read.
4
Show the secret.
The secret's value and metadata are returned.
Retrieving the secret requires querying the specific secret name inside the vault.

Key Concept

Azure Key Vault CLI Secret Management Lifecycle
Question 86Question

You are developing a C# console application that retrieves a specific product configuration document from an Azure Cosmos DB container by using the .NET SDK v3. You need to write the code that performs a point read of the item. Which sequence of actions should you perform to complete this operation? To answer, arrange the actions in the correct order.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To perform a point read, you must first instantiate a CosmosClient. Next, call GetDatabase on the CosmosClient to retrieve the Database reference. Then, call GetContainer on the Database to retrieve the Container reference. After that, initialize a PartitionKey structure with the partition key value. Finally, call ReadItemAsync on the Container, passing the unique identifier and the PartitionKey.
The correct sequence starts with instantiating the CosmosClient, which establishes the connection pool. You then call GetDatabase on the client and GetContainer on the database to navigate the SDK hierarchy. Before executing the read, you instantiate the PartitionKey with the target value. Finally, you execute the point read by calling ReadItemAsync on the container with the item ID and PartitionKey.

Step-by-Step Solution

1
Instantiate the CosmosClient object.
A CosmosClient instance is created, initiating the connection and client-side caching.
The client is the root object required to interact with any Azure Cosmos DB resources.
2
Call GetDatabase on the CosmosClient instance.
A Database object reference is returned.
You must navigate the resource hierarchy from the client down to the database before accessing containers.
3
Call GetContainer on the Database instance.
A Container object reference is returned.
All item-level operations are executed against a container reference.
4
Create a PartitionKey instance with the item's partition key value.
A PartitionKey structure is initialized.
The SDK v3 requires an explicit PartitionKey parameter for point operations to ensure efficient routing.
5
Call ReadItemAsync on the Container instance, passing the ID and PartitionKey.
An ItemResponse is returned, containing the document data.
This executing call performs the actual point read operation over the network.

Key Concept

Executing container and item operations using the Azure Cosmos DB .NET SDK v3 requires initializing the CosmosClient, obtaining Database and Container references, and providing a PartitionKey to the item operation method.
Question 87Question

You are writing a C# console application using the Azure.Storage.Blobs SDK (version 12.x) to migrate archive data from a source Azure Storage account to a destination storage account. The source container is private, and you want to perform the transfer asynchronously while monitoring the process. Arrange the following steps in the correct sequence to copy the blob and determine when the operation finishes.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

Generate the read-only SAS token for the source blob, instantiate the destination BlobContainerClient, obtain the destination BlobClient, initiate the copy using StartCopyFromUriAsync with the source URI, and poll the destination properties until the CopyStatus completes.
To copy a private blob asynchronously between storage accounts, you must first generate a read-only SAS token for the source blob. Next, create a container client and then a blob client for the destination target. With these clients set up, call StartCopyFromUriAsync on the destination blob client to prompt the service to pull data from the source URI. Finally, poll the destination properties using GetPropertiesAsync to monitor the copy status until it resolves.

Step-by-Step Solution

1
Generate a SAS token with read permissions on the source blob.
An authenticated URI pointing to the source blob is acquired.
The destination storage account requires read authorization to fetch the source blob's data.
2
Instantiate a BlobContainerClient for the destination container.
A service client targeting the destination container is created.
You must have a reference to the container before you can address specific blobs inside it.
3
Call GetBlobClient on the container client.
A BlobClient object representing the destination blob is returned.
The copying action is initiated on the target blob client itself.
4
Invoke StartCopyFromUriAsync on the destination BlobClient.
The copy task is queued on the Azure service backend.
This starts the asynchronous copy operation between the storage accounts.
5
Loop to call GetPropertiesAsync on the destination BlobClient.
The copy process completes with success or failure.
Because the copy is executed on the Azure service backend, the client must query the destination blob properties to find out when the status changes from Pending.

Key Concept

Asynchronous Blob Copying using the Azure.Storage.Blobs SDK

Alternative Method

Instead of polling the destination blob properties programmatically, you can listen to Microsoft.Storage.BlobCreated events using Azure Event Grid to handle completion reactively.
Estimated Time:2m 0s
Question 88Question

You manage an Azure App Service Web App named RetailCartService that is currently hosted on a Free (F1) App Service plan. You need to implement and test CPU-based autoscaling for the application. You must ensure the application scales out to multiple instances under high load and scales back in when load decreases.

Which of the following represents the correct sequence of steps to configure and verify this autoscale behavior?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence of steps starts with scaling up the App Service plan to the Standard tier, followed by enabling custom autoscale and defining the scaling rules. Next, synthetic load is generated to trigger the scale-out rule, and finally, the instance count is monitored to confirm the scale-out occurred.
The correct sequence begins with upgrading the App Service plan because scaling out and custom autoscale rules are not supported on the Free (F1) tier. Once scaled to the Standard (S1) tier, custom autoscale rules can be configured. To verify the configuration, synthetic load must be generated to trigger the scale-out threshold, and then the instance count is monitored to confirm the scale-out event succeeded.

Step-by-Step Solution

1
Scale up the hosting plan.
The App Service plan is upgraded from the Free (F1) tier to the Standard (S1) tier.
Free and Shared tiers do not support custom autoscale or scale-out capabilities. Standard (S) or Premium (P) tiers are required.
2
Configure the autoscale rules.
Custom autoscale is enabled with CPU-based scale-out and scale-in rules.
This establishes the autoscale profile and thresholds that govern the scale-out and scale-in operations.
3
Trigger the scale-out condition.
CPU utilization on the Web App increases beyond the scale-out threshold.
Synthetic load must be applied to simulate peak traffic and evaluate whether the autoscale engine detects the metric threshold breach.
4
Verify the scale-out outcome.
The App Service plan scales out to additional instances.
Monitoring the instance count confirms that the autoscale engine executed the rule and added capacity successfully.

Key Concept

Autoscaling configuration and verification workflow for Azure App Service Web Apps.
Estimated Time:1m 30s
Question 89Question

You need to configure a local script to run nightly administrative tasks against Azure resources. The script must run non-interactively and authenticate using certificate-based authentication. Which sequence of steps must you perform to set up the authentication and test the connection?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To set up certificate-based authentication, you must first generate the self-signed certificate, register the application in Microsoft Entra ID, upload the certificate public key, assign the required RBAC role to the service principal, and finally execute the login command using the certificate details.
The correct sequence starts with generating a certificate locally to obtain a public key. Then, the application is registered in Microsoft Entra ID to establish its identity. Next, the public key is uploaded to the application registration so Microsoft Entra ID can verify credentials. After that, the service principal is assigned an RBAC role to grant the necessary resource permissions. Finally, the script executes the login command using the certificate path, verifying the configuration.

Step-by-Step Solution

1
Generate a self-signed certificate locally.
A private key (retained locally) and a public key certificate (.cer file) are created.
The public key certificate is required to configure the application registration credential.
2
Create the application registration in Microsoft Entra ID.
An application object and a corresponding service principal are created in the Microsoft Entra tenant.
This establishes the identity that will be used by the automation script.
3
Upload the public key (.cer) to the application registration's Certificates & secrets.
The public key is associated with the application registration.
This allows Microsoft Entra ID to validate authentication requests signed by the private key.
4
Assign an RBAC role to the service principal.
The service principal is authorized to perform operations on the specified Azure resources.
Establishing identity is not enough; the service principal must be explicitly authorized to access resources.
5
Run the login command with the certificate details.
The script successfully authenticates and receives an access token.
This verifies that the identity, credentials, and RBAC permissions are correctly configured.

Key Concept

Configuring certificate-based authentication for service principals to enable secure, non-interactive scripting and automation.
Question 90Question

You are developing an ASP.NET Core web application that will be hosted in an Azure App Service. The application must retrieve configuration settings from an Azure App Configuration store. Several settings in the store are Key Vault references pointing to secrets in Azure Key Vault. You must secure access using a single user-assigned managed identity, adhering to the principle of least privilege.

Which of the following represents the correct sequence of steps to configure the Azure resources and the web application?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts with creating the user-assigned managed identity, associating it with the App Service web app, granting the identity the App Configuration Data Reader role on the App Configuration store and the Key Vault Secrets User role on the Key Vault, configuring the AZURE_CLIENT_ID application setting on the App Service, and finally updating the application startup code to use DefaultAzureCredential to connect to App Configuration and resolve Key Vault references.
The correct sequence ensures that the identity resource is established first, associated with the host compute resource, authorized via role-based access control (RBAC) to read configuration and Key Vault secrets, mapped to the environment via the standard client ID environment variable, and finally consumed by the application code using the DefaultAzureCredential.

Step-by-Step Solution

1
Create a user-assigned managed identity in Microsoft Entra ID.
A new managed identity resource is created with a unique Client ID and Principal ID.
You cannot perform role assignments or associate the identity with other Azure resources until the identity resource itself exists.
2
Associate the user-assigned managed identity with the Azure App Service web app.
The App Service web app is configured to use the user-assigned identity.
The web app must have the identity assigned so the hosting platform can request tokens on its behalf.
3
Assign the App Configuration Data Reader role to the identity on the App Configuration store, and the Key Vault Secrets User role to the identity on the Key Vault.
The managed identity is granted the minimum required permissions to read configuration keys and resolve Key Vault secrets.
Since Key Vault references in Azure App Configuration are resolved client-side by the application itself, the application's identity requires permissions to both services.
4
Add the AZURE_CLIENT_ID application setting to the App Service web app.
An environment variable with the identity's client ID is injected into the application's runtime context.
By default, DefaultAzureCredential attempts to use the system-assigned managed identity. Specifying the AZURE_CLIENT_ID environment variable forces it to use the correct user-assigned identity.
5
Configure the web app's startup code to connect to the App Configuration store using DefaultAzureCredential and enable Key Vault options.
The application successfully fetches the configuration and decrypts Key Vault references on startup.
The application code must explicitly register the App Configuration provider and pass DefaultAzureCredential to handle authentication.

Key Concept

Configuring secure client-side resolution of Azure App Configuration Key Vault references using a user-assigned managed identity.
Estimated Time:3m 0s
Question 91Question

An organization has deployed an Azure Container App named feedback-portal. You are tasked with configuring a custom domain named feedback.contoso.com for this Container App and securing it using an Azure Container Apps managed certificate. Which sequence of steps should you perform to complete the configuration?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To configure a custom domain and secure it with a managed certificate, you must first create the DNS TXT and CNAME records at your DNS provider. Next, add the custom domain to the Container App to validate ownership. Once validated, generate the managed certificate, and finally bind the certificate to the domain to secure the connection.
The correct order begins with configuring DNS records at the registrar, which allows Azure to verify ownership. Next, adding the custom domain to the Container App validates ownership. Only after successful validation can the managed certificate be generated. Finally, the certificate is bound to the custom domain to secure the connection with HTTPS.

Step-by-Step Solution

1
Create the DNS TXT and CNAME records at the DNS registrar.
The domain registrar has active records pointing to the Container App.
Azure checks these records during the validation phase to verify that you own the domain.
2
Add the custom domain to the Container App to trigger verification.
The domain is successfully added and verified on the Container App.
The domain must be validated and added to the Container App before a managed certificate can be issued.
3
Create the Azure Container Apps managed certificate for the domain.
The managed certificate is generated by Azure and is ready for binding.
The certificate must exist within the Container Apps environment before it can be bound to the custom domain.
4
Bind the managed certificate to the custom domain.
The custom domain is bound to the certificate, securing all incoming traffic with HTTPS.
This is the final step that establishes SSL/TLS termination for the custom domain.

Key Concept

Custom domain verification and managed certificate binding in Azure Container Apps.
Estimated Time:2m 0s
Question 92Question

You are developing a C# application using the Azure.Storage.Blobs SDK (v12). The application needs to perform a concurrency-safe metadata update on an existing blob named config.json. You must acquire a lease, apply the metadata dictionary, and release the lease.

Which sequence of code actions should you perform to complete this operation? Arrange the actions in the correct order.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To perform a concurrency-safe metadata update using the Azure.Storage.Blobs SDK, you must first get the BlobClient instance, initialize the BlobLeaseClient, acquire the lease to obtain a LeaseId, set the metadata while passing the LeaseId in the BlobRequestConditions, and finally release the lease.
The correct sequence begins by locating the target blob, initializing the lease manager, locking the blob to secure a lease ID, applying the metadata change with the required request conditions, and finally freeing the resource for other tasks.

Step-by-Step Solution

1
Retrieve the BlobClient instance for config.json.
A reference to the target blob is established.
All subsequent lease and metadata operations require a valid BlobClient reference.
2
Initialize the BlobLeaseClient.
A lease client is mapped to the target BlobClient.
The Azure.Storage.Blobs.Specialized namespace uses the BlobLeaseClient class to manage locks on blobs.
3
Acquire the lease for a specified duration.
A BlobLease object is returned containing the active LeaseId.
You must establish the lease lock first to secure the resource before attempting to write changes.
4
Call SetMetadataAsync with the request conditions.
The metadata dictionary is updated on the Azure Storage blob.
Azure Storage rejects write requests on leased blobs unless the correct LeaseId is provided in the headers via BlobRequestConditions.
5
Release the lease lock.
The write lock is removed from the blob.
Releasing the lease immediately frees the resource for other operations instead of waiting for the lease duration to expire.

Key Concept

Concurrency management and metadata updates using BlobLeaseClient in Azure Storage SDK (v12).
Question 93Question

You are configuring an ASP.NET Core web application hosted on an Azure App Service to retrieve data from an Azure SQL Database. The application must authenticate using a user-assigned managed identity. You need to configure the required identity and database access. Which five 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

To configure a user-assigned managed identity for an Azure App Service to access Azure SQL Database, the correct sequence of actions is: 1. Create a user-assigned managed identity in Microsoft Entra ID. 2. Associate the user-assigned managed identity with the Azure App Service web app. 3. Connect to the Azure SQL Database by using a Microsoft Entra ID administrator account. 4. Run the SQL command to create a database user mapped to the user-assigned managed identity. 5. Run the SQL command to add the database user to the db_datareader role.
The correct sequence starts with creating the user-assigned managed identity and associating it with the App Service web app. Next, you must connect to the Azure SQL Database using a Microsoft Entra ID administrator account to have the necessary privileges to provision external users. Inside the SQL Database, you run a SQL query to create a user mapped to the managed identity, and finally run another query to add that user to the db_datareader role to grant the application access.

Step-by-Step Solution

1
Create the user-assigned managed identity
The identity exists in Microsoft Entra ID and has a unique client ID and principal ID.
An identity must exist before it can be assigned to resources or referenced in permissions.
2
Associate the user-assigned managed identity with the App Service
The App Service is configured to use the identity for outbound authentications.
This allows the application hosted on the App Service to request access tokens for this identity.
3
Connect to Azure SQL Database using a Microsoft Entra ID administrator
Established database connection with administrative privileges capable of creating Entra-based users.
Standard SQL logins do not have permissions to query Microsoft Entra ID to validate and create database users from external providers.
4
Create a SQL database user mapped to the managed identity
A database user represents the managed identity within the database context.
A database user is required to grant database-level permissions to the identity.
5
Grant the database user the db_datareader role
The database user is added to the role, giving it read access.
This authorizes the identity to read data from the database.

Key Concept

Provisioning, assigning, and authorizing a user-assigned managed identity to access Azure SQL Database
Question 94Question

You are developing a solution that uses Azure Event Grid to handle custom application events. You need to create a new custom topic, configure a subscription to route events to an Azure Function, and then publish a test event to verify the endpoint routing using an API client.

Which five 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

Create the custom Event Grid topic, retrieve the endpoint URL and access key, create the event subscription, construct the JSON array with the event object, and send the HTTP POST request to the custom topic endpoint with the access key in the headers.
To configure and verify Event Grid routing, you must follow a logical sequence: first, create the target resource (the custom topic). Once created, retrieve the endpoint URI and SAS key for authorization. Then, create the event subscription so that when you publish the test event, it will actually be routed to the Azure Function rather than being dropped. Next, format the event payload as a JSON array to comply with the Event Grid schema. Finally, send an HTTP POST request to the endpoint, specifying the SAS key in the headers and the JSON array in the request body.

Step-by-Step Solution

1
Create the custom Event Grid topic resource in Azure.
The topic resource is created and allocated a unique endpoint.
You cannot obtain connection credentials or bind subscriptions without first creating the topic.
2
Retrieve the access key and the endpoint URI from the created topic.
The topic endpoint URL and primary access key are obtained.
These values are required to authenticate and direct the HTTP request when publishing events.
3
Create an event subscription on the custom topic targeting the Azure Function endpoint.
The handler endpoint is registered to listen to events from the custom topic.
If events are published before a subscription exists, the custom topic will discard them immediately.
4
Prepare the message payload as a JSON array containing a schema-compliant Event Grid event.
A valid Event Grid JSON payload is created.
Event Grid endpoints reject payloads that do not match the required JSON array structure and schema properties (e.g., id, subject, eventType, eventTime, data).
5
Send an HTTP POST request to the endpoint with the JSON payload and the access key in the aeg-sas-key header.
The event is successfully published and routed to the Azure Function.
This initiates the delivery pipeline, transmitting the test event to the registered handler.

Key Concept

Publishing events to a custom Event Grid topic
Question 95Question

You are developing a C# application that needs to publish telemetry events to an Azure Event Grid custom topic. You plan to use the Azure SDK for .NET (specifically the Azure.Messaging.EventGrid NuGet package). Which sequence of steps must you perform in your code to publish the events?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence of steps to publish events is to first retrieve the custom topic endpoint and key, then instantiate the EventGridPublisherClient, next construct the collection of EventGridEvent objects, and finally invoke SendEventsAsync to transmit the events.
To publish events, you must first fetch the configuration settings (endpoint and key), configure the client with those credentials, prepare the list of events to send, and finally call the send method on the client.

Step-by-Step Solution

1
Retrieve custom topic credentials
Endpoint URI and access key are available in memory.
These credentials are required to authorize the client when communicating with the Azure Event Grid custom topic.
2
Instantiate EventGridPublisherClient
An active client instance is ready for sending events.
The client handles connections and serialization, requiring the endpoint URI and an AzureKeyCredential initialized with the access key.
3
Construct EventGridEvent objects
A list or collection of event models ready to be transmitted.
You must define the metadata (subject, eventType, dataVersion) and the payload data for the events before publishing.
4
Invoke SendEventsAsync
Events are transmitted and published to the Event Grid topic.
The SendEventsAsync method sends the prepared batch of events to the target endpoint asynchronously.

Key Concept

Publishing events to an Azure Event Grid custom topic using the Azure Messaging EventGrid client library for .NET.
Question 96Question

You are developing a serverless order processing workflow using Azure Durable Functions. The workflow is initiated via an HTTP request, performs a payment processing activity, and then runs a receipt generation activity.

Arrange the execution and execution replay events of the Durable Functions runtime in the correct sequential order from the arrival of the initial client request to the execution of the second activity.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins with the client function initiating the orchestrator and returning a response, followed by the orchestrator starting and scheduling the first activity. The orchestrator then yields execution while the activity runs. After the activity completes and logs its output to history, the orchestrator wakes up, replays from the beginning, retrieves the activity output from history, and schedules the second activity.
The correct sequence mirrors the fundamental event-sourcing and execution replay design of Durable Functions. The workflow is started by a client function returning status endpoints. Then, the orchestrator begins, schedules the first activity, and yields. When the activity finishes, its outcome is recorded in Azure Storage, triggering the orchestrator to wake up, replay from the beginning using history, and proceed to the next activity.

Step-by-Step Solution

1
Trigger the orchestration client.
The client function starts the orchestration instance and returns an HTTP 202 response.
Durable workflows are kicked off by a starter client function which generates the management endpoints.
2
Begin orchestrator execution and schedule the first activity.
The orchestrator runs and calls the payment activity using an await expression.
The orchestrator must schedule the first task in the sequence.
3
Yield orchestrator execution.
The orchestrator goes to sleep, saving execution state.
Yielding execution ensures that compute resources are not wasted while waiting for long-running activities.
4
Log activity completion.
The completed activity's return value is saved to the history table in storage.
The runtime relies on persistent storage history to reconstruct the workflow state.
5
Replay the orchestrator and schedule the next activity.
The orchestrator executes again, reads the payment result from history, and schedules the receipt activity.
To maintain state safely, the orchestrator replays its code, bypassing completed tasks recorded in the history table.

Key Concept

Replay mechanism and event sourcing in Azure Durable Functions
Question 97Question

You are troubleshooting a startup failure for a web application hosted on a Linux-based Azure App Service. You need to enable container logging, view the logs in real-time to identify the exception, and minimize administrative overhead. Move the 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, run the az webapp log config command with the --docker-container-logging filesystem parameter. Second, run the az webapp log tail command. Third, access the web application URL. Fourth, review the streaming stdout and stderr console output in the CLI terminal.
To diagnose a startup failure on a Linux App Service, you must first enable container logging by running the command with the filesystem parameter. Once enabled, starting the log stream with the tail command ensures you can capture live output. Accessing the web application triggers the startup or request cycle, producing log entries that are then piped directly to the console for analysis.

Step-by-Step Solution

1
Enable container logging to the filesystem.
Container logging is activated, instructing the Linux App Service to write stdout and stderr to the filesystem.
By default, container logging is disabled. You must enable it using the az webapp log config command with the --docker-container-logging parameter set to filesystem before you can stream the logs.
2
Initiate the log streaming session.
A persistent connection is established to the App Service log streaming endpoint.
Running the az webapp log tail command starts a live stream session in your terminal, which will capture and print logs in real-time as they are written.
3
Trigger the failure.
The App Service container attempts to initialize or process the incoming web request, generating diagnostic events.
Since the stream is live, generating a new request ensures that the startup or runtime error is immediately logged and streamed to the active CLI session.
4
Review the log stream output.
The exact exception details, stack traces, or console outputs are displayed in the CLI terminal.
Analyzing the stdout/stderr streaming output allows you to inspect the exception details and trace the root cause of the startup failure.

Key Concept

Configuring container logging and streaming logs in real-time using Azure CLI for Linux Azure App Service.
Question 98Question

You are developing a web application that serves static assets from an Azure CDN Standard from Microsoft endpoint. You need to configure the CDN endpoint to automatically redirect all incoming HTTP requests to HTTPS using the CDN's Rules engine. Which five actions should you perform in sequence? To answer, arrange the appropriate actions in the correct order.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To configure an HTTP to HTTPS redirect for an Azure CDN Standard from Microsoft endpoint, you must navigate to the CDN endpoint in the Azure Portal, access the Rules engine under Settings, add a new rule, define a match condition where Request protocol equals HTTP, add a URL redirect action to HTTPS, and finally save the rule.
The correct sequence begins with accessing the endpoint settings and selecting the Rules engine. A new rule must be created and named. To target insecure traffic, a condition matching the HTTP protocol is added. The associated action must be a URL redirect pointing to HTTPS. Finally, saving the rule deploys the configuration to the edge nodes.

Step-by-Step Solution

1
Navigate to the Rules engine section of the CDN endpoint.
The Rules engine interface loads, allowing you to define global or custom rules.
This is the administrative interface where CDN rules are managed.
2
Add a new rule container.
A blank rule structure is created.
Each rule requires a name before conditions or actions can be appended.
3
Define the match condition for HTTP traffic.
The rule is configured to trigger only when an incoming request uses the HTTP protocol.
This ensures secure HTTPS requests are not evaluated or redirected again.
4
Configure the redirect action.
The rule is set to issue an HTTP redirect to the HTTPS counterpart.
The URL redirect action handles the redirection response directly at the CDN edge.
5
Save the rule configuration.
The rule is saved and begins deployment.
The configuration must propagate to all global edge servers to take effect.

Key Concept

Configuring transport layer security redirects using the Azure CDN Standard Rules Engine.
Estimated Time:1m 30s
Question 99Question

You are deploying an ASP.NET Core web application to an Azure App Service. The application must retrieve secrets from an Azure Key Vault using a user-assigned managed identity. The application code uses DefaultAzureCredential from the Azure.Identity SDK to authenticate. Which sequence of steps should you perform to configure the environment and enable secure access?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

First, create the user-assigned managed identity. Second, associate the identity with the App Service. Third, assign the Key Vault Secrets User RBAC role to the identity on the Key Vault. Finally, configure the AZURE_CLIENT_ID application setting on the App Service with the identity's client ID.
Configuring a user-assigned managed identity requires a specific sequence: you must create the standalone identity resource, associate it with the App Service resource, grant the identity permission to access the Key Vault, and configure the AZURE_CLIENT_ID app setting. Setting the AZURE_CLIENT_ID environment variable is necessary because DefaultAzureCredential will not automatically know which user-assigned identity to use without it.

Step-by-Step Solution

1
Create the user-assigned managed identity resource.
A standalone identity resource is created with a unique Client ID and Principal ID.
The identity must exist in Microsoft Entra ID before it can be assigned to resources or granted RBAC roles.
2
Associate the identity with the App Service.
The App Service's identity configuration includes the resource ID of the user-assigned managed identity.
This configuration allows the App Service infrastructure to obtain Entra ID tokens on behalf of the user-assigned managed identity.
3
Assign the Key Vault Secrets User RBAC role to the identity's service principal.
The identity is authorized to access secrets within the Key Vault.
Azure Key Vault requires explicit data-plane permissions for identities to retrieve secrets.
4
Set the AZURE_CLIENT_ID environment variable in the App Service app settings.
The application's runtime environment includes the AZURE_CLIENT_ID setting.
DefaultAzureCredential requires this environment variable to distinguish between multiple potential identities when acquiring tokens for a user-assigned managed identity.

Key Concept

Configuration workflow for user-assigned managed identities with DefaultAzureCredential
Question 100Question

An enterprise hotel management application uses Azure Cosmos DB to store reservation details. The container uses the guest's ID (guestId) as the partition key. You are writing a C# helper method using the Azure Cosmos DB .NET SDK v3 that retrieves an existing booking, modifies the check-out date, and saves the changes back to the database.

Which sequence of code statements must you execute to complete these tasks?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

Initialize the CosmosClient, obtain references to the database and container, execute ReadItemAsync to fetch the booking, modify the checkout date property, and call ReplaceItemAsync with the updated object and partition key.
To update an existing item in Azure Cosmos DB using the .NET SDK v3, you must first initialize a CosmosClient and drill down to the Container reference. From there, you perform a point read using ReadItemAsync to fetch the item, which requires the item ID and the PartitionKey. After modifying the deserialized object exposed via the Resource property of the response, you call ReplaceItemAsync, again specifying the updated object, the item ID, and the PartitionKey to save the changes.

Step-by-Step Solution

1
Initialize the CosmosClient instance using the connection string.
A CosmosClient object is created to manage connections to the Azure Cosmos DB account.
The client is the entry point for all Cosmos DB SDK operations.
2
Get a Database reference using the client.
A Database object representing the target database.
You must drill down through the hierarchy to get a container reference.
3
Get a Container reference using the database.
A Container object representing the target container.
Item operations like ReadItemAsync and ReplaceItemAsync are invoked on the Container object.
4
Retrieve the booking item by calling ReadItemAsync.
An ItemResponse containing the Booking object in its Resource property.
You must read the current state of the document from the server before modifying it.
5
Modify the guest's checkout date property on the deserialized object.
The local Booking object has its checkout date updated.
The modification must be applied locally before being sent to the database.
6
Persist the modified object using ReplaceItemAsync.
The item is updated in the Cosmos DB container.
This updates the existing document on the server using its unique ID and partition key.

Key Concept

Performing point read and replacement operations on items using the Cosmos DB .NET SDK v3.
PreviousPage 5 / 9Next
All practice questions — Microsoft Azure Developer (AZ-204) | Examkin