Examkin

All practice questions

171 questions

All types972Multiple choice497Multiple select269Matching9Ordering171Fill in the blank26
Question 161Question →

You are developing a C# service that manages customer profiles in Azure Cosmos DB using the .NET SDK v3. The service must connect to the database, navigate the resource hierarchy, and update a user profile. The database is named ProfileDb, the container is named Profiles, and the partition key path for the container is /userId.

You have an existing UserProfile instance named profile that contains a UserId property.

Which sequence of C# code blocks must you execute to initialize the client and upsert the user profile?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts with initializing the CosmosClient, obtaining the database reference, getting the container reference, instantiating the PartitionKey with the partition key property value, and finally calling UpsertItemAsync.
The C# .NET SDK v3 enforces a hierarchical resource model. You must first construct the root CosmosClient. From that client, you obtain the Database reference using GetDatabase. Using the Database object, you retrieve the Container reference using GetContainer. Before modifying or adding an item, a PartitionKey object must be initialized with the corresponding value. Finally, calling UpsertItemAsync on the container with the item and its partition key completes the operation.

Step-by-Step Solution

1
Initialize CosmosClient
A client connection to Azure Cosmos DB is established.
CosmosClient is the top-level SDK object required for all interactions.
2
Retrieve Database reference
A Database object representing ProfileDb is obtained.
Containers reside within a database context, so database access must precede container access.
3
Retrieve Container reference
A Container object representing Profiles is obtained.
Item operations are executed against a specific container.
4
Instantiate PartitionKey
A PartitionKey instance is created with the profile's UserId.
SDK v3 requires a PartitionKey object to perform point operations like UpsertItemAsync efficiently.
5
Execute UpsertItemAsync
The item is written or replaced in the container.
Calling UpsertItemAsync writes the updated data to the target partition.

Key Concept

Azure Cosmos DB .NET SDK v3 Resource Hierarchy and Item Operations
Estimated Time:1m 30s
Question 162Question →

You are deploying a secure web application named web-app to Azure Container Apps. The application needs to retrieve database credentials stored as a secret in an existing Azure Key Vault named kv-prod. You must configure the Container App to access the Key Vault secret securely using a user-assigned managed identity. Which sequence of steps should you perform to configure the Container App?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To configure the Container App to securely retrieve the secret, you must first create a user-assigned managed identity and grant it the Key Vault Secrets User role on the Key Vault. Next, associate this managed identity with the Container App. Then, add a secret to the Container App that references the Key Vault secret URL and specifies the identity. Finally, update the container definition to map the Container App secret to an environment variable.
The correct order follows the lifecycle dependencies of Azure resources. The identity must exist and have permissions (Step 1) before it can be assigned to the Container App (Step 2). Once associated with the Container App, the identity can be referenced in the Container App's secrets configuration (Step 3). Finally, once the secret is defined at the app level, it can be mapped to individual container environment variables (Step 4).

Step-by-Step Solution

1
Create the user-assigned managed identity and grant Key Vault Secrets User role on the Key Vault.
The identity is provisioned and authorized to retrieve secrets.
This establishes access permissions before configuring the Container App.
2
Associate the user-assigned managed identity with the Container App.
The Container App is updated with the identity's resource ID.
The Container App must possess the identity before the identity can be used in secret references.
3
Create a Container App secret referencing the Key Vault secret URL and the identity.
The Container App secret configuration is saved.
This defines an app-level secret backed by Azure Key Vault.
4
Map the Container App secret to an environment variable in the container configuration.
The container environment variable is populated with the secret value at runtime.
This exposes the secret to the application process running inside the container.

Key Concept

Azure Container Apps Key Vault references with User-Assigned Managed Identity
Estimated Time:2m 0s
Question 163Question →

You are configuring a daemon application (App1) to call a custom Web API (API1) programmatically. Both applications are registered in Microsoft Entra ID. You need to configure API1 to expose an application permission, assign that permission to App1, and ensure App1 can successfully request an access token. Which four actions should you perform in sequence?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To configure the daemon application (App1) to call the Web API (API1) programmatically, you must first create the App Role (Application type) in the API1 registration. Next, add this App Role under the API permissions of the App1 registration. After that, grant tenant-wide admin consent for the permission in App1. Finally, request an access token in the App1 application code using the Client Credentials flow.
The correct sequence starts with defining the App Role on the target API (API1) because a permission must exist before it can be assigned. Next, the client application (App1) must request this permission by adding it to its registration. After the permission is registered, a tenant administrator must grant consent. Finally, with the permission consented, the client application can execute its code to request the access token using the client credentials flow.

Step-by-Step Solution

1
In the API1 registration, create an App Role with the allowed member types set to Applications.
The custom Web API exposes an application permission that other service principals can request.
A permission role must be declared on the target API resource before any client applications can reference or request it.
2
In the App1 registration, add the defined App Role of API1 under API permissions.
App1 declares a dependency on the API1 application permission.
The client application registration must explicitly declare which permissions it requires to access target resources.
3
In the App1 registration, select Grant admin consent to authorize the added permission.
The application permission is approved for use within the directory tenant.
Application permissions (App Roles) cannot be consented to by regular users and must be granted tenant-wide by an administrator before tokens can be issued.
4
In the App1 application code, request an access token using the Client Credentials flow.
The application receives an access token containing the role claims necessary to call the Web API.
With consent granted, the daemon application can now authenticate and request a token representing its own identity.

Key Concept

Configuring application permissions and client credentials authentication flow in Microsoft Entra ID.
Estimated Time:2m 0s
Question 164Question →

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

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

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

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

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

You are developing a C# service that manages utility smart-meter configurations using the Azure Cosmos DB .NET SDK v3. The target container is configured with a partition key path of `/gridId`.

You need to update the configuration of a specific smart meter. Your task is to write a method that retrieves the existing configuration document, changes the `ReportingIntervalMinutes` property to `15` in memory, and then saves the updated configuration back to the container.

Arrange the steps in the correct order to complete the operation.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order of operations starts with instantiating the CosmosClient, followed by retrieving references to the Database and Container. Next, the existing item is read using ReadItemAsync with its ID and PartitionKey. The retrieved configuration's properties are then modified in memory. Finally, the updated configuration is saved back to the container using ReplaceItemAsync, passing the modified document, its ID, and its PartitionKey.
The correct order follows the logical hierarchy of the Azure Cosmos DB .NET SDK v3. A CosmosClient must be created first to manage connections. The client is used to reference the Database, which is then used to reference the Container. Before modifying and replacing the item, the current state of the item must be read using ReadItemAsync (providing the ID and partition key). The retrieved object's properties are updated in memory next. Finally, the replacement is committed using ReplaceItemAsync with the updated object, its ID, and the partition key.

Step-by-Step Solution

1
Initialize the SDK client.
A CosmosClient instance is created.
The client manages connections and configuration for the Azure Cosmos DB account.
2
Retrieve the database object.
A Database reference is obtained.
You must navigate the SDK hierarchy from client to database.
3
Retrieve the container object.
A Container reference is obtained.
All item operations are executed against a specific Container instance.
4
Perform a point read.
An ItemResponse containing the MeterConfig object is returned.
To modify an existing item, you must read the current state of the document using both ID and the partition key.
5
Update the object in memory.
The local object's property is changed.
Modifications must be made to the local object representation before sending it back.
6
Replace the item in Cosmos DB.
The item is updated in the container.
The ReplaceItemAsync method updates the database representation using the updated local object, the ID, and the partition key.

Key Concept

Azure Cosmos DB .NET SDK v3 item update workflow using point read and replace
Question 170Question →

You are managing a web application that distributes documents through an Azure CDN endpoint. You need to configure a custom caching rule in the Azure portal that overrides the default caching behavior specifically for files in the `/pdf/` directory.

In which order should you perform the steps in the Azure portal to configure and apply this custom caching rule?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To configure a custom caching rule in the Azure portal, you must first navigate to the CDN endpoint, select the Caching rules settings, configure the path match and override behavior in the Custom caching rules section, and then save the changes.
The correct order begins with locating the target CDN endpoint in the portal. Next, navigation to the caching rules settings is required. Once inside, you define the custom rule settings (using the path match condition and override behavior) to target the `/pdf/` directory. Finally, saving the settings deploys the rule to the CDN POPs.

Step-by-Step Solution

1
Navigate to the CDN endpoint
The endpoint blade is displayed, exposing the management settings.
You must target the specific endpoint before you can modify its caching configurations.
2
Open Caching rules
The caching rules workspace opens, showing query string, global caching, and custom caching options.
All caching-related settings are consolidated in the Caching rules menu under Settings.
3
Configure the Custom caching rule
A new custom rule is defined targeting the `/pdf/*` path with an Override behavior.
Defining the rule specifies which requests (by path) will have their cache headers overridden and how the CDN should handle them.
4
Save the changes
The configuration is saved and propagation to the CDN edge servers begins.
Changes to caching rules do not take effect until they are saved and deployed.

Key Concept

Custom caching rules allow overriding or bypassing default caching behaviors based on specific match conditions like path or file extension.
Question 171Question →

A telemetry ingestion system requires a .NET service to consume stream records from Azure Event Hubs. You plan to implement event processing using the Azure.Messaging.EventHubs.Processor namespace, using Azure Blob Storage for partition checkpoints. What is the correct sequence of API operations to manage the lifecycle of the client?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence is to first initialize the BlobContainerClient and EventProcessorClient, then register callback methods for both ProcessEventAsync and ProcessErrorAsync, followed by calling StartProcessingAsync to start processing, and finally calling StopProcessingAsync to cleanly terminate consumption.
To consume events using the modern Azure.Messaging.EventHubs SDK, the developer must first initialize the required clients (BlobContainerClient and EventProcessorClient). Before processing can begin, the client requires that handler methods for both events and errors be registered. Once registered, StartProcessingAsync is called to begin operations. To shut down cleanly and release partition leases, StopProcessingAsync must be called.

Step-by-Step Solution

1
Instantiate BlobContainerClient and EventProcessorClient.
Clients are constructed and ready for setup.
The processor requires references to the checkpoint storage container and target event hub configurations during creation.
2
Assign event handlers to ProcessEventAsync and ProcessErrorAsync.
Callback methods are registered to process incoming events and errors.
EventProcessorClient mandates both event and error handler registrations before processing can start.
3
Invoke StartProcessingAsync.
The processor starts load balancing and consuming partitions.
Starting the client initiates background tasks to pull events and update checkpoints.
4
Invoke StopProcessingAsync.
Event consumption stops and partition leases are released.
Stopping the client ensures a graceful shutdown, preventing other instances from waiting for lease expiration.

Key Concept

Managing the lifecycle of EventProcessorClient in Azure Event Hubs .NET SDK
PreviousPage 9 / 9
All practice questions — Microsoft Azure Developer (AZ-204) | Examkin