Examkin

All practice questions

171 questions

All types972Multiple choice497Multiple select269Matching9Ordering171Fill in the blank26
Question 41Question →

You are configuring a custom domain (api.contoso.com) for a public-facing Azure Container App named inventory-api. You need to ensure the custom domain is validated and secured with an SSL/TLS certificate.

Which sequence of steps must you perform to configure the custom domain and certificate?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To configure a custom domain and certificate for an Azure Container App, you must first retrieve the FQDN and verification code from Azure, then configure the CNAME and TXT records at the DNS provider, followed by adding the custom domain to the app to complete validation, and finally creating and binding the SSL/TLS certificate.
The correct order resolves dependencies chronologically. First, the FQDN and validation token are retrieved from the Container App. Second, these values are used to configure CNAME and TXT records at the DNS provider. Third, the domain is added and validated in the Azure Container App. Finally, a certificate is bound to the validated domain.

Step-by-Step Solution

1
Retrieve the FQDN and verification code from the Container App settings.
The verification token and default domain name are obtained.
These values are required to configure the DNS records at your registrar.
2
Configure CNAME and TXT records at the DNS provider.
DNS records are updated to point to the Container App.
Azure requires public DNS records to prove ownership of the domain before it can be registered.
3
Add the custom domain to the Container App.
The custom domain is validated and registered in the Container App environment.
Validation queries the DNS provider and will fail if the TXT and CNAME records are not present.
4
Create and bind the SSL/TLS certificate.
HTTPS is secured for the custom domain.
You cannot issue or bind a certificate to a domain that is not registered with the Container App.

Key Concept

Configuring custom domains and TLS certificates for ingress in Azure Container Apps.
Estimated Time:2m 0s
Question 42Question →

You have a private Azure Container Registry named registry1 and an Azure Container App named app1. You need to configure app1 to pull images from registry1 using a system-assigned managed identity. The configuration must follow the principle of least privilege. Which three 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

To configure the container app, first enable the system-assigned managed identity on the container app, then assign the AcrPull role to the container app's system-assigned managed identity on the Azure Container Registry, and finally configure the container app's registry credentials to use the system-assigned managed identity.
To allow a container app to pull images from a private Azure Container Registry using a system-assigned identity, you must first enable the system-assigned identity on the container app resource so that Microsoft Entra ID registers it. Next, you assign the AcrPull role to this identity at the registry's scope to authorize access. Finally, you update the container app's registry configuration to use the system-assigned identity for authentication.

Step-by-Step Solution

1
Enable the system-assigned managed identity on the container app.
An identity principal is created in Microsoft Entra ID for the container app.
You must create the system identity before you can grant it permissions on other resources.
2
Assign the AcrPull role to the container app's system-assigned managed identity on the Azure Container Registry.
The identity principal is granted read-only pull permissions to the registry.
This grants the minimum access permissions necessary to retrieve container images from the registry.
3
Configure the container app's registry settings to use the system-assigned managed identity.
The container app uses its system-assigned identity to authenticate against the registry URL.
The container app must be explicitly configured to authenticate via the system-assigned identity when referencing the registry.

Key Concept

Configuring private container registry access for Azure Container Apps using a system-assigned managed identity.
Question 43Question →

You are developing a web application hosted on an Azure App Service. You need to enable application logging to the file system and view the log messages in real-time using the Azure CLI. Which three 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, run the az webapp log config command with the --application-logging true parameter. Second, run the az webapp log tail command. Third, navigate to the web application URL to generate HTTP traffic.
To view application logs in real-time, you must first enable file system application logging by running the configure command with the application-logging flag set to true. Once configured, you run the tail command to start the live log stream, and then perform actions in the application to generate log entries.

Step-by-Step Solution

1
Enable filesystem application logging using Azure CLI
Application logging to the file system is enabled for the Web App
By default, application logging to the file system is disabled. It must be enabled before you can stream logs.
2
Start the log stream session
Real-time log streaming begins in the command line interface
Initiating the tail command starts listening for diagnostic events from the Web App.
3
Browse the web application
Diagnostic trace and log outputs appear live in the terminal
Generating web requests triggers the application execution which produces the log entries to stream.

Key Concept

Enabling and streaming Web App application logs using Azure CLI
Question 44Question →

You are developing a secure Azure Function App (V4 runtime). The Function App must retrieve a database connection string from an Azure Key Vault. To comply with security policies, the Function App must use a user-assigned managed identity to resolve Key Vault references.

Arrange the steps in the correct order to configure the Function App to use the user-assigned managed identity for resolving Key Vault references.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To configure the Function App to use a user-assigned managed identity for Key Vault references, first create and assign the user-assigned managed identity to the Function App. Next, update the Function App configuration to set this identity as the key vault reference identity. Then, grant this identity the Key Vault Secrets User role on the Key Vault. Finally, add the application setting referencing the Key Vault secret.
To successfully configure a user-assigned managed identity for Key Vault references in Azure Functions, the identity must first be created and assigned to the Function App. Then, the Function App must be configured to use this user-assigned identity for resolving Key Vault references (via the keyVaultReferenceIdentity setting). Next, the identity must be granted read access to the Key Vault (using the Key Vault Secrets User role or access policies). Finally, the reference setting is added to the Function App's configuration.

Step-by-Step Solution

1
Associate the user-assigned identity with the Function App.
The identity is linked to the Function App resource.
The identity must be associated with the Function App first so it has permission to act on behalf of the application.
2
Configure the Key Vault reference identity setting.
The keyVaultReferenceIdentity configuration of the Function App is set to the identity's resource ID.
By default, Key Vault references use system-assigned identities; you must explicitly override this to use a user-assigned identity.
3
Grant Secret Get access.
The user-assigned identity is authorized to retrieve secrets from the Key Vault.
The identity requires RBAC permissions or an access policy to fetch the secret values.
4
Add the application setting using Key Vault reference syntax.
The connection string setting is configured as a reference to the secret.
The setting is created last to ensure it resolves immediately when the Function App loads the configuration.

Key Concept

Configuring Azure Functions to use user-assigned managed identities for Key Vault references.
Estimated Time:2m 0s
Question 45Question →

You need to write a C# application using the Azure.Storage.Blobs SDK (v12) to temporarily lock a blob for exclusive write access. Arrange the following steps in the correct order to acquire a 30-second lease, perform operations, and then clean up the lease resource.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

First instantiate a BlobClient, then initialize a BlobLeaseClient using GetBlobLeaseClient, next call AcquireAsync to secure the lease, and finally call ReleaseAsync to unlock the blob.
The correct sequence begins with creating the base BlobClient targeting the blob. Next, you must instantiate a BlobLeaseClient by calling the GetBlobLeaseClient extension method on the BlobClient. Once initialized, AcquireAsync is invoked on the lease client to lock the blob. Finally, after performing modifications, ReleaseAsync is called to free the lock.

Step-by-Step Solution

1
Instantiate the BlobClient.
A BlobClient instance representing the specific blob is obtained.
All blob-level operations require a client targeting the resource.
2
Initialize the BlobLeaseClient.
A BlobLeaseClient bound to the BlobClient is obtained.
Lease operations are handled by the BlobLeaseClient class in Azure.Storage.Blobs (v12).
3
Acquire the lease.
The blob is locked for 30 seconds, returning a lease ID.
The lease must be active before modifying the blob or before releasing it.
4
Release the lease.
The lease is removed and the blob is unlocked.
This unlocks the blob so that other writers are not blocked once the task is completed.

Key Concept

Acquiring and releasing leases using the Azure.Storage.Blobs SDK (v12) BlobLeaseClient.
Question 46Question →

You are developing a .NET application for a fleet management system that logs vehicle telemetry. You need to write C# code using the Azure Cosmos DB .NET SDK v3 to insert a new status record into a container. Arrange the steps in the correct order to initialize the required SDK components and execute the item creation operation.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To insert an item using the Azure Cosmos DB .NET SDK v3, you must first instantiate a CosmosClient with the connection string. Using that client, call GetDatabase to get a Database reference, and then call GetContainer on the database to get a Container reference. Finally, invoke CreateItemAsync on the container reference while providing both the item object and its PartitionKey.
The Azure Cosmos DB .NET SDK v3 structures its objects in a strict hierarchy mapping directly to Azure Cosmos DB resources. You start by instantiating the CosmosClient (1), which represents the connection. From the client, you acquire a reference to the Database (2). From the database reference, you acquire a reference to the Container (3). With the Container reference, you can execute operations like CreateItemAsync (4).

Step-by-Step Solution

1
Instantiate the client object
A CosmosClient instance is configured and active.
The client holds configuration settings and handles connections to the Azure Cosmos DB service.
2
Access the database reference
A Database proxy object is returned.
The SDK requires traversing the logical hierarchy: Client -> Database -> Container.
3
Access the container reference
A Container proxy object is returned.
All item-level operations such as creates, reads, and deletes are executed directly against a Container reference.
4
Execute the item creation
The telemetry item is persisted in the database.
Calling CreateItemAsync with the payload and PartitionKey sends the insert request to the correct physical partition.

Key Concept

Traversing the Azure Cosmos DB .NET SDK v3 resource hierarchy (CosmosClient to Database to Container) to perform item operations.
Question 47Question →

An organization hosts a report generation web application named contoso-reports on an Azure App Service Web App. The web application currently runs on an App Service plan named asp-free using the Free (F1) pricing tier.

During scheduled weekly report generation, the web application experiences severe CPU spikes that cause performance degradation. You need to implement an autoscale strategy using the Azure CLI that meets the following requirements:
- The hosting plan must be changed to the lowest cost tier that supports autoscale rules.
- The instance count must scale out by 1 instance when average CPU utilization is greater than 85% for 10 minutes.
- The instance count must scale in by 1 instance when average CPU utilization drops below 40% for 10 minutes.
- The configuration must prevent autoscale flapping.

Which four Azure CLI commands should you execute in sequence? To answer, move the appropriate commands from the list of commands to the answer area and arrange them in the correct order. (Note: Configure the scale-out rule before the scale-in rule.)

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To configure autoscale for the web app, you must first update the App Service plan SKU to S1 to support autoscale. Next, create the autoscale setting on the plan. Finally, configure the scale-out rule followed by the scale-in rule.
The correct order begins with scaling up the App Service plan from Free (F1) to Standard (S1) using 'az appservice plan update' because autoscaling is not supported on the Free tier. Next, you must create the autoscale setting container using 'az monitor autoscale create' before you can add rules to it. After creating the setting container, you add the scale-out rule to handle CPU spikes, and finally, you add the scale-in rule with a 40% threshold to prevent autoscale flapping when the load drops.

Step-by-Step Solution

1
Scale up the App Service plan to the Standard (S1) tier.
The plan is updated to a SKU that supports custom autoscale rules.
The Free (F1) tier does not support autoscale features; Standard (S1) is the lowest pricing tier that supports custom autoscale.
2
Create the autoscale setting container.
An autoscale setting named autoscale-reports is created and linked to the App Service plan.
You cannot add rules without first creating an autoscale setting that defines the base instance limits.
3
Create the scale-out rule.
A scale-out rule is added to autoscale-reports to increase instances by 1 when average CPU exceeds 85% for 10 minutes.
This rule allows the web app to scale out during CPU spikes to maintain performance.
4
Create the scale-in rule.
A scale-in rule is added to autoscale-reports to decrease instances by 1 when average CPU is below 40% for 10 minutes.
This rule reduces costs when the CPU spikes subside, and the 40% threshold prevents flapping.

Key Concept

Scaling Azure App Service plans using the Azure CLI
Question 48Question →

You have an Azure subscription that contains a General Purpose v1 (GPv1) storage account named storage1 in a resource group named group1. You need to implement an Azure Blob Storage lifecycle management policy to automatically move inactive blobs to the Cool and Archive tiers. You plan to define the policy rules in a local file named policy.json and apply the policy using the Azure CLI. 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

To implement the lifecycle management policy, you must first upgrade the storage account from GPv1 to GPv2 because GPv1 does not support lifecycle policies. Next, you create the local policy.json file containing the policy rules. Then, you apply the policy to the storage account by running the az storage account management-policy create command. Finally, you verify that the policy is active by running the az storage account management-policy show command.
Upgrading the storage account from GPv1 to GPv2 is required first because lifecycle management policies are not supported on GPv1 accounts. Once upgraded, the rules must be defined in a JSON file. This file is then passed to the create command to apply the policy, and finally, the show command is run to verify the policy is active.

Step-by-Step Solution

1
Upgrade the storage account from General Purpose v1 (GPv1) to General Purpose v2 (GPv2).
The storage account is upgraded to GPv2, enabling support for lifecycle management policies.
Lifecycle management policies are only supported on General Purpose v2 (GPv2), Premium Block Blobs, and Blob Storage accounts.
2
Create the local policy.json file with the lifecycle rules.
The policy rules are defined in JSON format on the local machine.
The Azure CLI command to apply the policy requires a local path to a JSON file containing the policy rules.
3
Run the az storage account management-policy create command.
The lifecycle management policy is created and associated with the storage account.
This command applies the rules from the JSON file to the target storage account.
4
Run the az storage account management-policy show command.
The applied policy details are retrieved and displayed.
This confirms that the policy has been successfully configured and is active on the storage account.

Key Concept

Azure Blob Storage Lifecycle Management requires a GPv2 (or compatible) storage account and can be applied via the Azure CLI using a JSON policy file.
Question 49Question →

You are developing a .NET microservice that processes user orders in a multi-tenant SaaS application. Each tenant has their own partition in an Azure Cosmos DB SQL API container, and all operations within a single order lifecycle must be executed within a single transaction. You need to write C# code using the Azure Cosmos DB .NET SDK v3 to configure the client, access the container, and run a transactional batch of operations. In which sequence should you perform the steps to configure the client and execute the transactional batch?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To perform a transactional batch operation in Azure Cosmos DB using the .NET SDK v3, you must first initialize a singleton CosmosClient with the required options. Next, obtain the Database and Container references. Since transactional batches operate on a single logical partition, you must define the PartitionKey. Then, initialize the TransactionalBatch using CreateTransactionalBatch on the container with the partition key. Finally, chain the operations onto the batch and call ExecuteAsync.
The correct sequence starts with client initialization (CosmosClient), followed by drilling down to the specific database and container references. Because transactional batching in Azure Cosmos DB requires operations to share the same partition key, the PartitionKey instance must be defined prior to calling CreateTransactionalBatch on the container. Finally, individual operations are chained to the batch, and ExecuteAsync is called to execute the entire transaction.

Step-by-Step Solution

1
Initialize CosmosClient
An active connection client to the Azure Cosmos DB account.
CosmosClient is the top-level SDK client needed for all subsequent operations.
2
Obtain Container Reference
A Container object representing the target collection.
Container operations and transaction builders are scoped to the container level.
3
Define PartitionKey
A PartitionKey structure representing the tenant ID.
Azure Cosmos DB requires the logical partition key value to scope a transactional batch.
4
Build TransactionalBatch
A TransactionalBatch object initialized for the target partition key.
The CreateTransactionalBatch factory method on the container initiates the transactional workflow.
5
Chain Operations and Execute
A TransactionalBatchResponse containing the status and results of each chained operation.
Chained operations are added to the batch, and ExecuteAsync transmits them as a single atomic transaction.

Key Concept

Initiating CosmosClient, obtaining Container references, constructing a PartitionKey, and executing a TransactionalBatch with .NET SDK v3.
Question 50Question →

You are planning to deploy a containerized application to Azure Container Instances (ACI). The container requires access to a persistent volume hosted on an Azure File Share. You decide to use the Azure CLI to provision the resources and deploy the container. Which sequence of steps should you perform to create the storage resources and deploy the container with the mounted volume?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To deploy a container to Azure Container Instances with a mounted Azure File Share, you must first create the storage account, retrieve its access keys, create the file share within the storage account using those keys, and finally deploy the container group using the `az container create` command with the appropriate volume mount parameters.
The correct sequence starts with provisioning the physical storage account. Next, the access keys must be retrieved because they are required to authorize the creation of the file share and the subsequent mount operation. Once the keys are available, the file share is created. Finally, the container group is created using the container deployment command, which references the storage account, key, and share to mount the volume to the container.

Step-by-Step Solution

1
Create the storage account
A storage account is provisioned in Azure.
You need a storage account to host the Azure File Share.
2
Retrieve the storage account keys
The primary and secondary storage access keys are obtained.
The access keys are required to authenticate the creation of the file share and to allow ACI to mount the volume.
3
Create the Azure File Share
An SMB file share is created within the storage account.
ACI mounts an existing file share, so the share must exist prior to container deployment.
4
Deploy the container with the mounted volume
The ACI container group is created and the file share is mounted to the specified path.
The container group needs to reference the storage account credentials and share name at creation time to mount it.

Key Concept

Mounting an Azure File Share as a persistent volume in Azure Container Instances
Question 51Question →

You need to use the Azure CLI to create a new application registration in Microsoft Entra ID, instantiate its service principal, and grant the service principal Contributor access to a resource group.

Which sequence of commands should you perform? To answer, move all 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

The correct sequence of actions is: First, run `az login` to authenticate. Second, run `az ad app create` to register the application. Third, run `az ad sp create` to create a service principal for the registered application. Fourth, run `az role assignment create` to assign the Contributor role to the service principal.
The correct sequence begins with authenticating via `az login`. Next, the application registration must be created using `az ad app create` to obtain the Application ID. Then, a service principal must be instantiated in the tenant via `az ad sp create` using that Application ID. Finally, role-based access control (RBAC) is configured by running `az role assignment create` to grant the service principal the Contributor role.

Step-by-Step Solution

1
Run `az login` to authenticate the session.
The CLI session is authenticated with Azure.
Authentication is a prerequisite for executing any commands that interact with Azure resources or Microsoft Entra ID.
2
Run `az ad app create` to register the application.
The application object is created in Microsoft Entra ID, generating an Application (client) ID.
An application object must exist in the directory before a service principal can be created for it.
3
Run `az ad sp create` to create the service principal.
A service principal object is created in the tenant, linked to the application registration.
The service principal acts as the security identity (credential holder) that can be assigned roles in Azure.
4
Run `az role assignment create` to grant access.
The service principal is assigned the Contributor role on the resource group.
Azure RBAC roles can only be assigned to existing security principals, such as the newly created service principal.

Key Concept

An Application Registration creates the global definition of the application, while a Service Principal is the local representation (security principal) in a specific tenant that receives role assignments and permissions.
Estimated Time:1m 0s
Question 52Question →

You are developing a C# application using the Azure.Storage.Blobs SDK (v12). You need to add a new custom metadata tag to an existing blob while preserving all existing metadata on that blob. How should you order the steps to perform this update?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To update the custom metadata on an existing blob while preserving its current metadata, you must first call GetPropertiesAsync() on the BlobClient, extract the Metadata dictionary, update the dictionary with the new key-value pairs (omitting the x-ms-meta- prefix), and finally call SetMetadataAsync() with the updated dictionary.
To preserve existing metadata, the application must read the existing metadata first. This is done by calling GetPropertiesAsync() and accessing the Metadata dictionary. After modifying or adding entries to this dictionary (without adding the 'x-ms-meta-' prefix), the dictionary is passed to SetMetadataAsync() to update the blob.

Step-by-Step Solution

1
Retrieve current blob properties.
Obtained properties including the existing Metadata dictionary.
This is necessary to know the current metadata key-value pairs and avoid overwriting them entirely.
2
Access the Metadata dictionary.
An IDictionary<string, string> containing the current metadata is ready for modification.
By modifying the existing dictionary rather than creating a new one, existing metadata keys are preserved.
3
Modify the dictionary entries.
The dictionary contains new or updated metadata keys.
The key names should be clean (e.g., 'Project') rather than prefixed (e.g., 'x-ms-meta-Project') as the SDK handles the prefix internally.
4
Call SetMetadataAsync().
The metadata is saved to the blob on Azure Storage.
This uploads the updated metadata dictionary, completing the update operation.

Key Concept

Read-modify-write pattern for Azure Blob metadata operations
Question 53Question →

You are developing a lifecycle management policy for a Standard General Purpose v2 (GPv2) storage account to automate data tiering for telemetry log blobs. The storage account is configured with the following policy:

{
"rules": [
{
"name": "cool-rule",
"enabled": true,
"type": "Lifecycle",
"definition": {
"actions": {
"baseBlob": {
"tierToCool": {
"daysAfterModificationGreaterThan": 14
}
}
},
"filters": {
"blobTypes": ["blockBlob"],
"prefixMatch": ["telemetry/"]
}
}
},
{
"name": "archive-rule",
"enabled": true,
"type": "Lifecycle",
"definition": {
"actions": {
"baseBlob": {
"tierToArchive": {
"daysAfterModificationGreaterThan": 90
}
}
},
"filters": {
"blobTypes": ["blockBlob"],
"prefixMatch": ["telemetry/"],
"blobIndexMatch": [
{
"name": "Archivable",
"op": "==",
"value": "true"
}
]
}
}
}
]
}

A new block blob is uploaded to `telemetry/log1.txt`. You need to trace the lifecycle transitions of this blob based on the actions taken by the client application and the lifecycle execution engine. What is the correct sequence of events from the initial upload to the archiving of the blob? Arrange the events in chronological order.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct chronological sequence is: 1) Uploading the blob to the Hot tier on Day `00`, 2) Modifying the blob content on Day `1010` (resetting the Last-Modified time), 3) Transitioning to the Cool tier on Day `2424` after `1414` days of no modification, 4) Tagging the blob as Archivable=true on Day `5050` (without updating Last-Modified), and 5) Transitioning to the Archive tier on Day `100100` after `9090` days of no modification.
The correct order follows the chronological progression of the blob's lifecycle. Content modifications reset the Last-Modified timestamp, whereas setting blob index tags does not. This means the transition to Cool happens `1414` days after the content update (Day `2424`), and the transition to Archive happens `9090` days after the content update (Day `100100`), provided the index tag filter matches.

Step-by-Step Solution

1
Upload the blob to initialize the lifecycle.
The blob is placed in the Hot tier, and the Last-Modified time is set to Day `00`.
Lifecycle management calculations are relative to the Last-Modified timestamp.
2
Modify the blob content on Day `1010`.
The Last-Modified timestamp updates to Day `1010`, resetting the age calculation.
Modifying content alters the blob and resets the `daysAfterModificationGreaterThan` counter.
3
Evaluate the cool rule after `1414` days.
The blob transitions to the Cool tier on Day `2424`.
The blob has been unmodified for `1414` days since Day `1010`, matching the first rule's filter.
4
Tag the blob with index tags on Day `5050`.
The tag `Archivable=true` is applied, but the Last-Modified timestamp remains Day `1010`.
Tag updates do not alter the Last-Modified property, meaning the clock does not reset.
5
Evaluate the archive rule after `9090` days.
The blob transitions to the Archive tier on Day `100100`.
The blob has been unmodified for `9090` days since Day `1010`, and it matches the index tag filter required by the second rule.

Key Concept

Understanding how blob lifecycle transitions are calculated using the Last-Modified timestamp, how content modifications reset this timestamp, and how metadata/tag operations do not affect it.
Question 54Question →

You are developing a software release pipeline using Azure Durable Functions. The workflow is written in C# (.NET Isolated process) and must implement a gated approval step. The orchestrator must send an approval notification to a release manager, wait for up to 24 hours for a response via an external event, and then either proceed with the deployment or cancel it. If the manager responds before the timeout, the workflow must prevent the timer from running to completion to avoid unnecessary execution.

Move the steps required to implement this gated approval pattern within the orchestrator function into the correct execution sequence.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins with notifying the manager, setting up the timer and event tasks, waiting for either task to resolve, canceling the timer if the event is received first, and finally triggering the appropriate deployment or cleanup activity.
In a C# Durable Functions orchestrator implementing a human interaction pattern with a timeout, the orchestrator first calls an activity to send the notification. Next, it must define the timer (linked to a cancellation token) and the external event listener. It then blocks execution using Task.WhenAny to wait for whichever occurs first. If the event occurs first, it is critical to cancel the timer using the CancellationTokenSource to prevent it from executing at a later time. Finally, the orchestrator calls the corresponding activity based on the outcome.

Step-by-Step Solution

1
Call the activity function to send the approval request notification.
The manager is notified, and the workflow is ready to wait for input.
This initiates the human interaction process.
2
Create a CancellationTokenSource and instantiate both the durable timer and the external event tasks.
Two unresolved Task objects represent the timer and the external event.
Both tasks must exist in memory before they can be evaluated concurrently.
3
Await Task.WhenAny with both the timer and event tasks as inputs.
The orchestrator yields and remains suspended until either the timer expires or the external event is received.
This allows the orchestrator to resume immediately upon the first completed action.
4
Check if the external event task resolved first; if so, call Cancel on the CancellationTokenSource.
The durable timer is canceled in the Azure Functions backend.
This prevents the timer from firing, which is a best practice to avoid billing overhead and storage leaks.
5
Examine the result of the completed task and call either the deployment or cleanup activity.
The deployment is executed if approved, or the release is cancelled/notified if rejected or timed out.
This completes the lifecycle of the approval gate workflow.

Key Concept

Implementing the Human Interaction pattern with timeouts in Azure Durable Functions using CancellationTokenSource and Task.WhenAny.
Estimated Time:2m 30s
Question 55Question →

You are deploying updates to an Azure Function App (V4 runtime) running on an Elastic Premium hosting plan. The function app connects to an Azure SQL Database.

You must implement a deployment process that meets the following requirements:
- Updates must be tested in a staging environment before being routed to production.
- Zero downtime must occur during the deployment transition.
- The staging and production environments must use different database connection strings.
- Database connection strings must not be swapped when the update goes live.

You need to configure the deployment slots and perform the deployment.

Which sequence of actions should you perform? To answer, move all 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, create a deployment slot named staging under the Function App. Second, define the database connection string application setting in both slots and configure it as a deployment slot setting. Third, deploy the updated function code to the staging slot. Fourth, verify the function behavior and warm up the instance in the staging slot. Finally, swap the staging slot with the production slot.
The correct sequence begins with creating the staging deployment slot, then marking the connection string setting as a deployment slot setting (sticky) to prevent it from swapping. Next, the updated function code is deployed to the staging slot and verified/warmed up. Finally, the staging slot is swapped with production, achieving a zero-downtime release with slot-specific database connections intact.

Step-by-Step Solution

1
Create the staging deployment slot.
An isolated staging slot environment is established under the Function App.
This establishes the target environment for the staging deployments and configurations.
2
Configure the connection string setting as a deployment slot setting.
The setting is marked as 'sticky' to the slot.
Marking it as a deployment slot setting ensures the database connection strings are not swapped when slot swap occurs, keeping each slot connected to its correct database.
3
Deploy the updated function code to the staging slot.
The staging slot runs the new version of the function.
Deploying to the staging slot first prevents immediate exposure of unverified code to production users.
4
Verify behavior and warm up the function.
The staging instances are initialized and verified.
Warming up the instances prevents cold-start latency when traffic is switched, and verification ensures the code functions correctly under staging settings.
5
Swap the staging slot with the production slot.
Production traffic is routed to the new code, while the database connection strings remain in their respective slots.
Swapping the slots updates the production environment with zero downtime.

Key Concept

Azure Functions deployment slots configuration and swap process
Question 56Question →

An organization uses a Standard General Purpose v2 (GPv2) storage account to store compliance reports in a container. A lifecycle management policy is active with a rule that transitions all blobs in the container to the Archive tier 30 days after they are last modified. The lifecycle management policy executes once every 24 hours.

You need to rehydrate an archived blob named `reports/2025_audit.pdf` to the Hot tier to perform a 5-day audit analysis. You must ensure that the lifecycle management policy does not transition the blob back to the Archive tier during the 5-day analysis period.

Which sequence of 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

To safely rehydrate the blob and prevent it from being immediately re-archived, first initiate the rehydration by setting the blob's tier to Hot. Next, wait for the rehydration process to complete and the blob's status to transition to Hot. Then, perform a metadata write operation to update the Last-Modified timestamp. Finally, begin the 5-day audit analysis and perform the required read operations.
The correct order requires first initiating the rehydration of the blob to the Hot tier because it is currently offline and metadata writes are blocked. Once rehydration completes, you must perform a metadata write operation (such as setting dummy metadata properties) to update the Last-Modified timestamp. Since the lifecycle management policy evaluates the last-modified time and runs once every 24 hours, updating the metadata resets the lifecycle clock and prevents the policy from re-archiving the blob during the 5-day audit analysis.

Step-by-Step Solution

1
Call Set Blob Tier to transition the blob to the Hot tier.
The blob status changes to rehydrate-pending-to-hot.
The blob must be rehydrated from the Archive tier before its data can be read or its metadata updated.
2
Monitor the blob properties and wait for the tier to transition to Hot.
The blob tier becomes Hot and the pending status clears.
You must wait for the blob to be online in the Hot tier before any metadata write operations can be performed.
3
Update the blob's metadata or properties.
The blob's Last-Modified timestamp is updated to the current date and time.
Changing a blob's tier via Set Blob Tier does not update its Last-Modified time. Because the policy archives blobs older than 30 days and runs every 24 hours, the policy would archive the blob again on its next execution unless the Last-Modified timestamp is refreshed.
4
Perform the required read operations for the 5-day audit analysis.
The audit analysis is completed while the blob remains in the Hot tier.
The updated Last-Modified timestamp ensures the lifecycle policy will not archive the blob for another 30 days.

Key Concept

Rehydrating blobs from the Archive tier and preventing immediate re-archiving by updating the Last-Modified timestamp via metadata modifications.
Question 57Question →

You are deploying an Azure Container App named report-generator to an Azure Container Apps Environment. The Container App must read template files and write generated reports to a persistent, shared file share. You have already created an Azure Storage account. You need to configure the Container App to mount the Azure file share. Which sequence of steps should you perform?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

First, create an Azure file share in the Storage account. Second, link the file share to the Container Apps Environment. Third, define a volume in the Container App configuration referencing the environment storage. Fourth, configure a volume mount in the container template to bind the volume to a directory path.
The correct sequence starts with provisioning the physical Azure File Share, registering it at the environment level to expose it to the container apps, defining the volume resource in the container app's template, and finally mapping that volume to a path within the container.

Step-by-Step Solution

1
Create the Azure file share in the Azure Storage account.
A physical file share is created and ready for connection.
The file share must exist before the Container Apps Environment can connect to it.
2
Run the az containerapp env storage set command to link the share to the Environment.
The file share is registered as an environment-level storage resource.
This makes the storage share accessible by any Container App running in that specific environment.
3
Define a volume under the template properties of the Container App configuration.
The volume is defined and linked to the registered environment storage.
The Container App must declare the volume at the template level before any container can mount it.
4
Add a volumeMounts entry in the container definition pointing to the volume.
The volume is mounted to a specific container path.
This maps the template volume to a path in the container's file system where the application can read and write files.

Key Concept

Azure Container Apps storage mounting requires linking the Azure file share at the Container Apps Environment level before defining it as a volume and mounting it inside individual containers.
Question 58Question →

You are developing a multi-tenant web application that will be used by other organizations. The application requires delegated access to Microsoft Graph. You need to configure the application registration and ensure that a customer's tenant administrator can consent to the application and assign users to it.

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

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence is to register the application as multi-tenant, configure the delegated API permissions, direct the customer's tenant administrator to grant consent to instantiate the service principal, and finally assign users or groups to the service principal in the customer's tenant.
The correct sequence begins by registering the application as multi-tenant to establish its identity. Next, the developer defines the required delegated API permissions on the application registration. After deployment, the customer's administrator must grant consent, which instantiates the service principal in the customer's tenant. Only after the service principal exists can the customer administrator assign users or groups to it.

Step-by-Step Solution

1
Register the application in the home tenant as multi-tenant.
Creates the application object with a unique Application (client) ID that is accessible by other tenants.
You must establish the identity of the application before you can configure its permissions or seek consent.
2
Configure the required delegated API permissions in the application registration.
Defines the specific access scopes (such as Microsoft Graph) that the application will request.
The permissions must be declared on the application registration so that administrators can consent to them.
3
Direct the customer's tenant administrator to the admin consent endpoint.
The administrator consents, which automatically instantiates a service principal (enterprise application) in the customer's tenant.
A service principal must exist in the customer's tenant to represent the application and hold permissions within that tenant.
4
Assign users or groups to the service principal in the customer's tenant.
Limits or delegates application access to specific users or groups within the customer's organization.
Users cannot be assigned to an application in the customer's tenant until the service principal has been created in that tenant.

Key Concept

Multi-tenant application registration, consent flow, and service principal instantiation
Estimated Time:2m 0s
Question 59Question →

You are developing a web application named webapp1 hosted on a Windows-based Azure App Service in resource group rg1. During a testing phase, you need to diagnose startup crashes by enabling filesystem-based application logging, establishing a real-time log monitoring pipeline, triggering runtime execution, and obtaining the complete diagnostic log archive for offline verification. Which sequence of actions should you perform? Arrange the actions in the correct order.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

First, configure application logging to the file system using the `az webapp log config` command. Next, start the live log stream with `az webapp log tail`. Following that, make HTTP requests to the web application to generate traffic and write to the logs. Finally, download the historical log archive using `az webapp log download`.
The correct order proceeds from configuring the underlying log system, setting up the observer stream, triggering the target event, and finally downloading the persistent historical records. File-system application logging must first be enabled because it is disabled by default. Running the tail command next ensures that any live events generated during the subsequent HTTP requests are captured in the terminal stream. Finally, downloading the log bundle retrieves the full persistent log folder for subsequent analysis.

Step-by-Step Solution

1
Enable and configure application filesystem logging using Azure CLI.
App Service configures the application log buffer to write errors to the local virtual filesystem.
By default, application logging to the filesystem is disabled, so configuring it is a prerequisite for capturing log traces.
2
Initiate the log streaming pipeline in the terminal.
A streaming channel is opened to capture stdout/stderr and trace events from the App Service.
To observe real-time startup errors or execution traces, the stream tail must be active before triggering the workflow.
3
Generate traffic to the application.
The web application processes the requests, encountering errors that are outputted to the active streaming session.
Without HTTP request traffic or application runtime events, no logs will be generated to populate the active log stream.
4
Download the diagnostic log zip file.
A zip file containing all log subdirectories (such as LogFiles/Application/) is downloaded locally.
Downloading the archive is the final step to keep a permanent offline record of all generated diagnostic files.

Key Concept

Azure App Service Application Diagnostics and CLI Logging Commands
Estimated Time:2m 0s
Question 60Question →

You are a developer implementing a data retention strategy for a Standard General Purpose v2 (GPv2) storage account. You need to configure Azure Blob Storage Lifecycle Management to automatically transition older, historical versions of blobs (noncurrent versions) to the Cool tier. You plan to configure and test this policy using the Azure CLI.

Arrange the steps in the correct order to configure the storage account, define the policy, and verify that a blob version is subject to the policy.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To implement lifecycle management for noncurrent blob versions, first enable blob versioning on the storage account. Next, define the lifecycle rules targeting the noncurrent versions in a local JSON policy file. Then, use the Azure CLI command to deploy the policy. Finally, overwrite a blob to create a noncurrent version to test the policy.
The correct sequence begins with enabling versioning on the storage account so that history tracking is active. Then, the JSON policy is defined to target noncurrent versions. This JSON file is then deployed using the Azure CLI. Finally, a blob is overwritten to create a noncurrent version, which will be processed by the lifecycle management rules during the next execution cycle.

Step-by-Step Solution

1
Enable blob versioning on the Standard GPv2 storage account.
The storage account is configured to preserve previous states of blobs as noncurrent versions when they are updated or deleted.
Lifecycle rules cannot act on noncurrent versions unless versioning is enabled first to track those versions.
2
Create a JSON policy file defining rules that specify actions under the version block.
A policy document is prepared that targets noncurrent versions for tiering (e.g., transition to Cool).
The Azure CLI requires a local JSON file path to apply the policy configuration.
3
Execute the az storage account management-policy create command referencing the JSON file.
The lifecycle policy is successfully applied to the Azure Storage account.
The policy must be applied in Azure before any data modifications can be evaluated against it.
4
Overwrite an existing blob.
A new current version is written, and the previous content is preserved as a noncurrent version.
This generates the target version entity required to test the lifecycle transition rule.

Key Concept

Azure Blob Storage Lifecycle Management with Blob Versioning
PreviousPage 3 / 9Next
All practice questions — Microsoft Azure Developer (AZ-204) | Examkin