All practice questions

972 questions

Question 901Question

You are deploying a microservice named `inventory-service` to an Azure Container Apps environment. The microservice must only accept incoming requests from other container apps within the same environment and must not be exposed to the public internet. Additionally, client requests must be routed to the same replica of `inventory-service` to support in-memory session caching.

Which two configuration settings must you apply to the Container App's ingress configuration? (Select two.)

Select all that apply

Show answer & explanation

Answer: Set external to false.; Configure stickySessions with affinity set to sticky.

Answer

To configure the Container App as internal-only with session persistence, you must set external to false and configure stickySessions with affinity set to sticky in the ingress settings.
To satisfy both requirements, you configure ingress settings. Setting the external flag to false blocks public internet access, confining traffic to the Container Apps environment. Setting stickySessions.affinity to sticky ensures that client sessions are routed to the same replica.

Step-by-Step Solution

1
Analyze the isolation requirement.
The microservice must only be accessible within the Container Apps environment.
Setting the external property to false in the ingress configuration achieves this environment-level isolation.
2
Analyze the session affinity requirement.
Requests from a client must route to the same replica instance for caching.
Enabling stickySessions with the affinity property set to sticky ensures that requests from the same client are pinned to the same container replica.

Key Concept

Configuring ingress, environment isolation, and session affinity in Azure Container Apps
Estimated Time:1m 30s
Question 902Question

An organization is deploying a C# background service that runs on an on-premises Windows server. The service must periodically query Microsoft Graph using its own credentials, authenticated by a client certificate. Which MSAL.NET builder class must you use to instantiate the client application?

Show answer & explanation

Answer: ConfidentialClientApplicationBuilder

Answer

ConfidentialClientApplicationBuilder
The correct answer is ConfidentialClientApplicationBuilder because daemon applications running on secure servers can maintain client credentials securely. In MSAL.NET, these applications are instantiated using the ConfidentialClientApplicationBuilder class.

Step-by-Step Solution

1
Analyze the application requirements.
The application is a background service (daemon) running on-premises and needs to authenticate using its own credentials (client certificate) without user intervention.
Identifying the client application type determines the correct MSAL.NET class to use.
2
Determine the client type classification.
Since the app runs on a secure server and can maintain the confidentiality of its certificate, it is classified as a confidential client application.
MSAL.NET separates public clients (desktop/mobile/CLI) from confidential clients (daemons/web APIs/web apps).
3
Select the correct MSAL.NET builder.
Use ConfidentialClientApplicationBuilder to instantiate the client.
ConfidentialClientApplicationBuilder provides the methods needed to configure confidential client credentials like client secrets and certificates.

Key Concept

MSAL.NET Client Application Types
Question 903Question

You are developing a .NET background worker service that processes batch database updates from an Azure Service Bus queue named `db-updates`. The queue has a message lock duration set to 1 minute.

Each update batch takes exactly 7 minutes to process. You write the following code to initialize the processor and handle messages:

csharp
var client = new ServiceBusClient(connectionString);
var options = new ServiceBusProcessorOptions
{
ReceiveMode = ServiceBusReceiveMode.PeekLock,
AutoCompleteMessages = false
};
var processor = client.CreateProcessor("db-updates", options);

processor.ProcessMessageAsync += MessageHandler;
processor.ProcessErrorAsync += ErrorHandler;

async Task MessageHandler(ProcessMessageEventArgs args)
{
await ProcessBatchAsync(args.Message); // Takes 7 minutes
await args.CompleteMessageAsync(args.Message);
}

The `MaxAutoLockRenewalDuration` property is left at its default configuration.

What is the behavior of the application when processing a message?

Show answer & explanation

Answer: The processor automatically renews the lock up to the default duration of 5 minutes. After 5 minutes, the lock expires and the message becomes visible to other receivers on the queue. When the handler finishes processing at 7 minutes and calls CompleteMessageAsync, a ServiceBusException is thrown.

Answer

The processor automatically renews the lock up to the default duration of 5 minutes. After 5 minutes, the lock expires and the message becomes visible to other receivers on the queue. When the handler finishes processing at 7 minutes and calls CompleteMessageAsync, a ServiceBusException is thrown.
The correct answer is correct because the Azure Service Bus SDK's ServiceBusProcessor class has a default MaxAutoLockRenewalDuration configuration of 5 minutes. Even though the queue's lock duration is 1 minute, the processor automatically renews the lock in the background up to the maximum auto-renewal duration. Since the handler takes 7 minutes to process the message, the lock renewal stops at 5 minutes, allowing the lock to expire. When the handler attempts to call CompleteMessageAsync at 7 minutes, it fails because the active lock has been lost, causing the client to throw a ServiceBusException.

Step-by-Step Solution

1
Determine the default configurations of the ServiceBusProcessorOptions.
The default value for MaxAutoLockRenewalDuration is 5 minutes.
To evaluate lock validity over the 7-minute execution window, we need the background renewal limit.
2
Compare the task duration against the auto-renewal limit.
The task takes 7 minutes, which exceeds the 5-minute renewal threshold.
Since the task duration is longer than the renewal limit, the background thread will cease renewing the lock after 5 minutes.
3
Evaluate the state of the message lock at completion time.
At the 7-minute mark, the message lock has expired, causing the message to be released back to the queue, and calling CompleteMessageAsync throws a ServiceBusException.
A client cannot complete a message if its lock has already expired or been acquired by another receiver.

Key Concept

ServiceBusProcessor automatic lock renewal limits and manual message settlement.
Question 904Question

You manage an Azure App Service Web App named ImageResizerAPI that is deployed on a Standard (S2) App Service plan. The Web App is currently scaled to 3 instances. You configure an autoscale rule to scale out by increasing the instance count by 1 when the average CPU percentage exceeds 80%80\%. You need to configure a scale-in rule to decrease the instance count by 1 when the CPU load decreases. To prevent autoscale flapping, which scale-in CPU threshold should you configure?

Show answer & explanation

Answer: 50%

Answer

A scale-in threshold of 50% should be configured.
A scale-in threshold of 50% is correct because when the App Service scales out from 3 instances to 4 instances at a CPU utilization of 81%, the load is redistributed. The new average CPU per instance becomes 60.75%60.75\% (81%×3481\% \times \frac{3}{4}). Since 60.75% is greater than 50%, the scale-in rule is not triggered, preventing an immediate scale-in loop (flapping).

Step-by-Step Solution

1
Calculate the total CPU load when a scale-out is triggered.
Total CPU load is 81%×3=243%81\% \times 3 = 243\%.
At 3 instances with a threshold of 80%80\%, a scale-out triggers when average CPU exceeds 80%80\% (for example, 81%81\%).
2
Calculate the new average CPU per instance after scaling out.
New average CPU per instance is 60.75%60.75\%.
When 1 instance is added, the total CPU load of 243%243\% is distributed across 4 instances: 243%4=60.75%\frac{243\%}{4} = 60.75\%.
3
Determine the scale-in threshold that is lower than the new CPU load to prevent flapping.
A threshold of 50%50\% prevents flapping.
To prevent the scale-in rule from triggering immediately after scaling out, the scale-in threshold must be set to a value below 60.75%60.75\%.

Key Concept

Autoscale flapping prevention in Azure App Service
Question 905Question

An operations monitoring application uses an Azure Cosmos DB API for NoSQL account with a single write region in East US and read replicas in West US and East Asia. The database account is currently configured with the default Session consistency level. The development team needs to optimize the application for both performance and read guarantees.

Which two statements regarding Azure Cosmos DB consistency level configurations and their trade-offs are correct? (Select two.)

Select all that apply

Show answer & explanation

Answer: Switching the default consistency level from Session to Strong will double the Request Unit (RU) cost for read operations because reads require a quorum check across replica regions to ensure the latest version of data is returned.; When using the default Session consistency, if a web app writes a tracking record using one client instance and subsequently reads it using a different client instance, the read may return stale data unless the application explicitly passes the session token from the write operation to the read client.

Answer

Switching to Strong consistency doubles read RU costs due to replica quorum requirements, and when using Session consistency across different client instances, the session token must be explicitly passed to guarantee read-your-own-writes.
The correct statements are that switching the default consistency to Strong will double the RU cost for reads due to quorum reads, and that Session consistency requires passing the session token to guarantee read-your-own-writes when reads and writes occur on separate client instances.

Step-by-Step Solution

1
Analyze the read RU cost implications of changing the default consistency level.
Strong and Bounded Staleness consistency levels perform quorum reads, which cost twice as much in RUs as reads performed under Session, Consistent Prefix, or Eventual consistency.
This evaluates the trade-offs of switching from Session to Strong consistency.
2
Evaluate how Session consistency behaves across multiple independent client instances.
The Cosmos DB SDK automatically manages the session token at the client instance level. If different instances are used for reads and writes, the session token must be manually extracted and passed to maintain the read-your-own-writes guarantee.
This verifies the scoping and requirements of Session consistency in scale-out application scenarios.
3
Verify write cost and replication mechanics under Bounded Staleness and Consistent Prefix.
Writes cost the same across all consistency levels, and Consistent Prefix only guarantees ordering, not immediate read-your-own-writes. Partition keys must also maintain high cardinality to prevent hot partitions.
This rules out the incorrect options.

Key Concept

Azure Cosmos DB consistency levels and their performance, cost, and session scoping behavior.
Question 906Question

An enterprise data archive application written in C# needs to update the custom metadata of an existing blob named `log-archive.txt` inside a container named `logs` using the `Azure.Storage.Blobs` SDK (v12). The blob currently has an active lease held by another process with the ID stored in a string variable named `activeLeaseId`.

You need to write the code to update the metadata dictionary with a key of `ProcessedBy` and a value of `SyncService`. The update must succeed without breaking or releasing the lease.

Which code segment should you use?

Show answer & explanation

Answer: var metadata = new Dictionary<string, string>
{
{ "ProcessedBy", "SyncService" }
};
var conditions = new BlobRequestConditions { LeaseId = activeLeaseId };
await blobClient.SetMetadataAsync(metadata, conditions);

Answer

The correct option initializes the metadata dictionary using the key 'ProcessedBy' and values 'SyncService', instantiates a 'BlobRequestConditions' object containing the 'LeaseId' set to 'activeLeaseId', and passes both objects to 'SetMetadataAsync'.
The correct option correctly configures a 'BlobRequestConditions' object with the lease ID. Because the target blob has an active lease, passing the lease ID is required to authorize the metadata write. Additionally, it defines the metadata key using the key 'ProcessedBy' without the REST API prefix. The SDK manages prefixing automatically, so omitting it ensures that the metadata key is correctly resolved.

Step-by-Step Solution

1
Identify the active concurrency control on the blob.
The blob is currently leased by an external process, meaning all write and delete operations require the associated lease ID.
Azure Storage requires the lease ID in request headers/options to allow modifying a leased resource.
2
Construct the metadata dictionary payload.
Define the metadata dictionary with the key 'ProcessedBy' and value 'SyncService'.
In the modern Azure.Storage.Blobs SDK (v12), custom metadata keys are passed without the 'x-ms-meta-' HTTP header prefix because the SDK automatically adds it during transmission.
3
Call the appropriate SDK method passing request conditions.
Initialize 'BlobRequestConditions' with the 'LeaseId' property set, and call 'SetMetadataAsync'.
This sends the metadata update payload along with the lease credentials to authorize the change without breaking the lease.

Key Concept

Handling metadata updates on leased blobs using modern Azure Storage SDK (v12) request conditions.
Question 907Question

A developer is configuring a C# console application that will run on a user's workstation. The application must authenticate the user using the Microsoft Identity Platform to retrieve their profile from Microsoft Graph. Which two components must be configured to support this authentication flow? (Select two)

Select all that apply

Show answer & explanation

Answer: An instance of IPublicClientApplication initialized using the Microsoft Authentication Library (MSAL); Delegated permissions for the Microsoft Graph API configured in the Microsoft Entra ID application registration

Answer

The correct configurations are initializing an instance of IPublicClientApplication using the Microsoft Authentication Library (MSAL) and configuring delegated permissions for the Microsoft Graph API.
The C# console application runs on a local workstation and is a public client, meaning it cannot securely store secrets. Therefore, it requires the IPublicClientApplication interface from MSAL to acquire tokens. Since the application accesses Microsoft Graph on behalf of the signed-in user, delegated permissions must be configured in Microsoft Entra ID.

Step-by-Step Solution

1
Determine the application client type.
Since the console app runs on a user's workstation and cannot secure a client secret, it is classified as a public client.
This dictates that MSAL's IPublicClientApplication should be used instead of IConfidentialClientApplication.
2
Identify the permission type required for user-bound operations.
Delegated permissions are selected because the application acts on behalf of the logged-in user.
Application permissions are only for services running without user interaction.

Key Concept

Public client authentication flow using MSAL and delegated permissions
Question 908Question

A company runs a high-throughput transaction processing system that stores invoice documents in an Azure Cosmos DB container. To generate real-time financial reports, you are implementing a scaling consumer application with multiple active host instances. The instances must load-balance the processing of change feed events from the source container. Which configuration must you apply to the lease container and the Change Feed Processor instances to ensure correct load-balanced execution?

Show answer & explanation

Answer: Configure the lease container with /id as the partition key. Initialize the processor across all instances with the same processor name and a unique host instance name for each instance.

Answer

Configure the lease container with /id as the partition key. Initialize the processor across all instances with the same processor name and a unique host instance name for each instance.
The correct option correctly identifies that the lease container must use /id as its partition key, and that the Change Feed Processor instances must share the same processor name to work as a single consumer group while using unique host instance names to distribute the lease ownership among themselves.

Step-by-Step Solution

1
Define the partition key of the lease container.
The lease container is created with /id as its partition key.
The SDK's Change Feed Processor uses the id field of lease documents to store partition lease states. Thus, /id is the required partition key path for the lease container.
2
Configure the processor name on all host instances.
All instances of the consumer application are configured with the same processor name.
Using the same processor name groups the instances together as a single logical consumer, enabling them to load-balance the processing of the change feed.
3
Configure the instance name on each host instance.
Each instance is initialized with a unique instance name.
The instance name identifies each physical or virtual host. A unique value allows the processor to distribute lease ownership and coordinate among the instances.

Key Concept

Azure Cosmos DB Change Feed Processor scale-out and lease container configuration requirements
Question 909Question

A developer is configuring a V4 Azure Function App to connect to a secure database. The database connection string is stored in Azure Key Vault. The developer wants to reference this secret directly in the Function App's application settings without writing custom code to retrieve it. The Function App has a system-assigned managed identity enabled. Which of the following configurations is required to successfully retrieve the secret at runtime?

Show answer & explanation

Answer: Grant the system-assigned managed identity GET permission on secrets in the Key Vault access policy, and set the application setting value using the @Microsoft.KeyVault(SecretUri=...) syntax.

Answer

Grant the system-assigned managed identity GET permission on secrets in the Key Vault access policy, and set the application setting value using the @Microsoft.KeyVault(SecretUri=...) syntax.
The correct configuration resolves the secret automatically because it meets both the syntax and permission criteria. The system-assigned managed identity must be granted the GET secret permission in the Key Vault's access policy (or via Azure RBAC Key Vault Secrets User), and the application setting must use the `@Microsoft.KeyVault(SecretUri=...)` syntax for the runtime to locate and retrieve the secret.

Step-by-Step Solution

1
Determine the syntax needed for Key Vault references in Azure Functions.
The reference must use the `@Microsoft.KeyVault(...)` syntax.
This is the syntax required by the App Service and Azure Functions hosting runtime to automatically intercept and resolve the setting value.
2
Identify the authentication mechanism and permissions.
The system-assigned managed identity must have GET permissions for Key Vault secrets.
The runtime resolves references using the app's managed identity, which needs explicit data-plane read permissions on Key Vault secrets.
3
Combine both configurations.
Ensure the managed identity is configured with the Key Vault access policy (or RBAC data plane role) and the setting has the correct reference syntax.
If either setting syntax is wrong or permission is missing, the reference fails to resolve, yielding a runtime error or empty value.

Key Concept

Configuring Key Vault references in Azure Functions application settings
Question 910Question

A company is developing an Azure Cosmos DB API for NoSQL solution that replicates data across East US and West US. The Cosmos DB account is configured with Session consistency as the default. You deploy two distinct instances of a web client, AppClient1 and AppClient2. AppClient1 writes a document update to the database. AppClient2 must immediately read the updated document, but it does not have access to AppClient1's session token. Which of the following describes the consistency behavior AppClient2 will experience when reading the updated document?

Show answer & explanation

Answer: AppClient2 is not guaranteed to read the updated data immediately because Session consistency only guarantees read-your-writes for reads that occur within the same client session, unless the session token is explicitly passed.

Answer

AppClient2 is not guaranteed to read the updated data immediately because Session consistency only guarantees read-your-writes for reads that occur within the same client session, unless the session token is explicitly passed.
The correct answer is that AppClient2 is not guaranteed to read the updated data immediately. In Azure Cosmos DB, Session consistency is the default and provides read-your-writes, monotonic reads, and monotonic writes guarantees inside a single client session. Because AppClient2 is a separate instance and does not receive the session token of AppClient1's write, it reads data under Consistent Prefix consistency, which means it may observe a delay in replication between East US and West US.

Step-by-Step Solution

1
Analyze the configured consistency level and client setup in the scenario.
The Cosmos DB account is configured with Session consistency, and there are two independent clients (AppClient1 and AppClient2) operating without shared session tokens.
Understanding the session boundary is necessary to evaluate the consistency guarantees between separate clients.
2
Determine the consistency guarantees within and outside a session.
Session consistency guarantees read-your-writes and monotonic reads only within the same session. Outside the session (where the session token is not shared), reads default to Consistent Prefix consistency.
Knowing that AppClient2 is in a different session helps identify that it is subject to Consistent Prefix rather than strong read-your-writes guarantees.
3
Evaluate the likelihood of AppClient2 reading the most recent write immediately.
Since AppClient2 is outside AppClient1's session and does not pass the session token, it may read stale data (though writes will be in order).
This matches the behavior described where AppClient2 is not guaranteed to immediately read the updated document.

Key Concept

Session consistency scope and token passing across separate clients in Azure Cosmos DB
Estimated Time:1m 30s
Question 911Question

You are developing a veterinary clinic management system that synchronizes patient health records. The system uses an Azure Service Bus queue named patient-sync to distribute updates (with an average payload size of 80 KB80\text{ KB}) to a clinic database. You are implementing a .NET console application that processes these messages.

The solution must meet the following requirements:
- Synchronize messages with at-least-once delivery guarantees. If the console application crashes during processing, the message must remain in the queue for subsequent processing.
- Configure client authentication using a Shared Access Signature (SAS) token that restricts the console application to only receiving and processing messages from the patient-sync queue, with no permissions to send messages or manage the queue.

Which two configuration settings should you apply? (Select two.)

Select all that apply

Show answer & explanation

Answer: Set the ReceiveMode of ServiceBusProcessorOptions to ServiceBusReceiveMode.PeekLock.; Generate a SAS token with only the Listen permission scoped to the patient-sync queue.

Answer

To meet the requirements, set the ReceiveMode of ServiceBusProcessorOptions to PeekLock and generate a SAS token with only the Listen permission scoped to the patient-sync queue.
The correct choices are setting the receive mode to PeekLock and generating a SAS token restricted to the Listen permission scoped to the queue. PeekLock ensures that messages are locked rather than deleted immediately upon receipt, allowing for automatic or manual completion only after successful processing. Scoping the SAS token to the queue with only Listen permission limits access to reading messages from that specific queue, adhering to the principle of least privilege.

Step-by-Step Solution

1
Determine the receive mode required for at-least-once delivery.
PeekLock mode must be configured.
PeekLock ensures the message is locked rather than deleted upon receipt, which allows the message to be processed and settled; if processing fails or the client crashes, the lock expires and the message becomes available again.
2
Determine the SAS token scope and permissions.
A queue-scoped SAS token with only Listen claims is required.
This satisfies the requirement to restrict the console application to only receiving and processing messages from the patient-sync queue without permission to send or manage.

Key Concept

Implement Azure Service Bus Solutions
Question 912Question

You are configuring diagnostic telemetry for a .NET web application hosted on an Azure App Service. The application is experiencing intermittent unhandled exceptions in production, and you need to enable the Application Insights Snapshot Debugger to collect call stacks when these exceptions occur. Developers must also be able to view these snapshots in the Azure portal.

Which of the following configuration actions are required? (Select TWO)

Select all that apply

Show answer & explanation

Answer: Configure the APPLICATIONINSIGHTS_CONNECTION_STRING application setting in the App Service pointing to the Application Insights resource.; Assign the developers the Snapshot Debugger role on the Application Insights resource.

Answer

Configure the APPLICATIONINSIGHTS_CONNECTION_STRING application setting in the App Service pointing to the Application Insights resource, and assign the developers the Snapshot Debugger role on the Application Insights resource.
Enabling the Snapshot Debugger requires configuring the connection string so the Application Insights SDK can authenticate and send telemetry data. Viewing the collected snapshots in the Azure portal requires the Snapshot Debugger role (or Owner/Contributor roles) to be assigned to the developers' Microsoft Entra identities.

Step-by-Step Solution

1
Ensure the application is configured to connect to the Application Insights resource by setting the connection string app setting.
The SDK is initialized and knows the endpoint to transmit telemetry data.
Without a valid connection string, the application cannot transmit exception snapshots to the target Application Insights resource.
2
Assign the Snapshot Debugger role to the developer accounts.
Developers obtain permissions to view diagnostic call stacks and debug snapshots in the Azure portal.
Access to view sensitive snapshot debug data is protected by Azure Role-Based Access Control (RBAC) and requires the Snapshot Debugger role or administrative access.

Key Concept

Configuring requirements and access roles for Application Insights Snapshot Debugger.
Question 913Question

A C# financial auditing application needs to update the custom metadata on an existing block blob containing a transaction ledger. To prevent concurrent write operations from other clients, the application must implement lease-controlled metadata updates using the Azure SDK for .NET. Which of the following sequences represents the correct order of steps the application must execute to perform this update securely?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order of operations begins with instantiating a `BlobClient` to reference the target blob. Next, a `BlobLeaseClient` is created and `AcquireAsync` is invoked to secure a lease. Once the lease is acquired, `GetPropertiesAsync` is called with the lease ID in the request conditions to read the current state. Afterward, `SetMetadataAsync` is executed with the updated metadata and the lease ID in the request conditions. Finally, the lease is released using `ReleaseAsync` on the lease client.
The correct order requires establishing the client connection first, obtaining a write lock (lease) to ensure concurrency control, fetching the current properties under that lease, applying the metadata change using the lease ID, and finally releasing the lease so others can access the blob.

Step-by-Step Solution

1
Instantiate a `BlobClient` object.
Establishes a connection to the target blob resource in Azure Storage.
All subsequent operations, including lease acquisition and metadata updates, require a reference to the target blob.
2
Create a `BlobLeaseClient` and call `AcquireAsync`.
Obtains a unique lease ID and places a write lock on the blob.
The lease must be acquired before reading the current state or applying updates to prevent race conditions.
3
Call `GetPropertiesAsync` passing the lease ID.
Retrieves the current metadata and properties of the leased blob.
Accessing the blob's properties requires passing the lease ID in `BlobRequestConditions` since the blob is now locked.
4
Call `SetMetadataAsync` passing the updated metadata and the lease ID.
Updates the custom metadata on the block blob.
Writing metadata to a leased blob requires the active lease ID in the `BlobRequestConditions` to authorize the modification.
5
Call `ReleaseAsync` on the lease client.
Releases the write lock on the blob.
Releasing the lease allows other instances of the application or other clients to obtain a lease and make modifications.

Key Concept

Lease-controlled blob operations in Azure Blob Storage using the .NET SDK.
Estimated Time:2m 0s
Question 914Question

You are developing a client-side React single-page application (SPA) that will run in users' web browsers. The application must authenticate users against Microsoft Entra ID and access a secure downstream web API. You need to configure the authentication and identity settings for the React application. Which configuration should you implement in Microsoft Entra ID?

Show answer & explanation

Answer: Register the application in Microsoft Entra ID, configure a redirect URI with the Single-page application (SPA) platform type, and use the authorization code flow with PKCE.

Answer

Register the application in Microsoft Entra ID, configure a redirect URI with the Single-page application (SPA) platform type, and use the authorization code flow with PKCE.
The correct option is to register the application in Microsoft Entra ID with the platform type set to Single-page application (SPA) and use the authorization code flow with PKCE. Because the React app runs in the user's browser, it is a public client and cannot secure a client secret. PKCE eliminates the need for a client secret while protecting the flow against authorization code interception attacks. Furthermore, registering as an SPA enables the necessary CORS support on Entra ID token endpoints.

Step-by-Step Solution

1
Analyze the client application architecture.
The application is a client-side React Single-Page Application (SPA) running entirely in the user's web browser.
Understanding the execution environment is crucial to determine if the client is public (cannot protect secrets) or confidential (can protect secrets).
2
Determine the appropriate authentication flow.
The Authorization Code Flow with Proof Key for Code Exchange (PKCE) is the standard and secure flow for client-side applications.
PKCE protects the authorization code from interception without requiring a client secret.
3
Configure the platform type in Microsoft Entra ID App Registration.
Register the Redirect URI under the Single-page application (SPA) platform type.
The SPA platform type ensures Microsoft Entra ID issues tokens using the authorization code flow with PKCE and supports the required Cross-Origin Resource Sharing (CORS) headers.

Key Concept

Selecting the correct platform registration and authentication flow in Microsoft Entra ID for public client applications.
Question 915Question

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 916Question

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 917Question

You are developing a background daemon service named ConfigSync that runs as a containerized application in Azure Container Instances. The service must periodically query Microsoft Graph to read tenant group memberships to synchronize configurations. No user is signed in when the service runs.

You register the application in Microsoft Entra ID. You need to configure the API permissions for the application registration while adhering to the principle of least privilege.

Which configuration should you implement?

Show answer & explanation

Answer: Add Microsoft Graph Application permissions for GroupMember.Read.All, and have a global administrator grant admin consent.

Answer

Add Microsoft Graph Application permissions for GroupMember.Read.All, and have a global administrator grant admin consent.
The service runs as a background daemon without any user signed in, which dictates the use of the client credentials flow and Microsoft Graph Application permissions. To follow the principle of least privilege, GroupMember.Read.All should be chosen over Group.Read.All because it limits access strictly to reading memberships rather than full group properties. Application permissions always require a global administrator to grant admin consent.

Step-by-Step Solution

1
Determine the application type and interaction model.
Since the ConfigSync service runs as a background daemon with no user signed in, it must use the client credentials flow which requires Application permissions rather than Delegated permissions.
Delegated permissions require a signed-in user to act on behalf of, whereas Application permissions are used by applications that run without a signed-in user.
2
Select the permission scope adhering to the principle of least privilege.
Select GroupMember.Read.All instead of Group.Read.All.
GroupMember.Read.All is more restricted as it only allows reading group memberships and basic member profiles, whereas Group.Read.All allows reading all group properties and settings.
3
Determine the consent requirement.
A global administrator must grant admin consent for the tenant.
Application permissions always require administrator consent before they can be used by the application.

Key Concept

Microsoft Entra ID Application permissions and Client Credentials flow for background daemon services
Question 918Question

A SaaS application uses the Azure Cosmos DB .NET SDK v3 to store user settings in a container. The container is configured with Session consistency and is partitioned by `TenantId`. You are writing C# code to replace a user's settings document.

To ensure data consistency and verify the update immediately from a separate client instance, you need to execute the write and pass the session state to the second client.

Which code segment should you use to achieve this?

Show answer & explanation

Answer: ItemResponse<UserSettings> writeResponse = await container.ReplaceItemAsync<UserSettings>(
settings,
settings.Id,
new PartitionKey(settings.TenantId)
);
string sessionToken = writeResponse.Headers.Session;

ItemResponse<UserSettings> readResponse = await otherContainer.ReadItemAsync<UserSettings>(
settings.Id,
new PartitionKey(settings.TenantId),
new ItemRequestOptions { SessionToken = sessionToken }
);

Answer

The correct option is the code segment that replaces the item using the TenantId partition key, extracts the session token from the write response headers, and applies it to the read request options of the second client.
The correct code segment uses the Azure Cosmos DB .NET SDK v3 ReplaceItemAsync method with the correct parameters (item, id, PartitionKey). By default, Session consistency is scoped to a single client instance. To guarantee read-your-writes across multiple client instances, you must extract the session token from the write response header (Headers.Session) and pass it to the read operation of the second client using ItemRequestOptions.

Step-by-Step Solution

1
Call ReplaceItemAsync using the SDK v3 client.
The item is successfully replaced, returning an ItemResponse object.
SDK v3 requires passing the item, the item ID, and the PartitionKey for point-replace operations.
2
Extract the session token from the write response headers.
The session token string is captured via writeResponse.Headers.Session.
This token is needed to maintain consistency state across separate client instances.
3
Pass the session token in the ItemRequestOptions during the read operation.
The second client instance reads the updated data immediately.
Without passing the session token, Session consistency guarantees are limited to the client instance that performed the write.

Key Concept

Handling item operations and managing cross-client session consistency using the Azure Cosmos DB .NET SDK v3.
Question 919Question

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 920Question

You are deploying an Azure App Service web application that must retrieve a database connection string from an Azure Key Vault without modifying the application code. You plan to configure an application setting in App Service to reference the Key Vault secret directly. The secret is located at the URI: https://contosovault.vault.azure.net/secrets/dbconn/f3b890. Which syntax format must you use for the App Service application setting value to reference this secret?

Show answer & explanation

Answer: @Microsoft.KeyVault(SecretUri=https://contosovault.vault.azure.net/secrets/dbconn/f3b890)

Answer

The syntax prefixing the secret's URI with @Microsoft.KeyVault(SecretUri=...) is correct.
The correct answer is the syntax prefixing the URI with @Microsoft.KeyVault(SecretUri=...). When App Service detects this pattern, it resolves the secret from Key Vault on behalf of the application using the application's managed identity.

Step-by-Step Solution

1
Identify the requirement to resolve an Azure Key Vault secret inside an App Service configuration setting.
The App Service must use the Key Vault reference syntax to intercept the environment variable loading and fetch the secret value.
This allows the application to retrieve secrets dynamically without requiring custom Key Vault SDK integration.
2
Select the correct provider prefix and parameter for the reference.
The provider prefix must be '@Microsoft.KeyVault' and the parameter must be 'SecretUri'.
The App Service runtime specifically parses '@Microsoft.KeyVault' and expects 'SecretUri' as the parameter containing the full secret URL.

Key Concept

Azure Key Vault Reference Syntax in App Service
PreviousPage 46 / 49Next
All practice questions — Microsoft Azure Developer (AZ-204) | Examkin