All practice questions

972 questions

Question 921Question

You are developing a C# application using the Azure.Storage.Blobs SDK (v12). The application must perform a concurrency-safe update to an existing blob named `configuration.json` by acquiring a 30-second exclusive-write lease, uploading the new content, and then immediately releasing the lease.

How should you order the developer's actions to achieve this workflow?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order of operations is to first initialize the BlobClient, instantiate the BlobLeaseClient, acquire the lease, upload the content using the lease ID, and finally release the lease.
To perform a leased upload operation, you must first create a `BlobClient` to target the blob. Next, you construct a `BlobLeaseClient` using the `BlobClient`. You then acquire the lease to obtain a lease ID. With this lease ID, you can perform the upload by specifying it in the `BlobUploadOptions`. Finally, you release the lease to free the resource.

Step-by-Step Solution

1
Initialize a `BlobClient`.
An active reference to the `configuration.json` blob is established.
A client reference is required to interact with the blob and to initialize the lease client.
2
Instantiate a `BlobLeaseClient` using the `BlobClient`.
A lease client is created.
In modern SDK v12, lease operations are handled via the specialized `BlobLeaseClient`.
3
Call `AcquireAsync` on the lease client.
An exclusive-write lease is acquired on the blob, returning a unique lease ID.
The lease ID is necessary to perform write operations on the leased blob.
4
Call `UploadAsync` on the `BlobClient` with `BlobUploadOptions` containing the lease ID.
The blob content is safely updated.
The lease ID must be passed to satisfy the concurrency constraint of the active lease.
5
Call `ReleaseAsync` on the lease client.
The lease is released.
Releasing the lease allows other clients to perform modifications without waiting for the lease duration to expire.

Key Concept

Blob Lease Management Workflow using Azure Storage SDK
Question 922Question

You are developing a C# application that manages document archiving using the Azure.Storage.Blobs SDK (version 12). You write the following helper method to process and archive blobs:

csharp
public static async Task ArchiveBlobAsync(BlobClient blobClient, string user)
{
// Retrieve existing properties
BlobProperties properties = (await blobClient.GetPropertiesAsync()).Value;

// Check if the blob has a classification
if (properties.Metadata.ContainsKey("Classification"))
{
Console.WriteLine($"Classification: {properties.Metadata[\"Classification\"]}");
}

// Add the archival metadata
var metadata = new Dictionary<string, string>
{
{ "ArchivedBy", user }
};
await blobClient.SetMetadataAsync(metadata);

// Transition the blob to the Cool tier
await blobClient.SetAccessTierAsync(AccessTier.Cool);
}

Which of the following statements regarding the behavior or issues in this code are correct? (Select TWO)

Select all that apply

Show answer & explanation

Answer: The check properties.Metadata.ContainsKey("Classification") will evaluate to false even if a metadata key named "Classification" exists on the blob, because Azure Blob Storage returns metadata keys in lowercase.; Calling SetMetadataAsync(metadata) will clear all existing custom metadata on the blob, leaving only the "ArchivedBy" metadata key.

Answer

The check for the 'Classification' key will evaluate to false because keys are returned in lowercase, and calling SetMetadataAsync will overwrite and delete all existing metadata on the blob.
The correct statements identify that metadata keys are returned in lowercase by the storage service, causing case-sensitive checks for 'Classification' to fail, and that SetMetadataAsync replaces the entire metadata collection, which deletes any existing metadata not included in the input dictionary.

Step-by-Step Solution

1
Analyze metadata retrieval behavior in the .NET SDK via GetPropertiesAsync.
The Metadata dictionary keys are populated in lowercase because Azure Blob Storage returns them as lowercase HTTP headers.
Checking for uppercase keys like 'Classification' using ContainsKey will return false.
2
Analyze metadata update behavior via SetMetadataAsync.
The call replaces the entire metadata collection with the new dictionary.
All existing custom metadata keys not included in the new dictionary will be deleted.
3
Verify lease and access tier conditions.
Updating metadata on a leased blob requires specifying the lease ID, and setting the access tier does not bypass this requirement if a lease is present.
Ensures correct understanding of concurrency and access tier operations.

Key Concept

Managing Blob properties, metadata, and access tiers in C# using the Azure SDK.
Question 923Question

You are developing a secure C# .NET console application that uses the `Azure.Security.KeyVault.Certificates` SDK. The application must provision a new SSL/TLS certificate inside Azure Key Vault. Your organization requires that the certificate be signed by an internal corporate Certificate Authority (CA) that is not integrated with Azure Key Vault. You need to complete the process of generating the certificate while keeping the private key secure within the key vault. Arrange the steps in the correct order to configure, sign, and complete the certificate creation process.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

First, start the certificate creation process using a policy with the issuer specified as 'Unknown'. Second, retrieve the pending certificate operation to extract the generated Certificate Signing Request (CSR). Third, submit the CSR to the non-integrated Certificate Authority to obtain the signed certificate. Finally, merge the signed certificate back into Azure Key Vault using the certificate client to complete the operation.
The correct sequence starts with initiating the request in Key Vault using 'Unknown' as the issuer, which forces the key vault to generate the private key and prepare a pending operation. Next, the pending operation is queried to extract the CSR. Then, the CSR is signed by the external CA. Finally, the signed certificate is merged back into Key Vault to associate it with the private key and activate the certificate resource.

Step-by-Step Solution

1
Initiate the creation request using `CertificateClient.StartCreateCertificateAsync` with a policy where `IssuerName` is set to "Unknown".
A pending `CertificateOperation` is created inside Azure Key Vault, and the private key is generated within the vault.
Azure Key Vault must generate the public/private key pair and create a CSR. Setting the issuer to "Unknown" is required for non-integrated CAs.
2
Query the key vault to retrieve the active `CertificateOperation` and extract the CSR from its properties.
The base64-encoded CSR string is retrieved.
The CSR is needed so that the external CA can sign it, confirming the identity and public key details.
3
Submit the CSR to the external CA and download the signed certificate chain.
The signed X.509 certificate file containing the certificate chain.
The external CA acts as the trust anchor and signs the public key provided in the CSR.
4
Call `CertificateClient.MergeCertificateAsync` to import the signed certificate.
The certificate operation is completed, and the active certificate is now available in Azure Key Vault.
Merging associates the signed certificate with the private key that remained securely inside Key Vault, finalizing the enrollment lifecycle.

Key Concept

Azure Key Vault Certificate Enrollment with Non-Integrated Certificate Authorities
Question 924Question

You are configuring a canary deployment for an Azure Container App named `web-shop`. The application is configured to run multiple active revisions. You have deployed a new revision named `web-shop--v2`, and the existing revision is named `web-shop--v1`.

You need to configure the HTTP ingress of the Container App to route 80%80\% of the incoming traffic to `web-shop--v1` and the remaining 20%20\% to `web-shop--v2`.

Which configuration block should you include under the `properties.configuration.ingress` section of the Container App Bicep template?

Show answer & explanation

Answer: traffic: [
{
revisionName: 'web-shop--v1'
weight: 80
}
{
revisionName: 'web-shop--v2'
weight: 20
}
]

Answer

The correct block must define the 'traffic' array with objects specifying 'revisionName' as 'web-shop--v1' and 'web-shop--v2', and 'weight' as the integers 80 and 20 respectively.
The correct configuration uses the 'traffic' block under 'properties.configuration.ingress'. In this block, you specify the active revisions using the 'revisionName' property and allocate the traffic share as an integer percentage using the 'weight' property. This allows the Container App to balance traffic according to the specified weights.

Step-by-Step Solution

1
Locate the 'ingress' property under 'properties.configuration' in the Container App template.
Confirm where traffic routing rules are defined.
Traffic splitting is configured at the ingress level of the application.
2
Add the 'traffic' array containing an entry for each active revision.
Ensure both 'web-shop--v1' and 'web-shop--v2' are targeted.
To split traffic, each target revision must have a defined entry in the array.
3
Use the 'revisionName' property to specify the revision and the 'weight' property with an integer value to define the traffic share.
Assign a weight of 80 to the first revision and 20 to the second revision.
The weight must be an integer, and the property names must strictly match the Azure resource provider specification.

Key Concept

Configuring traffic splitting for multiple revisions in Azure Container Apps ingress.
Question 925Question

You are developing a C# backend application that uses the Azure.Storage.Blobs SDK (v12) to manage resources in Azure Blob Storage. A blob contains custom metadata with a key named `ProjectOwner`.

You retrieve the properties of the blob using the following code:
csharp
BlobProperties properties = (await blobClient.GetPropertiesAsync()).Value;

Which code segment should you use to retrieve the value of the `ProjectOwner` custom metadata key?

Show answer & explanation

Answer: string owner = properties.Metadata["ProjectOwner"];

Answer

The correct code segment is: string owner = properties.Metadata["ProjectOwner"];
The correct answer correctly queries the dictionary using the key name without the 'x-ms-meta-' prefix. In the Azure.Storage.Blobs SDK, the HTTP response headers are parsed, and the metadata keys are mapped directly into a dictionary with the prefix removed.

Step-by-Step Solution

1
Retrieve the properties of the blob from Azure Storage.
A Response containing the BlobProperties object is returned from the GetPropertiesAsync call.
Before metadata can be accessed, we must query the blob properties from the service.
2
Access the Metadata dictionary.
The Metadata IDictionary is accessed from the BlobProperties instance.
User-defined metadata is stored inside the Metadata property of BlobProperties.
3
Retrieve the value using the key name without the HTTP header prefix.
The value of the 'ProjectOwner' metadata key is successfully retrieved.
The SDK strips 'x-ms-meta-' prefixes from HTTP response headers before populating the dictionary.

Key Concept

Retrieval of custom blob metadata via the C# SDK without HTTP header prefixes
Estimated Time:1m 0s
Question 926Question

An enterprise application requires Azure API Management (APIM) to forward client requests to a backend web API that is secured via Microsoft Entra ID. The backend web API expects tokens containing the audience claim https://backend.contoso.com. To facilitate cross-environment deployments, you create a user-assigned managed identity named apim-identity and associate it with your APIM instance. You need to configure APIM to authenticate using this specific identity when calling the backend. Which configuration should you apply to the APIM policy?

Show answer & explanation

Answer: Add the authentication-managed-identity policy inside the <inbound> policy block, setting the resource attribute to https://backend.contoso.com and the client-id attribute to the client ID of apim-identity.

Answer

Add the authentication-managed-identity policy inside the <inbound> policy block, setting the resource attribute to https://backend.contoso.com and the client-id attribute to the client ID of apim-identity.
To authenticate to a backend API using a user-assigned managed identity, you must use the authentication-managed-identity policy. This policy must be configured in the inbound processing section so that the bearer token is attached to the request before it is forwarded to the backend. Because multiple user-assigned identities can be associated with an APIM instance, you must explicitly specify the client ID of the desired identity in the policy configuration.

Step-by-Step Solution

1
Identify the required policy to acquire a token using a managed identity.
The authentication-managed-identity policy is chosen.
This policy natively handles the acquisition and configuration of Entra ID access tokens for backend communication.
2
Determine the correct policy section for modifying the backend request.
The policy is placed in the inbound block.
To authenticate requests sent to the backend, the authorization token must be set before the request is forwarded by the gateway.
3
Configure the parameters to identify the user-assigned identity.
Set the resource attribute to the audience URI and the client-id attribute to the Client ID of the user-assigned identity.
Because an APIM instance can have multiple user-assigned identities, the client ID is required to specify which identity should acquire the token.

Key Concept

Securing API Management backend connections using a user-assigned managed identity.
Question 927Question

An organization is transitioning its Azure resources to use Azure Role-Based Access Control (RBAC) instead of Key Vault access policies. A developer needs to ensure that an Azure Web App can retrieve secrets from a Key Vault named kv-prod using its system-assigned managed identity.

Which configuration change must be performed to allow the Web App to retrieve the secrets?

Show answer & explanation

Answer: Set the Key Vault permission model to Azure RBAC, and assign the Key Vault Secrets User role to the Web App's managed identity.

Answer

Set the Key Vault permission model to Azure RBAC, and assign the Key Vault Secrets User role to the Web App's managed identity.
Setting the Key Vault permission model to Azure RBAC and assigning the Key Vault Secrets User role is correct because the Key Vault Secrets User role provides the necessary data-plane permissions to read secret values, and system-assigned managed identities are fully compatible with Azure RBAC.

Step-by-Step Solution

1
Select the correct permission model on the Key Vault.
The Key Vault is configured to authorize data-plane operations using Azure role-based access control (Azure RBAC).
This is required to shift from the legacy Key Vault access policies to RBAC-based authorization.
2
Assign the appropriate data-plane role to the application's identity.
The system-assigned managed identity of the Web App is assigned the Key Vault Secrets User role.
The Key Vault Secrets User role is the specific built-in role designed to allow reading secret contents (secrets/get) without granting administrative control.

Key Concept

Key Vault access authorization model transition and data-plane role assignment
Estimated Time:1m 0s
Question 928Question

You are developing a secure client-side Single Page Application (SPA) named OrderClient and a backend Web API named OrderProcessor. The OrderClient application must make HTTP requests to OrderProcessor to retrieve order history on behalf of the currently signed-in user. You need to configure the Microsoft Entra ID app registrations for both applications to secure the API calls using OAuth 2.0. Which of the following configurations should you implement?

Show answer & explanation

Answer: In the OrderProcessor app registration, configure the Application ID URI to api://<OrderProcessor-ClientId>, expose a delegated scope named Orders.Read, and in the OrderClient app registration, add the delegated permission api://<OrderProcessor-ClientId>/Orders.Read.

Answer

Configuring a delegated scope on the backend Web API registration and granting it as a delegated permission to the SPA registration.
Configuring a delegated scope on the backend Web API and granting it to the SPA registration correctly enforces OAuth 2.0 delegated authorization. Using the Application ID URI prefix ensures the scope is globally unique in Microsoft Entra ID, allowing the client application to obtain tokens specifically for that resource.

Step-by-Step Solution

1
Identify the application architecture and user context.
The client is a Single Page Application (SPA) calling a backend Web API on behalf of a signed-in user.
This establishes that delegated permissions (scopes) are required rather than application permissions (App Roles) or managed identities.
2
Expose the custom scope on the backend Web API registration.
Configure an Application ID URI (e.g., api://<OrderProcessor-ClientId>) and define a delegated scope (e.g., Orders.Read).
Microsoft Entra ID requires custom API scopes to be prefixed with the Application ID URI to ensure global uniqueness.
3
Grant the delegated permission to the client application registration.
Add the fully qualified scope URI (api://<OrderProcessor-ClientId>/Orders.Read) to the client application's requested API permissions.
This allows the SPA to request access tokens containing the custom scope during the OAuth 2.0 authorization code flow.

Key Concept

Microsoft Entra ID Delegated Permissions and Custom API Scopes
Question 929Question

You are developing a C# backend service that manages delivery truck configurations using the Azure Cosmos DB .NET SDK v3. The container is configured with Session consistency and uses `/fleetId` as the partition key path.

The application runs on multiple independent Azure App Service instances behind a load balancer. You need to implement a workflow where one instance updates a truck configuration (with `id` of `truck-99` and `fleetId` of `fleet-west`) and another instance immediately reads the updated configuration, guaranteeing a read-your-writes level of consistency.

Which code snippet should you use?

Show answer & explanation

Answer: // Instance 1: Update the configuration and extract the session token
ItemResponse<TruckConfig> writeResponse = await container.ReplaceItemAsync<TruckConfig>(
updatedConfig,
"truck-99",
new PartitionKey("fleet-west")
);
string token = writeResponse.Headers.Session;

// Instance 2: Read the configuration using the session token
ItemResponse<TruckConfig> readResponse = await container.ReadItemAsync<TruckConfig>(
"truck-99",
new PartitionKey("fleet-west"),
new ItemRequestOptions { SessionToken = token }
);

Answer

The code snippet that extracts the session token from the write response headers and passes it in the ItemRequestOptions when performing the read operation.
The correct code snippet retrieves the session token from the write response headers on the first instance and passes it to the read operation on the second instance using the SessionToken property of ItemRequestOptions. This ensures that the second instance reads from a replica that has been updated with the write from the first instance.

Step-by-Step Solution

1
Analyze the consistency requirements
The application uses Session consistency, which guarantees read-your-writes within the same client session. However, because the application runs on multiple independent Azure App Service instances, each instance will have its own CosmosClient and thus a different client session.
Understanding the scope of Session consistency across multiple client sessions is critical to identifying why the session token must be shared.
2
Determine the mechanism to share the session context
To achieve read-your-writes consistency across different client sessions, the session token must be explicitly passed from the writer instance to the reader instance.
Explicitly passing the session token allows the reader client to request data from a replica that has caught up to at least the transaction indicated by the token.
3
Identify the correct SDK v3 methods and parameters
Use ReplaceItemAsync to write the update, extract the session token via writeResponse.Headers.Session, and pass it to ReadItemAsync using ItemRequestOptions. The partition key must be 'fleet-west' as the container is partitioned by '/fleetId'.
This matches the C# SDK v3 syntax and complies with the partition key path requirement.

Key Concept

Managing Session consistency scope across multiple SDK client instances using session tokens.
Question 930Question

You are configuring a Bicep template to deploy an Azure Container App named `order-processor`. The application needs to connect to a database using a connection string that is stored as a secret in Azure Key Vault. The connection string must be exposed to the container as an environment variable named `DB_CONNECTION`. Which of the following configuration steps must you perform in the Bicep template to meet these requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Define a secret in the `configuration.secrets` block of the Container App, specifying the secret's name, Key Vault secret URL, and the managed identity resource ID.; In the container's `env` array, add an environment variable named `DB_CONNECTION` that references the defined secret using the `secretRef` property.

Answer

To configure the Container App to use a Key Vault secret as an environment variable, you must define the secret in the `configuration.secrets` block of the Container App resource pointing to the Key Vault secret URL with a managed identity, and reference that secret name via the `secretRef` property in the container's environment variables array.
To successfully pull a secret from Key Vault and inject it into a Container App container as an environment variable, two configuration steps are required. First, the secret must be declared in the Container App's configuration section, linking the secret name to the Key Vault URL and specifying which identity has the permission to read it. Second, the container's environment variable array must reference the secret's name using the `secretRef` property.

Step-by-Step Solution

1
Expose the Key Vault secret to the Container App configuration.
A secret is declared in `configuration.secrets` referencing the Key Vault URL and a managed identity that has permissions to read it.
Azure Container Apps requires Key Vault secrets to be declared at the resource level before they can be referenced by individual containers.
2
Map the declared secret to the container's environment variables.
The container configuration includes an environment variable with a `secretRef` pointing to the declared secret.
This injects the secret value into the container's runtime environment under the specified variable name without exposing the plaintext value in the template.

Key Concept

Configuring secrets and environment variables in Azure Container Apps using Key Vault references.
Estimated Time:1m 30s
Question 931Question

You need to configure an Azure App Service web app to retrieve configuration settings from an Azure App Configuration store. The solution must use a user-assigned managed identity.

Which sequence of actions should you perform? Arrange the actions in the correct order from first to last.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence is: Create the user-assigned managed identity; grant the identity the App Configuration Data Reader role on the configuration store; configure the App Service to use the identity; and add the configuration store's endpoint URI to the App Service settings.
To secure App Configuration access using a user-assigned managed identity, you must first create the identity. Next, you assign the necessary RBAC permissions (App Configuration Data Reader role) to the identity. After permissions are set, you link the identity to the App Service web app. Lastly, you define the App Configuration endpoint inside the App Service settings so that the app code knows where to fetch settings using the assigned identity.

Step-by-Step Solution

1
Create a user-assigned managed identity.
A standalone security principal is created.
You need a security principal to grant permissions to and associate with the App Service.
2
Assign the App Configuration Data Reader role to the identity on the App Configuration store.
The identity receives read access to the configuration store.
This establishes access control permissions for the identity.
3
Associate the identity with the App Service web app.
The App Service is configured to use the identity for outbound calls.
The web app must have the identity linked to authenticate requests under it.
4
Add the App Configuration store endpoint to the App Service application settings.
The web app is configured with the target configuration store URI.
The application code needs this endpoint configuration to locate and fetch settings from the store.

Key Concept

Configuring access to Azure App Configuration using a user-assigned managed identity
Question 932Question

You manage a memory-intensive web application named PatientPortalAPI that is currently hosted on a Shared (D1) App Service plan. During peak usage hours, the application experiences memory spikes exceeding 75%, causing it to become unresponsive. You must configure the application to dynamically scale out by adding instances when memory usage exceeds 75%, and automatically scale in when the load subsides. Which of the following actions should you perform to meet these requirements?

Show answer & explanation

Answer: Scale up the App Service plan to the Standard (S1) tier, and then configure an autoscale rule with a scale-out threshold of 75% memory and a scale-in threshold of 50% memory.

Answer

Scale up the App Service plan to the Standard (S1) tier, and then configure an autoscale rule with a scale-out threshold of 75% memory and a scale-in threshold of 50% memory.
To configure autoscale rules, the App Service plan must be scaled up to at least the Standard (S1) tier, as the Shared (D1) and Basic (B1) tiers do not support autoscaling. Furthermore, to prevent autoscale flapping, the scale-in threshold must be set to a value significantly lower than the scale-out threshold. A scale-in threshold of 50% ensures that the resource consumption drops below a safe level before removing an instance, whereas a threshold of 80% is higher than the scale-out trigger (75%) and would cause immediate scale-in loop behavior.

Step-by-Step Solution

1
Determine the minimum App Service plan tier required to configure autoscale rules.
The Standard (S1) or higher pricing tier must be selected, as Shared (D1) and Basic (B1) tiers do not support autoscale rules.
Azure App Service autoscale rules require at least the Standard tier.
2
Determine the scale-in threshold that avoids autoscale flapping.
A scale-in threshold must be lower than the scale-out threshold and should account for the distributed load reduction on scaled-out instances.
If the scale-in threshold is too high (such as 80% when the scale-out threshold is 75%), the system will immediately scale in after scaling out, resulting in constant loop execution (flapping).
3
Select the correct pricing tier and threshold combination.
Scale up to the Standard (S1) plan and configure a scale-out threshold of 75% and a scale-in threshold of 50%.
This configuration satisfies all technical requirements and operates within valid operational thresholds.

Key Concept

Azure App Service plan tier scaling features and autoscale flapping prevention.
Question 933Question

You are developing a web application that will be hosted on an on-premises web server. The application must programmatically retrieve database connection strings stored as secrets in an Azure Key Vault.

You need to configure the security and authentication requirements to allow the application to access the secrets.

Which of the following actions should you perform?

Show answer & explanation

Answer: Register the application in Microsoft Entra ID to create an application object and a service principal, configure a client secret or certificate for the registration, and grant the service principal access to the secrets in the Key Vault access policy.

Answer

Register the application in Microsoft Entra ID to create an application object and a service principal, configure a client secret or certificate for the registration, and grant the service principal access to the secrets in the Key Vault access policy.
The correct option outlines the standard process for enabling an application running outside of Azure (on-premises) to authenticate and access Azure Key Vault. Since it is hosted on-premises, it cannot use Azure Managed Identities. It requires an Application Registration in Microsoft Entra ID to establish a service principal. The application uses a client secret or certificate to authenticate as this service principal, which must be granted the necessary permissions in the Key Vault access policy to retrieve the secrets.

Step-by-Step Solution

1
Register the application in Microsoft Entra ID.
This creates an application object (definition) and a corresponding service principal (local representation/identity) in the tenant.
An identity is required for the application to authenticate against Microsoft Entra ID.
2
Configure credentials (a client secret or certificate) for the application registration.
The application can now use these credentials to obtain an access token from Microsoft Entra ID.
Since the application runs on-premises, it cannot use managed identities directly and must supply credentials to authenticate.
3
Grant the service principal permission to get secrets in the Azure Key Vault access policy.
The service principal is authorized to retrieve the secrets.
Microsoft Entra ID authentication only proves identity; authorization must be configured at the target resource (Key Vault).

Key Concept

App Registrations and Service Principals are used to establish a security identity for applications, especially when running outside of Azure where Managed Identities are not supported.
Question 934Question

You are developing a data synchronization solution using Azure Durable Functions. The solution must implement the Monitor pattern to periodically poll the status of an external import process until it finishes.

Arrange the steps in the correct chronological order of execution for a single complete loop of the monitoring workflow, starting from the client request.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence of events starts with the HTTP client initiating the orchestration ('client_start'), followed by the orchestrator querying the initial status via an activity ('first_poll'). Since the status is incomplete, the orchestrator sets a durable timer ('timer_scheduled'). Upon timer expiration, the runtime replays the history to restore the orchestrator state ('history_replay'). Finally, the orchestrator resumes, performs the final poll, and completes the workflow ('final_poll').
The correct sequence mirrors the stateful replay architecture of Durable Functions implementing the Monitor pattern. The client initiates the process, creating the instance. The orchestrator calls the activity function for the first status. If incomplete, it creates a durable timer and shuts down. When the timer fires, the runtime restarts the orchestrator, replaying history to reach the current state. Finally, the orchestrator executes the next step, calls the activity again, finds the task complete, and terminates.

Step-by-Step Solution

1
Initiate the orchestration flow.
The client function starts the orchestrator instance and returns a status query response containing endpoints.
An orchestration must be started by a client function using the client binding.
2
Execute the first poll operation.
The orchestrator calls the activity function to fetch the current status.
Orchestrators cannot perform direct I/O, so they must call activity functions to query external endpoints or systems.
3
Schedule the pause interval using a durable timer.
The orchestrator yields execution by creating a durable timer.
To implement non-blocking polling and avoid hosting charges during idle time, the orchestrator uses a durable timer rather than standard thread sleeps.
4
Replay execution history upon timer expiration.
The runtime restarts the orchestrator function and replays past events from the Azure Storage history table.
Durable Functions use event sourcing; when waking up from a timer, the function restarts and replays history to reconstruct its local variables and state.
5
Perform the final status check and complete.
The orchestrator issues the final status query activity and completes the workflow upon detecting success.
Once the condition is met, the orchestrator finishes executing its logic, marking the overall instance as completed.

Key Concept

Monitor Pattern in Azure Durable Functions
Question 935Question

You are developing a C# application that runs on an Azure Virtual Machine (VM). The application uses the Azure.Identity library to authenticate to an Azure Key Vault using DefaultAzureCredential. Both a system-assigned managed identity and a user-assigned managed identity are enabled on the VM. The user-assigned managed identity is granted the Key Vault Secrets User role on the Key Vault, but the system-assigned managed identity has no permissions. When the application runs, it fails to retrieve secrets because DefaultAzureCredential attempts to authenticate using the system-assigned managed identity. You need to configure the environment so that DefaultAzureCredential uses the user-assigned managed identity without modifying the code that instantiates DefaultAzureCredential. Which of the following actions should you perform?

Show answer & explanation

Answer: Set the AZURE_CLIENT_ID environment variable on the Virtual Machine to the Client ID of the user-assigned managed identity.

Answer

Set the AZURE_CLIENT_ID environment variable on the Virtual Machine to the Client ID of the user-assigned managed identity.
When multiple managed identities are configured on a resource, DefaultAzureCredential defaults to the system-assigned managed identity. To override this behavior and select a specific user-assigned managed identity without code changes, you must set the AZURE_CLIENT_ID environment variable to the Client ID of the user-assigned managed identity.

Step-by-Step Solution

1
Identify the authentication behavior of DefaultAzureCredential when both system-assigned and user-assigned managed identities are present.
By default, DefaultAzureCredential will attempt to use the system-assigned managed identity first.
DefaultAzureCredential follows a specific sequence of credential providers, and for managed identities, it defaults to the system-assigned identity unless instructed otherwise.
2
Determine how to configure DefaultAzureCredential to select a specific user-assigned managed identity without code changes.
Identify that the AZURE_CLIENT_ID environment variable can be set to specify the Client ID of the desired user-assigned managed identity.
The Azure Identity SDK checks for the AZURE_CLIENT_ID environment variable to resolve the identity client ID when initializing the ManagedIdentityCredential component of DefaultAzureCredential.
3
Select the correct environment variable value.
The value must be the Client ID (also known as Application ID) of the user-assigned managed identity, not its Resource ID or Principal ID.
Using the Resource ID, Tenant ID, or Principal ID will fail because the SDK expects the Client ID representation to uniquely query the token endpoint for that specific identity.

Key Concept

Configuring DefaultAzureCredential for user-assigned managed identity using environment variables
Question 936Question

You are hosting an ASP.NET Core web application in an Azure App Service. The application requires a database connection string stored as a secret named db-conn in an Azure Key Vault named prod-kv. You create a user-assigned managed identity named app-identity and associate it with the App Service. In prod-kv, you grant the Key Vault Secrets User role to app-identity using Azure RBAC. In the App Service configuration, you add an application setting named ConnectionStrings__DefaultConnection with the value @Microsoft.KeyVault(SecretUri=https://prod-kv.vault.azure.net/secrets/db-conn/). However, the App Service fails to resolve the Key Vault reference at runtime and the application cannot retrieve the database connection string. Which of the following actions should you take to resolve this issue?

Show answer & explanation

Answer: Configure the App Service's keyVaultReferenceIdentity property to point to the resource ID of app-identity.

Answer

Configure the App Service's keyVaultReferenceIdentity property to point to the resource ID of app-identity.
To resolve Key Vault references using a user-assigned managed identity, you must set the keyVaultReferenceIdentity property of the App Service to the resource ID of the user-assigned identity. By default, the App Service attempts to use its system-assigned managed identity, which fails if it is not configured or lacks permissions.

Step-by-Step Solution

1
Identify the authentication mechanism used for resolving Key Vault references.
The App Service is configured with a user-assigned managed identity (app-identity) and lacks a system-assigned managed identity.
By default, App Service attempts to resolve Key Vault references using the system-assigned managed identity.
2
Set the Key Vault reference identity property.
Update the keyVaultReferenceIdentity property of the App Service to point to the Resource ID of the user-assigned identity.
This explicitly tells the App Service which user-assigned managed identity to use for authenticating against the Key Vault to resolve reference strings.
3
Verify reference resolution in the App Service configuration.
The reference status changes to Resolved, and the application successfully retrieves the secret value at runtime.
Once the identity is mapped and permissions are verified, App Service can fetch the secret content.

Key Concept

Using user-assigned managed identities to resolve App Service Key Vault references.
Estimated Time:3m 0s
Question 937Question

You are developing a C# backend service that manages customer order logs using the Azure Cosmos DB .NET SDK v3. The Cosmos DB container uses Session consistency and is partitioned by the customer's identifier (/customerId). A different client session has just created a new order log item with the ID "order-789" for the customer "customer-101". Your service must perform a point read to retrieve this new log item immediately, ensuring it reads the latest write. Which C# code segment should you use?

Show answer & explanation

Answer: string sessionToken = GetWriterSessionToken();
ItemRequestOptions options = new ItemRequestOptions { SessionToken = sessionToken };
ItemResponse<OrderLog> response = await container.ReadItemAsync<OrderLog>("order-789", new PartitionKey("customer-101"), options);

Answer

The correct option is the one that retrieves the write session token, configures it in ItemRequestOptions, and passes both the item ID and the customer-101 partition key to ReadItemAsync.
The correct option obtains the session token from the write operation, configures it in ItemRequestOptions, and calls ReadItemAsync with the item ID and the partition key containing the customer identifier. Under Azure Cosmos DB's Session consistency, sharing the session token is required to guarantee read-your-writes consistency across different client sessions.

Step-by-Step Solution

1
Obtain the session token from the write operation that occurred in the other client session.
The token is stored in a string variable.
Under Session consistency, read-your-writes guarantees across different client sessions require passing the session token.
2
Create an instance of ItemRequestOptions and assign the SessionToken property.
An ItemRequestOptions object configured with the session token.
This request option instructs the Cosmos DB client to read data up to at least the point of the session token.
3
Call ReadItemAsync on the container object, passing the item ID, the PartitionKey containing customer-101, and the request options.
An ItemResponse containing the retrieved OrderLog item.
Cosmos DB .NET SDK v3 requires both the item ID and the partition key value to perform a point read operation.

Key Concept

Session consistency requires passing the session token across different client sessions to guarantee read-your-writes consistency during item operations.
Question 938Question

You are transitioning a .NET web application hosted on an Azure App Service named `web-prod` from using a system-assigned managed identity to a new user-assigned managed identity named `id-prod`. The application retrieves secrets from an Azure Key Vault named `kv-prod` using the `DefaultAzureCredential` class. The system-assigned identity must remain temporarily enabled during the migration to prevent configuration issues, but the application must immediately begin using the new user-assigned identity to authenticate. You need to configure the resource association and access permissions using the Azure CLI, and update the application configuration. Arrange the steps in the correct order to achieve this transition while preventing application authorization errors during the configuration process.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order of steps is: 1) Run `az identity create` to create the user-assigned identity, 2) Run `az webapp identity assign` to associate the identity with the App Service, 3) Run `az role assignment create` to grant the identity the Key Vault Secrets User role, 4) Add the `AZURE_CLIENT_ID` App Setting to direct `DefaultAzureCredential` to the new identity, and 5) Deploy the updated application code.
The correct sequence begins with creating the user-assigned managed identity to obtain its unique identifiers. Next, the identity must be associated with the App Service so that the App Service can request tokens for it. The RBAC role assignment is then configured at the Key Vault scope to authorize access. Following that, the `AZURE_CLIENT_ID` App Setting is configured to instruct `DefaultAzureCredential` to use this specific user-assigned identity, resolving the ambiguity of coexisting identities. Finally, deploying the application code ensures a seamless transition without access failures.

Step-by-Step Solution

1
Create the user-assigned managed identity.
The identity `id-prod` is created in Microsoft Entra ID, generating its Client ID and Principal ID.
The Client ID and Principal ID are required dependencies for role assignment and App Service configuration.
2
Associate the identity with the App Service host.
The App Service is configured to recognize the user-assigned identity `id-prod`.
The App Service environment must have the identity registered so the Azure Instance Metadata Service (IMDS) token endpoint can retrieve tokens for it.
3
Assign the RBAC role to the identity's Principal ID.
The identity `id-prod` is granted the 'Key Vault Secrets User' role at the `kv-prod` Key Vault scope.
Assigning permissions prior to forcing the application to use the identity prevents 403 Forbidden errors when the application attempts to fetch secrets.
4
Configure the `AZURE_CLIENT_ID` App Setting.
The environment variable `AZURE_CLIENT_ID` is set to the client ID of `id-prod`.
When both system-assigned and user-assigned identities are active on the same App Service, `DefaultAzureCredential` requires the `AZURE_CLIENT_ID` environment variable to identify which user-assigned identity to use.
5
Deploy the application code.
The application runs, and `DefaultAzureCredential` successfully fetches Key Vault secrets using the user-assigned managed identity.
With all infrastructure, permissions, and environment variables fully configured, the application can securely execute without service disruption.

Key Concept

Configuring coexisting managed identities and directing DefaultAzureCredential using environment variables.
Question 939Question

An enterprise application requires copying a blob named `archive.zip` from a source storage account to a destination storage account. The destination blob already exists and is locked with an active, exclusive-write lease. The application must perform the copy operation asynchronously and overwrite the destination blob without breaking or releasing the existing lease. You have retrieved the destination blob's lease ID: `d3b07384-d113-4c4e-a51a-7b2c0f209176`.

Which C# code snippet should you run to perform the copy operation?

Show answer & explanation

Answer: var options = new BlobCopyFromUriOptions
{
DestinationConditions = new BlobRequestConditions
{
LeaseId = "d3b07384-d113-4c4e-a51a-7b2c0f209176"
}
};
await destBlobClient.StartCopyFromUriAsync(sourceUri, options);

Answer

Use BlobCopyFromUriOptions with DestinationConditions containing the lease ID, and pass it to StartCopyFromUriAsync.
To copy a blob to a destination that has an active exclusive-write lease, you must pass the lease ID associated with the destination blob. In the Azure.Storage.Blobs SDK (v12), this is accomplished by setting the LeaseId property of the BlobRequestConditions assigned to the DestinationConditions of the BlobCopyFromUriOptions object. The destination client uses these conditions to authorize the write operation against the leased blob.

Step-by-Step Solution

1
Identify the source of the lease constraint.
The destination blob is leased, meaning any write operations (like copying over it) require the lease ID.
Applying write operations to a leased blob without the lease ID results in a precondition failure.
2
Configure the BlobCopyFromUriOptions object.
Assign a new BlobRequestConditions object to DestinationConditions, specifying the destination lease ID.
DestinationConditions defines the conditions under which the destination blob can be modified.
3
Execute the copy operation.
Invoke StartCopyFromUriAsync on the destination client, passing the source URI and the configured options.
This starts the asynchronous copy process on the Azure Storage service backend with the correct authorization.

Key Concept

Copying blobs to a leased destination using Azure.Storage.Blobs SDK
Question 940Question

You are designing the security architecture for an enterprise Azure Function app that processes financial transactions. The app requires access to an Azure SQL Database and retrieves cryptographic keys from an Azure Key Vault. Due to strict CI/CD and compliance policies, the Function app is frequently torn down and recreated in different resource groups using automated Terraform scripts. You need to choose a managed identity configuration that ensures the application can authenticate to Azure SQL and Key Vault with the least administrative effort during deployment cycles, specifically avoiding the need to recreate database users or update Key Vault access policies after each deployment.

Which configuration should you implement?

Show answer & explanation

Answer: Configure a user-assigned managed identity as a standalone Azure resource, grant it the required roles on the Azure SQL Database and Key Vault, and assign this identity to the Function app during deployment.

Answer

Configure a user-assigned managed identity as a standalone Azure resource, grant it the required roles on the Azure SQL Database and Key Vault, and assign this identity to the Function app during deployment.
A user-assigned managed identity exists as a standalone Azure resource with its own lifecycle. When the Azure Function app is deleted and recreated by Terraform, the user-assigned identity and its associated service principal object ID remain unchanged. Consequently, the permissions granted to the identity in the Azure SQL Database and Azure Key Vault persist across deployments, requiring only that the new Function app instance be associated with the existing identity.

Step-by-Step Solution

1
Analyze the resource lifecycle requirement.
The application infrastructure is ephemeral (frequently deleted and recreated via CI/CD), while the target systems (Azure SQL and Key Vault) are persistent.
Choosing a system-assigned identity would tie the identity's lifecycle to the ephemeral resource, causing credential loss and requiring constant manual reconfiguration.
2
Compare system-assigned and user-assigned managed identities.
A user-assigned managed identity is created as a standalone Azure resource. It survives the deletion of the associated Azure Function App.
To maintain persistent authorization in Key Vault and Azure SQL without updating permissions during deployments, the identity must have an independent lifecycle.
3
Verify authorization requirements.
The managed identity must have specific data plane permissions (e.g., Key Vault Secrets User, Azure SQL database roles) to retrieve keys and query data.
Generic management plane roles like Reader do not authorize data plane operations, so direct RBAC role assignments or access policies are required.

Key Concept

The lifecycle difference between System-Assigned and User-Assigned Managed Identities.
Estimated Time:2m 0s
PreviousPage 47 / 49Next
All practice questions — Microsoft Azure Developer (AZ-204) | Examkin