All practice questions

972 questions

Question 741Question

An API gateway implemented via Azure API Management (APIM) needs to forward requests to a backend microservice secured by Microsoft Entra ID. The APIM instance is configured with a user-assigned managed identity named `apim-identity`. The backend service expects an Entra ID access token from this specific managed identity. Which policy configuration should you apply to authenticate requests using this user-assigned managed identity?

Show answer & explanation

Answer: Place the <authentication-managed-identity resource="api://backend-app-id" client-id="00000000-0000-0000-0000-000000000000" /> policy inside the <inbound> section of the API policy XML.

Answer

Place the authentication-managed-identity policy with the specified resource and client-id attributes inside the inbound section of the API policy XML.
The correct answer configuration places the `<authentication-managed-identity>` policy in the `<inbound>` block, specifying the target backend application's audience scope via the `resource` attribute, and the `client-id` of the user-assigned managed identity. This configuration correctly retrieves the token prior to the request forwarding phase and instructs API Management which specific user-assigned identity to utilize.

Step-by-Step Solution

1
Determine the correct policy section for attaching authentication credentials to the backend request.
Identify the inbound policy section as the target because authentication tokens must be obtained and attached to the header before the request is transmitted to the backend microservice.
The outbound section is processed after the backend response has returned, which is too late to authorize the initial request.
2
Configure the policy attributes for a user-assigned managed identity.
Define the authentication-managed-identity policy, passing the backend application's resource URI and the client-id of the user-assigned managed identity.
Unlike system-assigned identities, user-assigned identities require the client-id or resource-id to be explicitly specified in order to locate the correct identity credentials.

Key Concept

Defining backend authentication policies in Azure API Management using user-assigned managed identities.
Question 742Question

You are developing a C# console application that needs to authenticate users using the Microsoft Identity Platform. The application must support signing in users from any Microsoft Entra ID tenant, but must explicitly prevent users with personal Microsoft accounts (such as Xbox, Outlook.com, or Skype accounts) from signing in.

You have the following C# code to build the public client application:

csharp
var app = PublicClientApplicationBuilder.Create(clientId)
.WithAuthority(authority)
.WithRedirectUri(redirectUri)
.Build();

Which value should you assign to the `authority` variable?

Show answer & explanation

Answer: https://login.microsoftonline.com/organizations

Answer

https://login.microsoftonline.com/organizations
The authority endpoint https://login.microsoftonline.com/organizations is designed specifically for multi-tenant applications that only allow work or school accounts from Microsoft Entra ID tenants, thereby excluding personal Microsoft accounts.

Step-by-Step Solution

1
Analyze the tenant requirements for the application.
The application must support multi-tenant authentication for all Microsoft Entra ID directories, but must exclude personal Microsoft accounts.
This filters the choice of authority endpoints based on audience type.
2
Evaluate the standard Microsoft Identity Platform v2.0 authority endpoints.
The endpoint ending in '/organizations' targets work or school accounts from any tenant, while '/common' includes personal accounts, and '/consumers' includes only personal accounts.
Choosing the correct endpoint ensures compliance with the target user audience constraints.
3
Assign the correct endpoint URI to the authority configuration in MSAL.NET.
Setting the authority to 'https://login.microsoftonline.com/organizations' completes the client application configuration correctly.
This passes the correct target audience to the client application builder.

Key Concept

Microsoft Identity Platform multi-tenant authority endpoints
Estimated Time:1m 30s
Question 743Question

A developer is designing a distributed caching system using Azure Cache for Redis to store product catalog data for a highly concurrent e-commerce platform. The system must implement the Cache-Aside pattern, prevent race conditions during concurrent database updates, and prevent memory exhaustion under high load. Which two practices should the developer implement? (Select two).

Select all that apply

Show answer & explanation

Answer: When data is updated in the database, invalidate the corresponding cache key rather than updating the key with the new value.; Apply a Time-to-Live (TTL) value when writing items to the cache to ensure that unused product details are eventually purged from memory.

Answer

The developer should invalidate the corresponding cache key rather than updating it directly when the database changes, and apply a Time-to-Live (TTL) value when writing items to the cache to prevent memory exhaustion.
The correct practices are to invalidate the cache key when updating the database and to configure a Time-to-Live (TTL) for cached items. Invalidating the key prevents race conditions where out-of-order writes leave stale data in the cache. Setting a TTL ensures that old or unused data is purged from memory, keeping the cache clean and preventing memory exhaustion.

Step-by-Step Solution

1
Analyze concurrency safety in the Cache-Aside pattern.
Identify that concurrent writes to the database and direct cache updates can arrive out-of-order, leading to stale data.
Invalidating the cache key is the safest mechanism to ensure data consistency because the next read will pull the single source of truth from the database.
2
Evaluate memory management strategies under load.
Determine that applying a Time-to-Live (TTL) allows Redis to automatically clean up keys that are no longer active.
TTL configuration naturally mitigates memory pressure by deleting stale entries without relying on aggressive global eviction policies.
3
Examine the behavior of the noeviction policy.
Recall that when memory limit is hit under noeviction, any commands that attempt to allocate more memory will return an error.
This shows that the noeviction policy degrades application write capability rather than keeping it unblocked.

Key Concept

Cache-Aside data pattern consistency and memory management using TTL.
Question 744Question

You are configuring database persistence for a newly provisioned Azure Cache for Redis instance in the Premium tier to ensure data can be recovered in the event of a cache failure. You decide to implement Redis database (RDB) persistence.

Which sequence of steps must you perform in the Azure Portal to configure and enable RDB persistence?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To configure RDB database persistence in the Azure Portal, you must navigate to the Data persistence menu of the Premium tier cache, select the RDB option, set the Backup Frequency, choose the Storage Account and container, and click Save.
Configuring RDB persistence requires first navigating to the Data persistence section of a Premium cache, enabling the RDB option, specifying the backup interval, configuring the target Azure Storage Account, and finally saving the changes to apply them.

Step-by-Step Solution

1
Navigate to the Data persistence settings.
The Data persistence blade is opened, displaying options for Disabled, RDB, and AOF.
This is the entry point for configuring persistence in Azure Cache for Redis.
2
Enable RDB persistence.
The RDB configuration options are exposed.
RDB is disabled by default; enabling it is required to expose the backup parameters.
3
Select a backup frequency.
A specific backup interval (e.g., 15 minutes) is configured.
This defines the snapshot interval for taking point-in-time backups.
4
Configure the storage account destination.
The destination container is linked to the cache instance.
Azure Cache for Redis requires a storage account in the same region to store the backup files.
5
Save the configuration.
The configuration is committed and the cache begins RDB persistence.
Any changes made in the Azure Portal are pending until explicitly saved.

Key Concept

Redis Database (RDB) Persistence Configuration
Question 745Question

You are developing a logistics tracking application that processes real-time location updates from delivery vehicles. To maintain the correct timeline of movements, updates for each vehicle must be processed in the exact chronological order they are received. You configure an Azure Service Bus queue with session support enabled.

You need to write the C# code using the Azure.Messaging.ServiceBus SDK to read these messages reliably. If a processing node fails, the message must not be lost.

Which approach should you use to instantiate and configure the receiver?

Show answer & explanation

Answer: Call AcceptNextSessionAsync on a ServiceBusClient to obtain a ServiceBusSessionReceiver, keeping the default PeekLock receive mode.

Answer

Call AcceptNextSessionAsync on a ServiceBusClient to obtain a ServiceBusSessionReceiver, keeping the default PeekLock receive mode.
The correct approach is to call AcceptNextSessionAsync to obtain a ServiceBusSessionReceiver while maintaining the default PeekLock receive mode. This ensures that session locks are respected for strict FIFO processing, and that messages are not lost if the processor crashes because the message is only completed after successful processing.

Step-by-Step Solution

1
Select the correct receiver class for session-enabled queues.
Identify that ServiceBusSessionReceiver must be used rather than ServiceBusReceiver.
Azure Service Bus requires session receivers to acquire a lock on a session and process messages within that session in FIFO order.
2
Determine the appropriate receive mode for reliability.
Select PeekLock mode instead of ReceiveAndDelete.
PeekLock ensures that the message remains on the queue locked by the receiver. If the receiver crashes, the lock expires and the message is made available again, preventing data loss.
3
Combine the session receiver initialization with the correct receive mode configuration.
Use AcceptNextSessionAsync with the default PeekLock receive mode.
This configuration satisfies both the session-based ordering and the message processing reliability requirements.

Key Concept

To process session-enabled Azure Service Bus queues reliably and in order, a session receiver must be used with the PeekLock receive mode.
Question 746Question

You are developing a secure C# application using the Azure.Storage.Blobs SDK (v12) to generate a User Delegation SAS token. An external client requires temporary, read-only access to a specific blob named "backup.bak" in a container named "db-backups".

The security requirements are as follows:
- Access must be restricted to HTTPS only.
- Access must be restricted to the client's IP address "203.0.113.88".
- The token must account for potential client-server clock desynchronization (clock skew).
- The token must grant only the minimum necessary permissions.

You write the following code:

csharp
var sasBuilder = new BlobSasBuilder
{
BlobContainerName = "db-backups",
BlobName = "backup.bak",
Resource = [PLACEHOLDER_RESOURCE],
StartsOn = [PLACEHOLDER_START],
ExpiresOn = DateTimeOffset.UtcNow.AddHours(2),
Protocol = [PLACEHOLDER_PROTOCOL],
IPRange = [PLACEHOLDER_IP]
};
sasBuilder.SetPermissions([PLACEHOLDER_PERMISSIONS]);

Which set of properties correctly configures the BlobSasBuilder to meet the security requirements?

Show answer & explanation

Answer: Resource = "b", StartsOn = DateTimeOffset.UtcNow.AddMinutes(-15), Protocol = SasProtocol.Https, IPRange = SasIPRange.Parse("203.0.113.88"), and Permissions = BlobSasPermissions.Read

Answer

The correct configuration is the one that sets Resource to "b", StartsOn with a 15-minute clock skew buffer, Protocol to HTTPS, specifies the exact client IP address, and grants Read permissions.
The correct configuration specifies Resource = "b" (which scopes the token to a single blob rather than the entire container), subtracts 15 minutes from UtcNow to handle potential client-server clock desynchronization (clock skew), sets the protocol to HTTPS only, restricts the IP range to the client's IP, and limits permissions to Read only, satisfying all security constraints.

Step-by-Step Solution

1
Determine the correct resource scope and permissions for the BlobSasBuilder.
Because access is restricted to a single blob named 'backup.bak', the Resource property must be set to 'b' (blob) rather than 'c' (container). The permissions must be limited strictly to BlobSasPermissions.Read to maintain least privilege.
Setting Resource to 'c' would grant access to all blobs in the container, violating the least privilege rule.
2
Configure the security protocol and network constraints on the builder.
The Protocol property must be set to SasProtocol.Https, and the IPRange must be configured to SasIPRange.Parse("203.0.113.88") to restrict operations to the designated client.
This guarantees that client requests are encrypted in transit over HTTPS and originate only from the specified partner IP address.
3
Provide a buffer for clock synchronization issues between client and server.
Set the StartsOn property to a time slightly in the past, such as DateTimeOffset.UtcNow.AddMinutes(-15).
Without a buffer, if the client's clock is slightly ahead of the Azure storage server, the token will be rejected as not yet valid.

Key Concept

Configuring a secure User Delegation Shared Access Signature (SAS) token using the Azure Storage .NET SDK (Azure.Storage.Blobs) to enforce least-privilege, clock skew handling, protocol restrictions, and IP restrictions.
Estimated Time:1m 30s
Question 747Question

You maintain a Premium tier Azure Cache for Redis instance that supports a high-throughput data processing application. The application frequently writes, updates, and deletes large, complex serialized objects. During peak loads, the hosting virtual machines experience out-of-memory (OOM) crashes, even though the Used Memory metric reported by the cache remains below the allocated maxmemory limit. You observe that the memory fragmentation ratio is high. You need to configure the cache to prevent these VM-level OOM crashes by forcing Redis to perform evictions or fail writes before physical memory is exhausted. Which configuration setting should you adjust?

Show answer & explanation

Answer: Increase the maxfragmentationmemory-reserved configuration setting.

Answer

Increase the maxfragmentationmemory-reserved configuration setting.
Increasing the maxfragmentationmemory-reserved configuration setting reserves a specified amount of physical memory to accommodate fragmentation. When the physical memory usage exceeds the allowed threshold minus this reserved value, Redis starts evicting keys or failing writes according to the maxmemory-policy. This prevents the hosting virtual machine's operating system from running out of physical memory and crashing the Redis process.

Step-by-Step Solution

1
Analyze the crash symptoms and metrics.
The VM crashes due to system-level OOM, but the Used Memory metric is below the maxmemory limit, indicating that memory fragmentation is the primary driver of physical memory exhaustion.
Used Memory measures logical memory allocated for data keys, but doesn't fully represent the actual physical memory footprint when fragmentation is high.
2
Identify the configuration setting designed to mitigate fragmentation-induced OOM crashes.
The maxfragmentationmemory-reserved setting defines the buffer size in megabytes reserved specifically to absorb memory fragmentation.
Having this setting configured forces Redis to start reclaiming memory or rejecting writes when the physical memory limit is approached, preventing the OS from terminating the Redis process.
3
Select the correct option that matches the required configuration.
Increasing the maxfragmentationmemory-reserved setting is selected.
This is the targeted setting in Azure Cache for Redis to prevent VM-level OOM crashes caused by memory fragmentation.

Key Concept

Azure Cache for Redis memory management settings and OOM prevention.
Question 748Question

You are developing a containerized API that will run on Azure Container Instances. The container groups are frequently created, destroyed, and recreated via automated workflows. The API must authenticate to the Microsoft Identity Platform to retrieve configuration keys from Azure App Configuration. You must ensure that recreating the Container Instances does not require updating permission grants in Azure App Configuration. Which two configurations should you implement? (Select two.)

Select all that apply

Show answer & explanation

Answer: Create a user-assigned managed identity, assign it to the container group, and grant it the App Configuration Data Reader role.; Instantiate DefaultAzureCredential by passing DefaultAzureCredentialOptions with the ManagedIdentityClientId property set to the client ID of the user-assigned managed identity.

Answer

Use a user-assigned managed identity assigned to the container group and configure DefaultAzureCredentialOptions in code using the client ID of that identity.
A user-assigned managed identity operates as a standalone Azure resource, so its lifecycle is decoupled from the container instances. Recreating the container instances will not delete the identity or its assigned roles. When writing the authentication code, DefaultAzureCredential needs to know which user-assigned identity to use, which is achieved by specifying the client ID via DefaultAzureCredentialOptions.ManagedIdentityClientId.

Step-by-Step Solution

1
Analyze the resource lifecycle requirements.
Determine that because the container groups are frequently destroyed and recreated, a system-assigned managed identity is unsuitable as its credentials and role assignments would be deleted along with the resource.
A user-assigned managed identity exists as a standalone Azure resource, meaning its identity and role assignments persist independently of the container lifecycle.
2
Create and associate the identity.
Create a user-assigned managed identity, assign it to the container group, and grant it the App Configuration Data Reader role in the Azure App Configuration resource.
This establishes the identity, links it to the container group, and grants the minimum required access permissions to retrieve configuration data.
3
Configure the Azure SDK client in application code.
Instantiate DefaultAzureCredential passing an instance of DefaultAzureCredentialOptions with the ManagedIdentityClientId property configured to the client ID of the user-assigned managed identity.
Explicitly passing the client ID is necessary because a resource can have multiple user-assigned managed identities, and the SDK needs to know which specific identity to use for token acquisition.

Key Concept

User-assigned managed identity lifecycle and Client ID configuration in Azure SDK / MSAL authentication.
Question 749Question

A gaming company uses an Azure Cache for Redis instance to store real-time leaderboard statistics and user session states. The leaderboard keys must persist indefinitely and are not configured with a Time-to-Live (TTL). The user session keys are configured with a sliding TTL. During peak gaming events, the cache reaches its memory limit, causing write operations to fail. You need to configure the cache to automatically evict the user session keys that are accessed the least frequently to free up memory, while ensuring that the leaderboard keys are never evicted. Which eviction policy should you configure to meet these requirements?

Show answer & explanation

Answer: volatile-lfu

Answer

volatile-lfu
The volatile-lfu policy evicts the least frequently used keys among those that have an expiration (TTL) set. Because only the user session keys have a TTL configured, and the leaderboard keys do not, this policy guarantees that leaderboard keys are preserved. Additionally, it uses the Least Frequently Used (LFU) algorithm, satisfying the requirement to evict keys based on access frequency.

Step-by-Step Solution

1
Analyze key configuration constraints.
Leaderboard keys do not have a TTL and must be protected. User session keys have a TTL and can be evicted.
This limits the choice of eviction policies to the volatile family, which only target keys with an expiration set.
2
Determine the access pattern requirement for eviction.
The keys that are accessed the least frequently must be evicted.
This indicates that a Least Frequently Used (LFU) algorithm must be used rather than a Least Recently Used (LRU) algorithm.
3
Select the policy combining volatile scope and LFU algorithm.
The volatile-lfu policy is selected.
This policy ensures that only keys with an expiration set are evaluated using the LFU algorithm.

Key Concept

Selecting the correct Redis eviction policy based on TTL configuration and access patterns to prevent data loss of critical keys.
Question 750Question

You are developing a solution that stores sensitive media files in an Azure Blob Storage container named mediafiles. You need to grant a partner application temporary access to read and list the blobs in this container. The security requirements state that you must be able to revoke this access immediately if a compromise occurs, without rotating the storage account keys or affecting other SAS tokens.

Which two actions should you perform to implement this security requirement?

Select all that apply

Show answer & explanation

Answer: Create a stored access policy on the container.; Generate a service SAS that is associated with the stored access policy.

Answer

To implement the revocation requirement, you should create a stored access policy on the container and then generate a service SAS that is associated with that stored access policy.
Creating a stored access policy on the container and generating a service SAS that references it is correct because it allows the SAS lifetime and permissions to be managed directly by the policy. If a compromise is suspected, the policy can be deleted or updated, instantly revoking all SAS tokens that reference it without affecting other services or requiring account key rotation.

Step-by-Step Solution

1
Define the stored access policy on the specific blob container.
A policy containing the permissions (read and list) and validity duration is created, which can be modified or deleted on demand.
This provides a single point of control for access configuration that can be altered to invalidate associated SAS tokens immediately.
2
Generate a service SAS for the partner application, binding it to the stored access policy.
A service SAS token is generated that points to the container and inherits its constraints from the stored access policy.
By using a service SAS bound to the policy rather than an account SAS, the token's lifetime and validity are tied directly to the container-level policy.

Key Concept

Stored Access Policies and SAS Revocation
Question 751Question

You are developing a C# console application to consume messages from an Azure Service Bus queue using the Azure.Messaging.ServiceBus SDK. You need to initialize, execute, and cleanly terminate a ServiceBusProcessor to process messages asynchronously. Which of the following sequences represents the correct chronological order of steps required to achieve this?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins with instantiating a ServiceBusClient, followed by calling CreateProcessor. Next, you register the ProcessMessageAsync and ProcessErrorAsync event handlers, then call StartProcessingAsync. To shut down, you call StopProcessingAsync and finally call DisposeAsync on both the processor and client.
Establishing a connection requires first instantiating the ServiceBusClient, then using it to obtain a ServiceBusProcessor. You must register the required message and error event handlers on the processor before invoking StartProcessingAsync. During application shutdown, you must cleanly halt message retrieval by calling StopProcessingAsync before freeing resources via DisposeAsync.

Step-by-Step Solution

1
Instantiate a ServiceBusClient using the connection string.
A ServiceBusClient connection is established.
The client is the primary factory class used to create processors.
2
Call CreateProcessor on the client.
A ServiceBusProcessor instance is obtained.
The processor is scoped to a specific queue and handles message fetching.
3
Register the ProcessMessageAsync and ProcessErrorAsync handlers.
Event handlers are bound to the processor.
The SDK requires both handlers to be registered before processing can begin.
4
Call StartProcessingAsync.
The message pump is activated.
This starts the background message receiving loop.
5
Call StopProcessingAsync.
Message reception is stopped.
This is necessary to gracefully stop processing before disposing resources.
6
Call DisposeAsync on the processor and client.
Network and client resources are freed.
Clean disposal prevents resource leaks and hanging TCP connections.

Key Concept

ServiceBusProcessor Lifecycle Management
Question 752Question

Your company is configuring SSL/TLS certificates for a web application and wants to automate the certificate renewal lifecycle using an integrated Certificate Authority (CA) partner, DigiCert. You need to configure Azure Key Vault to automatically request and renew certificates from DigiCert. Which sequence of actions must you perform to configure the integrated certificate auto-renewal?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

Retrieve the organization ID, API key, and account credentials from the partner Certificate Authority; register the partner Certificate Authority as a certificate issuer in the Azure Key Vault using the retrieved credentials; create a certificate policy in the Azure Key Vault that specifies the registered issuer and configures a lifetime trigger for auto-renewal; and create the certificate in the Azure Key Vault using the configured certificate policy to initiate the initial enrollment and enable automatic renewals.
The correct configuration sequence for integrated CA certificate auto-renewal begins with obtaining the credentials from the CA provider. Next, these credentials are used to register the CA as an issuer object within the Key Vault. Once the issuer exists, you define a certificate policy referencing that issuer and setting the auto-renewal lifetime trigger. Finally, you create the certificate based on that policy to trigger the initial generation and establish the auto-renewal lifecycle.

Step-by-Step Solution

1
Retrieve organization details and API keys from DigiCert.
Credentials are ready to be used in Azure Key Vault.
Azure Key Vault requires CA account credentials to authenticate and communicate with the partner CA.
2
Register the partner CA as an issuer in the Key Vault.
An issuer object is created in the Key Vault.
A certificate policy cannot reference an issuer until the issuer is registered in the Key Vault.
3
Create a certificate policy containing issuer details and lifetime actions.
A policy defining the auto-renewal percentage trigger is ready.
The policy must exist to define the properties of the certificate and specify that the CA should auto-renew it at a specific lifetime milestone.
4
Create the certificate in Key Vault using the policy.
The initial certificate is generated and auto-renewal is active.
This initiates the initial contact with the CA and configures the certificate for the automated renewal cycle.

Key Concept

Azure Key Vault integrated Certificate Authority auto-renewal configuration
Question 753Question

You are configuring policies for an Azure API Management (APIM) gateway that routes requests to a backend microservice. You must meet the following requirements:
1. Authenticate the gateway to the backend microservice by using the APIM instance's system-assigned managed identity to acquire a Microsoft Entra ID token.
2. Strip the X-Powered-By header from the response returned by the backend microservice before the response is sent back to the clients.

Which policy configuration should you use?

Show answer & explanation

Answer: <policies>
<inbound>
<base />
<authentication-managed-identity resource="https://graph.microsoft.com" />
</inbound>
<backend>
<base />
</backend>
<outbound>
<base />
<set-header name="X-Powered-By" exists-action="delete" />
</outbound>
<on-error>
<base />
</on-error>
</policies>

Answer

The configuration that places the authentication-managed-identity policy without a client-id inside the inbound section, and the set-header policy with exists-action="delete" inside the outbound section.
The correct configuration places the authentication-managed-identity policy (with only the resource attribute specified) in the inbound section. This correctly triggers authentication using the system-assigned managed identity before routing. It also places the set-header policy in the outbound section with exists-action="delete" to successfully strip the X-Powered-By header from the backend response before returning it to the client.

Step-by-Step Solution

1
Determine the proper placement of the authentication policy.
The authentication-managed-identity policy must be placed in the inbound section to acquire the Microsoft Entra ID token before the request is forwarded to the backend microservice.
Inbound policies process the request before it reaches the backend.
2
Configure the managed identity parameters for system-assigned managed identity.
Omit both the client-id and identity-resource-id attributes from the authentication-managed-identity tag.
By default, omitting these attributes causes Azure API Management to use the system-assigned managed identity.
3
Determine the proper placement and action of the header removal policy.
Place a set-header policy inside the outbound section with the header name set to 'X-Powered-By' and exists-action set to 'delete'.
Response headers returned by the backend microservice are modified in the outbound section before being returned to the client.

Key Concept

Azure API Management policy sections and identity configuration
Question 754Question

You are designing an ASP.NET Core Web API that is called by a web-based front-end client application. The Web API needs to request data from a downstream reporting database service. To comply with data privacy policies, the requests to the downstream service must execute under the security context of the specific user who logged into the front-end application, allowing the reporting service to audit access by individual user accounts. Which authentication flow and client application type should you implement in the Web API to meet these requirements?

Show answer & explanation

Answer: The OAuth 2.0 On-Behalf-Of flow using a confidential client application

Answer

The OAuth 2.0 On-Behalf-Of flow using a confidential client application
The OAuth 2.0 On-Behalf-Of flow is specifically designed for Web APIs that need to call downstream APIs while propagating the original user's identity and permissions. Because a Web API runs on a server and can protect credentials, it must be implemented as a confidential client application.

Step-by-Step Solution

1
Evaluate the context propagation requirement.
Identify that requests to the downstream service must run under the user's security context to allow individual user auditing.
This rules out authentication flows that use application-only identities, such as client credentials or managed identities.
2
Determine the application type and trust level of the Web API.
Since the Web API runs on a server and can safely hold credentials, it is classified as a confidential client application.
This requires using ConfidentialClientApplication in MSAL.NET rather than PublicClientApplication.
3
Match the flow to the multi-tier API authentication scenario.
Select the OAuth 2.0 On-Behalf-Of (OBO) flow.
The OBO flow is the standard mechanism in the Microsoft Identity Platform for a Web API to exchange the user's incoming assertion token for a token to access a downstream API on their behalf.

Key Concept

OAuth 2.0 On-Behalf-Of flow for user context propagation in Web APIs
Question 755Question

An application uses Azure Cache for Redis to store both temporary catalog search results and active shopping cart details. The transient catalog search results are configured with a defined Time-to-Live (TTL), while the shopping cart details are stored without a TTL. During periods of peak traffic, the cache memory becomes fully utilized. You must ensure that the Redis instance evicts the catalog search results based on a least-recently-used (LRU) algorithm when the memory limit is reached, while preserving all shopping cart details. In addition, you must reserve memory for replication and fragmentation overhead to prevent out-of-memory (OOM) conditions.

Which two configuration settings should you configure to meet these requirements?

Select all that apply

Show answer & explanation

Answer: Set the maxmemory-policy configuration setting to volatile-lru; Configure a non-zero value for the maxmemory-reserved setting

Answer

Setting the maxmemory-policy configuration setting to volatile-lru and configuring a non-zero value for the maxmemory-reserved setting.
The correct configurations are setting the eviction policy to volatile-lru and configuring a non-zero value for the maxmemory-reserved setting. The volatile-lru policy ensures that under memory pressure, only keys with an active expiration (TTL) set are evaluated and evicted using a least-recently-used (LRU) algorithm, preserving keys without an expiration. Configuring the maxmemory-reserved setting allocates dedicated memory for replication and fragmentation overhead, preventing out-of-memory conditions on the instance.

Step-by-Step Solution

1
Analyze the eviction requirements for keys with and without a TTL.
Determine that keys without a TTL (shopping cart details) must be protected, while keys with a TTL (search results) are eligible for LRU eviction.
This narrows the eviction policy choice to 'volatile' policies, specifically excluding 'allkeys' policies which evict any key regardless of expiration status.
2
Select the correct eviction algorithm based on the scenario description.
Identify 'volatile-lru' as the configuration that applies the least-recently-used algorithm only to keys with an expiration.
The scenario requires a least-recently-used (LRU) algorithm for eviction, making volatile-lru correct and volatile-ttl incorrect.
3
Address the requirement to prevent out-of-memory (OOM) conditions caused by overhead.
Identify that reserving memory using the 'maxmemory-reserved' setting secures space for replication and fragmentation.
Azure Cache for Redis provides the 'maxmemory-reserved' setting specifically to allocate memory for non-cache overhead and operations.

Key Concept

Azure Cache for Redis eviction policies and memory reservation configuration.
Question 756Question

A hotel reservation system uses an Azure Service Bus queue named `reservation-bookings` to process guest bookings. The processing application must ensure that booking requests are not lost if the application crashes during database updates.

You write a C# worker service using the `Azure.Messaging.ServiceBus` SDK to process these messages.

Which approach should you use to guarantee at-least-once delivery and processing of the booking messages?

Show answer & explanation

Answer: Receive the message with ServiceBusReceiveMode.PeekLock, process the booking, and then call CompleteMessageAsync after the database update succeeds.

Answer

Receive the message with ServiceBusReceiveMode.PeekLock, process the booking, and then call CompleteMessageAsync after the database update succeeds.
The correct approach is to use the PeekLock receive mode. In this mode, the message is locked during processing. Calling CompleteMessageAsync after the database update succeeds ensures the message is only deleted after the processing is fully complete. If a crash occurs before calling CompleteMessageAsync, the lock expires and the message is returned to the queue, ensuring at-least-once delivery.

Step-by-Step Solution

1
Configure the receiver to use PeekLock mode (which is the default receive mode).
The message is retrieved by the receiver and locked on the Service Bus queue for the lock duration, making it invisible to other receivers.
This guarantees that if the application crashes during processing, the lock will eventually expire and the message will reappear in the queue for retry.
2
Process the reservation request and write the changes to the database.
The database contains the updated guest booking.
The message must remain locked and not deleted from the queue until we are sure the database transaction has committed successfully.
3
Call CompleteMessageAsync on the ServiceBusReceiver.
The message is deleted from the queue.
This notifies Azure Service Bus that processing was successful and that it is safe to delete the message.

Key Concept

Azure Service Bus Receive Modes
Estimated Time:1m 30s
Question 757Question

You are developing a C# .NET 8 console application that runs on-premises and needs to manually send custom exception reports to Azure Application Insights. You retrieve the connection string from a secure local store.

You write the following code:

csharp
using Microsoft.ApplicationInsights;
using Microsoft.ApplicationInsights.Extensibility;

var connectionString = GetSecureConnectionString();
var configuration = TelemetryConfiguration.CreateDefault();
// INSERT CODE HERE
var telemetryClient = new TelemetryClient(configuration);

You need to complete the code to ensure that the Application Insights SDK is properly initialized and telemetry data is transmitted to the correct Azure resource. Which line of code should you insert?

Show answer & explanation

Answer: configuration.ConnectionString = connectionString;

Answer

Assign the retrieved connection string to the ConnectionString property of the TelemetryConfiguration object.
Assigning the connection string to configuration.ConnectionString correctly configures the telemetry endpoint and credentials for the TelemetryConfiguration object, which is then passed to the TelemetryClient constructor. This ensures that the SDK knows where to send telemetry data.

Step-by-Step Solution

1
Identify the configuration object used to initialize the telemetry client.
The TelemetryConfiguration object named configuration is used to initialize TelemetryClient.
The SDK requires the endpoint and credentials specified in the connection string to target the correct resource.
2
Set the appropriate property on the TelemetryConfiguration object.
Assign the connection string to the ConnectionString property.
Setting ConnectionString is the standard method to configure telemetry routing in modern Azure SDKs.

Key Concept

Configuring Application Insights manually using TelemetryConfiguration and ConnectionString
Question 758Question

Complete the Azure API Management (APIM) policy snippet to append or replace a query parameter in the backend request with the client's subscription ID.

Fill in the blanks below

You are configuring an inbound policy for an Azure API Management gateway. You need to ensure that a query parameter named `client-id` is sent to the backend service. If the `client-id` query parameter already exists in the incoming request, it must be overwritten with the subscription ID from the request context.

Complete the XML policy configuration by filling in the blanks.

xml
<inbound>
<base />
<
name="client-id" exists-action="">
<value>@(context.Subscription.Id)</value>
</
>
</inbound>
Show answer & explanation

Answer

blank_1 = set-query-parameter, blank_2 = override
The `<set-query-parameter>` policy adds, replaces, or deletes query parameters in the request sent to the backend. Setting the `exists-action` attribute to `override` ensures that any existing query parameter with the same name is replaced by the subscription ID from the request context.

Step-by-Step Solution

1
Identify the policy element that modifies query parameters in API Management.
The correct element is `<set-query-parameter>`.
This policy is specifically designed to add, replace, or delete query parameters.
2
Determine the correct value for the `exists-action` attribute to overwrite an existing query parameter.
The correct attribute value is `override`.
The `override` action ensures that if the query parameter is already present, its value will be replaced.

Key Concept

API Management policies can manipulate incoming requests to backends. The `<set-query-parameter>` policy modifies request query strings, and setting `exists-action` to `override` replaces any pre-existing query parameter value.
Question 759Question

A developer is configuring a C# ASP.NET Core web application hosted on an Azure App Service. The application must retrieve a database connection string stored in an Azure Key Vault named kv-prod using a Key Vault reference in the App Service configuration. The App Service is configured with a system-assigned managed identity. Which configuration should the developer apply to retrieve the secret value successfully?

Show answer & explanation

Answer: Set the application setting value to @Microsoft.KeyVault(SecretUri=https://kv-prod.vault.azure.net/secrets/db-conn/) and assign the Key Vault Secrets User role to the App Service system-assigned managed identity.

Answer

Set the application setting value to @Microsoft.KeyVault(SecretUri=https://kv-prod.vault.azure.net/secrets/db-conn/) and assign the Key Vault Secrets User role to the App Service system-assigned managed identity.
The correct configuration requires setting the application setting to the format @Microsoft.KeyVault(SecretUri=https://kv-prod.vault.azure.net/secrets/db-conn/) and granting the system-assigned managed identity the Key Vault Secrets User role. The SecretUri parameter is the correct syntax for referencing a secret by its URI, and the Key Vault Secrets User role provides the necessary permissions to read the secret's value at runtime.

Step-by-Step Solution

1
Define the App Service application setting value using the Key Vault reference syntax with the SecretUri parameter.
The setting is configured as @Microsoft.KeyVault(SecretUri=https://kv-prod.vault.azure.net/secrets/db-conn/).
This tells the App Service runtime to resolve the setting value from the specified Key Vault secret.
2
Assign the Key Vault Secrets User role to the system-assigned managed identity on the Key Vault.
The identity is authorized to retrieve the secret value.
Without this role (or equivalent access policy permissions), the App Service runtime will fail to retrieve the secret value, causing the setting to remain unresolved.

Key Concept

Key Vault References in App Service
Question 760Question

You are developing a C# background worker service that runs on an on-premises server. The service must periodically query a secured downstream web API without any user interaction. You register the service in Microsoft Entra ID as a daemon application. You need to write code using MSAL.NET to acquire an access token for the downstream API.

Which two code segments should you use to instantiate the application client and acquire the token? (Select two.)

Select all that apply

Show answer & explanation

Answer: var app = ConfidentialClientApplicationBuilder.Create(clientId).WithClientSecret(clientSecret).WithAuthority(authority).Build();; var result = await app.AcquireTokenForClient(scopes).ExecuteAsync();

Answer

To instantiate the application client and acquire the token for a daemon application, you must use ConfidentialClientApplicationBuilder to create the client and call AcquireTokenForClient to retrieve the token.
For daemon applications running without user interaction, MSAL.NET requires a confidential client application configuration. The correct setup uses ConfidentialClientApplicationBuilder to define the client with a client secret and AcquireTokenForClient to perform the OAuth 2.0 Client Credentials grant flow.

Step-by-Step Solution

1
Determine the application type and flow based on the scenario requirements.
Since the background worker service runs on an on-premises server without user interaction, it represents a daemon application that must use the OAuth 2.0 Client Credentials flow.
Daemon applications run headlessly and must authenticate using their own identity (app identity) rather than a user's identity.
2
Select the correct MSAL.NET application builder to instantiate the client.
Use ConfidentialClientApplicationBuilder because it supports configuring confidential clients with credentials like client secrets or certificates.
PublicClientApplicationBuilder does not support client credentials and is meant for interactive client applications.
3
Select the correct method to request and acquire the access token.
Call the AcquireTokenForClient method on the instantiated confidential client application instance.
AcquireTokenForClient initiates the non-interactive Client Credentials flow, whereas AcquireTokenInteractive requires a UI browser session for user interaction.

Key Concept

Authenticating daemon applications with MSAL.NET using the Client Credentials flow
PreviousPage 38 / 49Next
All practice questions — Microsoft Azure Developer (AZ-204) | Examkin