All practice questions

972 questions

Question 721Question

An Azure App Service plan named `asp-gateway` is currently running a microservice API gateway on the Standard S1 tier with 22 instances. You configure a scale-out autoscale rule that increases the instance count by 11 when the Average CPU percentage is greater than 80%80\% for 1010 minutes. To optimize costs when traffic decreases, you need to define a scale-in rule that decreases the instance count by 11. Which configuration should you choose to prevent autoscale flapping and ensure the rules function correctly?

Show answer & explanation

Answer: Configure the scale-in rule with a threshold of 50%50\% CPU percentage using the Average metric aggregation.

Answer

Configure the scale-in rule with a threshold of 50%50\% CPU percentage using the Average metric aggregation.
The configuration with a threshold of 50%50\% CPU percentage using the Average metric aggregation prevents flapping. When running on 22 instances at 80%80\% CPU utilization (total of 160%160\%), scaling out to 33 instances reduces the average CPU utilization per instance to approximately 53.3%53.3\%. Since 53.3%53.3\% is greater than the 50%50\% scale-in threshold, the autoscale engine will not immediately trigger a scale-in. Additionally, the Standard S1 tier supports autoscale rules.

Step-by-Step Solution

1
Calculate the total CPU capacity utilized at the scale-out threshold.
Total capacity utilized is 2×80%=160%2 \times 80\% = 160\%.
Before scaling out, the workloads are distributed across 22 instances, each approaching 80%80\%. The total load across all instances is the product of the instance count and the average CPU utilization threshold.
2
Calculate the average CPU utilization per instance immediately after scaling out.
New average utilization is 160%/353.3%160\% / 3 \approx 53.3\%.
When a scale-out is triggered, the instance count increases by 11 (totaling 33 instances). The total workload of 160%160\% is now distributed across these 33 instances, assuming uniform load distribution.
3
Determine the maximum allowable scale-in threshold to prevent flapping.
The scale-in threshold must be strictly less than 53.3%53.3\%.
If the scale-in threshold is set to a value higher than 53.3%53.3\% (such as 60%60\% or 70%70\%), the autoscale engine will immediately trigger a scale-in action after a scale-out event, creating a continuous loop of scaling up and down (flapping).
4
Verify hosting plan compatibility.
The App Service plan must remain on at least the Standard S1 tier.
Custom autoscale rules based on metrics require the Standard, Premium, or Isolated tier. Downgrading to the Basic B1 tier disables the autoscale engine's capabilities.

Key Concept

To prevent autoscale flapping, the scale-in metric threshold must be sufficiently lower than the post-scale-out utilization value, and the hosting plan must support autoscaling.
Estimated Time:1m 30s
Question 722Question

You are configuring policies for an API gateway in Azure API Management (APIM). The API gateway must meet the following requirements:
1. Restrict client request rates to a maximum of 100 calls per 60 seconds.
2. Remove a sensitive header named `X-Internal-Token` returned by the backend service before the response is sent back to the client.

Which two of the following policy configurations should you implement?

Select all that apply

Show answer & explanation

Answer: Place the rate-limiting configuration within the inbound section:
xml
<inbound>
<base />
<rate-limit calls="100" renewal-period="60" />
</inbound>
; Place the header deletion configuration within the outbound section:
xml
<outbound>
<base />
<set-header name="X-Internal-Token" exists-action="delete" />
</outbound>

Answer

The correct configurations are placing the rate-limit policy in the inbound section to throttle incoming requests, and placing the set-header policy with exists-action set to delete in the outbound section to remove the response header returned by the backend.
The rate-limit policy must be placed in the inbound section to intercept and throttle client requests before they are forwarded. The set-header policy with exists-action set to delete must be placed in the outbound section to remove the specified header from the backend response before returning it to the client.

Step-by-Step Solution

1
Analyze the rate-limiting requirement.
Rate limiting is an inbound operation that throttles incoming traffic before hitting the backend.
Placing rate limiting in inbound reduces unnecessary backend load and is the only valid section for this policy.
2
Analyze the header removal requirement.
The target header 'X-Internal-Token' is returned by the backend service in the response.
Since the header originates from the backend, it must be removed from the response payload within the outbound section before reaching the client.

Key Concept

Azure API Management policies are executed sequentially across different sections (inbound, backend, outbound, on-error). Choosing the correct policy section is essential for routing, throttling, and modifying requests or responses.
Question 723Question

You are configuring a C# ASP.NET Core web application hosted in Azure App Service to connect to a Premium tier Azure Cache for Redis instance. To align with security best practices, you must eliminate the use of access keys and implement Microsoft Entra ID authentication using the system-assigned managed identity of the App Service.

Which sequence of steps should you perform to configure and establish this secure connection?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To configure Microsoft Entra ID authentication using the system-assigned managed identity, first enable Microsoft Entra ID authentication on the Azure Cache for Redis instance. Second, assign a Redis Access Policy to the managed identity. Third, in the application code, acquire a Microsoft Entra ID token. Fourth, configure the StackExchange.Redis connection options using the Object ID of the managed identity as the username and the token as the password. Finally, establish the connection using the ConnectionMultiplexer.
Establishing a passwordless connection requires enabling Entra ID authentication on the Redis resource, configuring the appropriate Redis Access Policy for the managed identity, obtaining the JWT access token client-side, configuring the client to pass the Object ID and token, and finally establishing the connection.

Step-by-Step Solution

1
Enable Microsoft Entra ID authentication on the cache instance.
The Redis server is configured to accept token-based authentication connections.
By default, Azure Cache for Redis uses access keys. Entra ID authentication must be explicitly enabled.
2
Create a Redis Access Policy assignment linking the system-assigned managed identity to a role like Redis Data Reader or Redis Data Owner.
The identity is authorized to access the Redis data layer with specific permissions.
Authentication will fail if the identity does not have an active policy assignment mapping it to a permissions policy.
3
Acquire a token for the Redis resource inside the ASP.NET Core application using DefaultAzureCredential.
A short-lived JWT token is retrieved from Microsoft Entra ID representing the managed identity.
The client must present a valid Microsoft Entra token to Redis to authenticate.
4
Configure StackExchange.Redis ConnectionOptions, passing the Object ID as the username and the token as the password.
The connection metadata is set up to send the required credentials during the Redis AUTH call.
Redis protocol uses the AUTH command where the username must be the principal's Object ID and the password must be the token.
5
Call ConnectionMultiplexer.Connect.
A connection is successfully negotiated and opened.
This establishes the TCP connection and performs the handshake containing the AUTH command.

Key Concept

Microsoft Entra ID Authentication and Access Policies in Azure Cache for Redis
Estimated Time:2m 0s
Question 724Question

Your company requires all storage accounts containing sensitive client data to comply with a security policy that limits the maximum validity period of Shared Access Signatures (SAS) signed with account keys to 4 hours. You have configured a SAS lifetime policy on the storage account named clientdata.

A developer generates an ad-hoc Service SAS token for a blob in this storage account with a validity period of 12 hours.

What is the result when a client attempts to read the blob using this Service SAS token 1 hour after it was generated?

Show answer & explanation

Answer: The request fails with an HTTP 403 (Forbidden) error because the validity period of the SAS token exceeds the maximum limit configured in the SAS lifetime policy.

Answer

The request fails with an HTTP 403 (Forbidden) error because the validity period of the SAS token exceeds the maximum limit configured in the SAS lifetime policy.
The correct answer is that the request fails with a 403 (Forbidden) error. SAS lifetime policies limit the maximum expiration time allowed for SAS tokens signed with account keys. Because these tokens are generated offline, the policy is evaluated and enforced when a client presents the token for authorization. A token with an expiration exceeding the policy limit fails authorization completely.

Step-by-Step Solution

1
Determine the scope of the SAS lifetime policy.
The SAS lifetime policy configured on the storage account applies to any SAS token (Service or Account) signed with the account keys, limiting the maximum validity period to 4 hours.
This establishes how the policy affects the generated 12-hour Service SAS token.
2
Analyze how SAS lifetime policies are enforced.
Since SAS tokens signed with account keys are created client-side, Azure Storage has no visibility into their generation. Consequently, the policy is enforced when a client presents the token for authorization.
This explains why the token was successfully generated but will fail during consumption.
3
Compare the token validity period with the allowed policy limit.
The token validity period is 12 hours, which exceeds the 4-hour limit. Since it violates the policy, Azure Storage returns an HTTP 403 (Forbidden) error during request authorization, regardless of when the request is sent.
This confirms the final outcome when the client attempts to access the resource.

Key Concept

Azure Storage SAS lifetime policies restrict the maximum allowed expiration period of SAS tokens signed with account keys, and this policy is enforced during request authorization.
Question 725Question

You are designing autoscale rules for an Azure Virtual Machine Scale Set (VMSS) named `vmss-orders` that hosts an order-processing API. The VMSS is configured with a minimum of 22 instances, a maximum of 1010 instances, and currently runs 44 instances.

You configure the following scale-out rule:
- Metric: CPU Percentage
- Time grain: 11 minute
- Statistic: Average
- Time aggregation: Average
- Operator: Greater than
- Threshold: 90%90\%
- Operation: Increase count by 22
- Cooldown: 55 minutes

You need to create a scale-in rule that decreases the instance count by 11 when the CPU load decreases. You must ensure that the scale-in rule does not cause autoscale flapping if the total workload remains constant at the point the scale-out rule is triggered.

Which of the following is the maximum CPU percentage threshold you should configure for the scale-in rule?

Show answer & explanation

Answer: 58%58\%

Answer

The maximum safe CPU percentage threshold for the scale-in rule is 58%58\%.
The threshold of 58%58\% is correct because the new average CPU usage per instance after scaling out is 60%60\%. To prevent immediate scale-in (flapping), the scale-in threshold must be strictly less than this post-scale-out average CPU usage. Setting it to 58%58\% prevents the scale-in rule from triggering while the load remains constant.

Step-by-Step Solution

1
Calculate the total CPU workload at the scale-out trigger.
Total workload is 4×90%=360%4 \times 90\% = 360\%.
Determines the total CPU capacity consumed before scaling out occurs, assuming the workload is evenly distributed across the current 44 instances.
2
Calculate the new instance count after scale-out.
New instance count is 4+2=64 + 2 = 6 instances.
Determines the total number of instances available to handle the workload after the scale-out action completes.
3
Calculate the new average CPU usage per instance under the same load.
New average CPU is 360%/6=60%360\% / 6 = 60\%.
Determines the baseline CPU usage per instance post-scaling when workload remains constant.
4
Determine the maximum scale-in threshold to prevent flapping.
The threshold must be strictly less than 60%60\%, which is 58%58\% among the choices.
If the scale-in threshold is set to 60%60\% or higher, the new average CPU of 60%60\% immediately triggers a scale-in, creating an infinite loop of scaling up and down.

Key Concept

Autoscale flapping prevention and metric aggregation
Estimated Time:2m 30s
Question 726Question

You are developing an Azure Function App in C# that needs to retrieve a third-party API key stored as a secret in an Azure Key Vault. The Function App must authenticate to Key Vault securely using a system-assigned managed identity, adhering to the principle of least privilege.

Which five actions should you perform in sequence to configure the resources and write the code? To answer, arrange all the actions from the list of actions to the correct order.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To retrieve the secret securely, first enable the system-assigned managed identity on the Function App. Next, assign the Key Vault Secrets User RBAC role to this identity to grant read access. In the code, instantiate a DefaultAzureCredential, pass it to initialize a SecretClient, and then call GetSecretAsync to retrieve the secret value.
The correct sequence begins by provisioning the identity, granting it read-only permissions via RBAC (Key Vault Secrets User), instantiating the credential provider (DefaultAzureCredential), initializing the Key Vault client (SecretClient), and executing the secret retrieval request.

Step-by-Step Solution

1
Enable the system-assigned managed identity on the Function App.
A service principal is created in Microsoft Entra ID representing the Function App.
This establishes the identity context that will be authorized to access Key Vault.
2
Assign the Key Vault Secrets User RBAC role to the Function App's identity on the Key Vault.
The identity receives the minimum required permissions to read secrets.
Azure RBAC requires a security principal to grant permissions. You must use the Key Vault Secrets User role for least privilege secret reading.
3
Instantiate a DefaultAzureCredential object in the C# code.
A token credential pipeline is created.
The DefaultAzureCredential class automatically discovers the managed identity when deployed to Azure.
4
Instantiate a SecretClient passing the Key Vault URI and the DefaultAzureCredential.
A SecretClient instance is initialized.
The SecretClient from the Azure.Security.KeyVault.Secrets library handles all API operations against Key Vault.
5
Call the GetSecretAsync method on the SecretClient.
The secret containing the API key is retrieved.
This makes the actual network call to Key Vault to return the secret value.

Key Concept

Establishing a secure connection from an Azure Function App to Azure Key Vault using modern C# SDKs and a managed identity with role-based access control.
Question 727Question

A C# daemon application runs as a Windows Service on an on-premises server. The application must authenticate to the Microsoft Identity Platform without user interaction and query directory metadata from Microsoft Graph. You configure the application registration in Microsoft Entra ID with the Directory.Read.All Application permission, and an administrator grants tenant-wide consent. In your code, you instantiate an IConfidentialClientApplication instance. Which string array should you pass as the scopes argument to the AcquireTokenForClient method to successfully retrieve the access token?

Show answer & explanation

Answer: new string[] { "https://graph.microsoft.com/.default" }

Answer

The string array containing 'https://graph.microsoft.com/.default'
For the Client Credentials flow (AcquireTokenForClient), the Microsoft Identity Platform requires the scopes parameter to be the resource root URL followed by '/.default' (e.g., 'https://graph.microsoft.com/.default'). This triggers the token service to inspect the application registration and issue a token containing all application permissions consented to by the administrator. Statically defining and consenting to scopes is mandatory for daemon applications.

Step-by-Step Solution

1
Analyze the authentication flow specified in the scenario.
The application is a daemon application running as a Windows Service without user interaction, which dictates the use of the Client Credentials flow (Confidential Client Application flow).
Choosing the correct OAuth 2.0 flow is necessary to determine the token acquisition method and scope requirements.
2
Determine the scope requirement for the Client Credentials flow in the Microsoft Identity Platform.
In the Client Credentials flow, permissions are statically assigned during app registration and must be consented by an administrator. Consequently, MSAL.NET requires requesting the resource root followed by '/.default' to obtain all pre-consented permissions.
Requesting individual scopes like Directory.Read.All at runtime is not supported in the Client Credentials flow and results in a runtime error.
3
Construct the correct scope array argument for MSAL.NET.
The correct argument is a string array containing 'https://graph.microsoft.com/.default'.
This matches the required format for requesting token scopes on behalf of the application itself.

Key Concept

Microsoft Identity Platform Client Credentials flow requires the '/.default' scope pattern to request statically consented application permissions.
Estimated Time:1m 30s
Question 728Question

You are developing a media metadata caching solution using Azure Cache for Redis. The cache contains two types of keys:

1. Critical lookup tables that do not have a Time-to-Live (TTL) set and must remain in the cache indefinitely.
2. Dynamic media metadata keys that are set with a TTL. Under memory pressure, you want the cache to prioritize evicting the keys that are nearest to their expiration time.

You need to configure the cache to meet these requirements and ensure the instance has sufficient memory buffer to handle replication and system fragmentation.

Which of the following configuration options should you implement? (Select two.)

Select all that apply

Show answer & explanation

Answer: Configure the maxmemory-policy setting to volatile-ttl.; Configure the maxmemory-reserved setting to allocate a buffer for replication and system overhead.

Answer

Configure the maxmemory-policy setting to volatile-ttl and configure the maxmemory-reserved setting to allocate a buffer for replication and system overhead.
The configuration requires preserving keys without a TTL (the critical lookup tables) while evicting keys with a TTL (dynamic metadata) based on their remaining lifetime. Configuring the maxmemory-policy to volatile-ttl achieves this by restricting eviction candidate keys to those with an expiration set and evicting the ones closest to expiration first. Additionally, configuring the maxmemory-reserved setting is necessary to allocate a dedicated memory buffer for background processes such as replication and failover, ensuring the instance remains stable under high load.

Step-by-Step Solution

1
Analyze key eviction requirements based on expiration status.
Identify that critical lookup tables lack a TTL and must be preserved, whereas dynamic metadata keys have a TTL and can be evicted.
Choosing an eviction policy prefixed with 'volatile-' ensures that only keys with a TTL are targeted, leaving keys without a TTL intact.
2
Select the specific volatile eviction algorithm that aligns with the priority requirement.
Select volatile-ttl instead of volatile-lru.
The requirement specifies prioritizing the eviction of keys nearest to their expiration time (shortest remaining TTL), which is the exact behavior of volatile-ttl.
3
Address system stability and data replication memory requirements.
Identify the need to reserve memory using the maxmemory-reserved configuration setting.
Reserving a dedicated buffer ensures background operations like replication during failover and memory fragmentation do not cause the cache to experience out-of-memory (OOM) failures.

Key Concept

Selecting appropriate eviction policies (maxmemory-policy) to manage volatile datasets while securing persistent keys, alongside configuring maxmemory-reserved to maintain platform stability.
Question 729Question

An internal audit team requires temporary, read-only access to log files stored in a private blob container named `applogs`. You are writing the C# backend code to generate a Shared Access Signature (SAS) token for their client software.

The security policy dictates the following constraints:
- The token must be signed using Microsoft Entra ID credentials, avoiding the use of storage account keys.
- Connections must be restricted to HTTPS.
- Access must be limited specifically to the client software's outbound IP address of `203.0.113.88`.

Which of the following configurations or code steps are required to generate this SAS token? (Select TWO).

Select all that apply

Show answer & explanation

Answer: Generate a User Delegation SAS by retrieving a User Delegation Key using a BlobServiceClient authenticated with Microsoft Entra ID credentials.; Set the Protocols property of the BlobSasBuilder instance to SasProtocol.HttpsOnly.

Answer

Generating a User Delegation SAS using a User Delegation Key and configuring the BlobSasBuilder's Protocols property to HttpsOnly are both required.
Generating a User Delegation SAS signed with Microsoft Entra ID credentials meets the requirement to avoid storage account keys, and setting the Protocols property to HttpsOnly enforces secure connections.

Step-by-Step Solution

1
Select the correct SAS type based on the identity requirement.
A User Delegation SAS is chosen because it is signed using Microsoft Entra ID credentials rather than the account keys.
This aligns with security best practices and meets the specific requirement to sign using Entra ID credentials.
2
Configure connection protocol constraints on the SAS builder.
Set the Protocols property of the BlobSasBuilder to SasProtocol.HttpsOnly.
This guarantees that the generated SAS token will reject non-HTTPS requests, ensuring data in transit is encrypted.
3
Apply client IP restrictions to the SAS builder.
Assign a SasIPRange containing only the single IP address 203.0.113.88 to the IPRange property of the BlobSasBuilder.
This enforces least privilege by ensuring only the specific client IP can use the token.

Key Concept

Shared Access Signatures (SAS) security configurations including User Delegation SAS, HTTPS protocol enforcement, and client IP constraints.
Question 730Question

You are configuring an Azure API Management (APIM) instance to authenticate to a backend API. The backend API is secured with Microsoft Entra ID and requires an authentication token. You configure the APIM instance to use a system-assigned managed identity.

You need to add a policy that obtains an OAuth token for the resource `https://graph.microsoft.com` and presents it to the backend API.

Which XML policy configuration should you apply?

Show answer & explanation

Answer: <inbound>
<base />
<authentication-managed-identity resource="https://graph.microsoft.com" />
</inbound>

Answer

The correct configuration is the inbound policy block containing the authentication-managed-identity element with the resource attribute set to the Microsoft Graph audience.
The correct configuration uses the `<authentication-managed-identity>` policy placed within the `<inbound>` section. This policy instructs Azure API Management to use its system-assigned managed identity to acquire an OAuth token for the specified resource (in this case, `https://graph.microsoft.com`) and add it as an Authorization header to the request before forwarding it to the backend API.

Step-by-Step Solution

1
Determine the correct policy section for modifying the request before forwarding it to the backend.
The modification must happen in the inbound policy section.
Policies in the inbound section run before the request is sent to the backend, which is required for inserting authorization headers.
2
Select the policy designed for managed identity token retrieval.
Use the <authentication-managed-identity> policy with the resource parameter set to the backend app's audience URI.
This policy natively handles token acquisition and attaches the token to the outgoing request's Authorization header automatically.
3
Verify configuration parameters for the system-assigned managed identity.
Ensure no user-assigned identifiers (like client-id) are specified in the policy.
Omitting the client ID correctly defaults the authentication request to the system-assigned identity.

Key Concept

Acquiring an OAuth token for backend authentication using the APIM system-assigned managed identity via the authentication-managed-identity policy in the inbound section.
Question 731Question

A warehouse automation system requires a C# solution to consume high-throughput logistics events from Azure Event Hubs. You must write a consumer application that processes these events reliably, handles errors, updates partition progress in Azure Blob Storage, and shuts down gracefully when a cancellation token is triggered. How should you order the following implementation steps to achieve this?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To implement the consumer, first initialize the BlobContainerClient and EventProcessorClient. Second, assign handlers to ProcessEventAsync and ProcessErrorAsync. Third, call StartProcessingAsync to begin event processing. Fourth, call UpdateCheckpointAsync inside the event handler to store offsets. Finally, invoke StopProcessingAsync during shutdown to release leases.
The correct sequence for using the EventProcessorClient is: 1) Initialize the container and processor client objects; 2) Assign handlers to both the event and error delegates; 3) Start processing using the async start method; 4) Save consumer progress using update checkpoint within the active loop; and 5) Stop processing using the async stop method to release the storage leases.

Step-by-Step Solution

1
Initialize client objects.
BlobContainerClient and EventProcessorClient instances are created and linked.
You must create the storage client first because the processor client requires it to handle partition lease management and checkpoint storage.
2
Register event and error handlers.
Handlers for ProcessEventAsync and ProcessErrorAsync are registered on the EventProcessorClient.
The client requires both event and error handler delegates to be defined before it can run. Starting the client without registering both delegates throws an InvalidOperationException.
3
Start processor execution.
The background thread pool begins receiving events and acquiring partition ownership leases.
Calling StartProcessingAsync activates the EventProcessorClient, starting partition load balancing and routing incoming events to your handlers.
4
Persist processing checkpoint.
The current partition offset is saved to Azure Blob Storage.
Calling UpdateCheckpointAsync periodically inside the event handler ensures that if the host crashes, another processor can resume reading from the last saved offset.
5
Stop processor execution.
Event processing stops, and partition ownership leases are released.
When stopping or shutting down, calling StopProcessingAsync gracefully shuts down background processing tasks and releases blob storage leases.

Key Concept

Lifecycle and execution order of the Azure SDK EventProcessorClient for Event Hubs partition consumer operations.
Question 732Question

An enterprise API uses an Azure Cache for Redis instance to store two distinct categories of data: user session tokens that are assigned a sliding expiration Time to Live (TTL) of 30 minutes, and global application configuration settings that are stored without any TTL. Due to a sudden spike in application usage, the cache memory consumption is approaching its limit. You need to configure a policy that automatically evicts the least recently used session keys under memory pressure, while guaranteeing that all global configuration settings remain in the cache. Which maxmemory-policy configuration should you apply?

Show answer & explanation

Answer: volatile-lru

Answer

volatile-lru
The policy volatile-lru directs Redis to evict keys using the Least Recently Used (LRU) algorithm, but restricts the candidate keys only to those that have an expiration (TTL) set. Because the global configuration settings do not have a TTL, they are excluded from the eviction pool and will remain in the cache, while the session tokens (which do have a TTL) are successfully evicted based on how recently they were used.

Step-by-Step Solution

1
Analyze the requirements for the cached datasets.
Identify that the session tokens have a TTL (volatile keys) and must be evicted based on least-recently-used (LRU) algorithm, while the configuration settings have no TTL (non-volatile keys) and must not be evicted.
This establishes the key differentiation between volatile keys (with TTL) and non-volatile keys (without TTL).
2
Evaluate the behavior of the candidate maxmemory-policies.
Understand that 'allkeys-lru' scans all keys for eviction, risking configuration loss. 'volatile-lru' only targets keys with an active TTL using LRU, safeguarding configuration. 'volatile-ttl' targets keys with TTL based on shortest remaining lifespan, not LRU. 'noeviction' blocks writes entirely.
Matching the requirements to the functional definition of each Redis eviction policy is necessary to find the compliant configuration.
3
Select the policy that restricts eviction to volatile keys using the LRU algorithm.
Choose 'volatile-lru' as the configuration policy.
This policy ensures that only keys with a TTL are evaluated for eviction using the LRU criteria, protecting the TTL-less configuration data from being deleted.

Key Concept

Azure Cache for Redis maxmemory-policy eviction behaviors and volatile key scoping
Question 733Question

You are developing a secure backend service in C# using the Azure.Storage.Blobs SDK (v12) to grant temporary access for clients to upload diagnostic files to a private Azure Blob Storage container.

Your company enforces the following security requirements:
- Storage account access keys must not be used or loaded by the application; access must be authenticated via Microsoft Entra ID.
- Clients must only be permitted to write new files; they must not be allowed to read, list, or delete existing files.
- All client connections must be encrypted using HTTPS.
- The SAS token must be valid immediately upon generation, accounting for potential clock synchronization differences between the server and clients.

You write the following code segment:

csharp
// blobServiceClient is an authenticated BlobServiceClient using DefaultAzureCredential
var userDelegationKey = await blobServiceClient.GetUserDelegationKeyAsync(
DateTimeOffset.UtcNow.AddMinutes(-15),
DateTimeOffset.UtcNow.AddHours(2)
);

var sasBuilder = new BlobSasBuilder
{
BlobContainerName = "diagnostics",
BlobName = "log.txt",
Resource = "b"
};

Which code segment should you use to complete the SAS configuration and token generation?

Show answer & explanation

Answer: sasBuilder.StartsOn = DateTimeOffset.UtcNow.AddMinutes(-15);
sasBuilder.ExpiresOn = DateTimeOffset.UtcNow.AddMinutes(45);
sasBuilder.Protocol = SasProtocol.Https;
sasBuilder.SetPermissions(BlobSasPermissions.Write);

string sasToken = sasBuilder.ToSasQueryParameters(userDelegationKey, blobServiceClient.AccountName).ToString();

Answer

The correct code segment configures the SAS token for HTTPS only, grants Write permission, adjusts the start time backwards to account for clock skew, and uses the User Delegation Key signed with Microsoft Entra ID to generate the query parameters.
The correct segment sets the protocol strictly to HTTPS, restricts access to write-only permissions, applies a negative offset to the start time to mitigate clock skew, and signs the token with the User Delegation Key to satisfy the Microsoft Entra ID requirement.

Step-by-Step Solution

1
Ensure keyless authentication using Microsoft Entra ID.
Obtained a UserDelegationKey using GetUserDelegationKeyAsync, and signed the SAS parameters using ToSasQueryParameters with the delegation key and the account name instead of StorageSharedKeyCredential.
Security policy forbids storing or utilizing storage account access keys in application code.
2
Configure the SAS permissions and protocols.
Set permissions strictly to BlobSasPermissions.Write and protocol to SasProtocol.Https.
Least-privilege policy mandates write-only access, and data in transit must be encrypted using HTTPS.
3
Adjust token lifetime constraints for clock skew.
Set StartsOn to 15 minutes in the past.
Prevents immediate authorization failures if the client clock is slightly ahead of the Azure Storage server clock.

Key Concept

Generating a User Delegation SAS token using Azure.Storage.Blobs .NET SDK with security configurations.
Estimated Time:1m 30s
Question 734Question

You are configuring an inbound policy for an Azure API Management (APIM) instance. You need to route incoming API requests to a specific regional backend API based on the value of a custom header named `X-Region`. If the header value is `EU`, the request must be routed to `https://eu-backend.contoso.com/api`. Otherwise, the request must use the default backend. What are the correct API Management policy element names required to complete the XML configuration below?

Fill in the blanks below

xml
<inbound>
<base />
<choose>
<
condition="@(context.Request.Headers.GetValueOrDefault("X-Region") == "EU")">
<
base-url="https://eu-backend.contoso.com/api" />
</
>
</choose>
</inbound>
Show answer & explanation

Answer

The correct policy elements are 'when' to evaluate the conditional routing expression and 'set-backend-service' to redirect the backend API base URL.
The correct elements are 'when' and 'set-backend-service'. The `<when>` element defines a conditional branch inside the `<choose>` parent element. The `<set-backend-service>` element alters the destination endpoint for the incoming API request during the inbound processing pipeline.

Step-by-Step Solution

1
Identify the conditional block element within the `<choose>` policy structure.
The `<choose>` element executes policies in the first nested `<when>` element whose condition evaluates to true.
To evaluate whether the custom header `X-Region` is equal to `EU`, a conditional `<when>` block must be declared.
2
Identify the policy element required to alter the destination URL for the backend API.
The `<set-backend-service>` policy dynamically changes the destination backend base URL for the request.
To route requests to the regional URL when the condition is met, the `<set-backend-service>` policy with the `base-url` attribute must be placed inside the conditional block.

Key Concept

Configuring conditional routing policies in Azure API Management using the choose-when policy structure and the set-backend-service policy element.
Estimated Time:1m 30s
Question 735Question

You are developing a C# desktop application that will run on local client workstations. The application must authenticate users using the Microsoft Identity Platform and call a secured downstream Web API. You need to write the MSAL.NET code to initialize the application and acquire the access token. Which two code segments should you use? (Select two.)

Select all that apply

Show answer & explanation

Answer: var app = PublicClientApplicationBuilder.Create(clientId).WithRedirectUri("http://localhost").Build();; var result = await app.AcquireTokenInteractive(scopes).ExecuteAsync();

Answer

To initialize the application and acquire the token, you must build a public client application using PublicClientApplicationBuilder and acquire the token interactively using AcquireTokenInteractive.
For desktop applications running on local user machines, the application is classified as a public client because it cannot securely store secrets. Therefore, it must be initialized using PublicClientApplicationBuilder. To authenticate the user and obtain an access token, the application should initiate an interactive flow using AcquireTokenInteractive, which prompts the user for credentials.

Step-by-Step Solution

1
Determine the application type and build the client application.
Initialize a public client application using PublicClientApplicationBuilder because desktop apps running on local machines cannot securely protect secrets.
Public client applications do not use client secrets or certificates for authentication since they run on untrusted client devices.
2
Select the appropriate MSAL.NET token acquisition method.
Call AcquireTokenInteractive to prompt the user for credentials and acquire the token.
Interactive authentication is the standard method for acquiring user-delegated tokens in public client desktop applications.

Key Concept

Microsoft Identity Platform authentication for public client applications using MSAL.NET
Question 736Question

You are developing a C# background service that processes smart meter telemetry data from an Azure Service Bus queue named 'meter-telemetry'. If the processing of a telemetry message fails due to an external API outage, the message must not be lost and should remain in the queue for another attempt. You need to initialize the receiver and handle the message processing in a way that guarantees at-least-once delivery. Which code segment should you use?

Show answer & explanation

Answer: var options = new ServiceBusReceiverOptions { ReceiveMode = ServiceBusReceiveMode.PeekLock };
var receiver = client.CreateReceiver("meter-telemetry", options);
var message = await receiver.ReceiveMessageAsync();
// Process message...
await receiver.CompleteMessageAsync(message);

Answer

Initialize the receiver using ServiceBusReceiveMode.PeekLock and explicitly call CompleteMessageAsync after processing is complete.
The correct approach uses PeekLock mode. This ensures that the message is only deleted from the queue when CompleteMessageAsync is explicitly called after successful processing. If the background service encounters a transient failure or crashes before completion, the lock expires and the message is released back to the queue for retry, ensuring at-least-once delivery.

Step-by-Step Solution

1
Set the ServiceBusReceiverOptions ReceiveMode property.
Use ServiceBusReceiveMode.PeekLock to ensure that messages are locked rather than instantly deleted upon retrieval.
This guarantees that if the receiver fails mid-process, the message lock will expire and the message will become available again on the queue.
2
Invoke receiver.ReceiveMessageAsync() and perform the required business logic.
Receive the message payload and process the meter telemetry data.
During this phase, the message remains hidden from other consumers for the duration of the lock.
3
Invoke receiver.CompleteMessageAsync(message) upon successful execution.
The message is permanently deleted from the queue.
Explicit completion is required in PeekLock mode to confirm successful processing and remove the message.

Key Concept

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

An Azure App Configuration store needs to retrieve a database password stored in an Azure Key Vault named kv-app-prod at runtime. The Key Vault uses the Azure Role-Based Access Control (RBAC) permission model. The App Configuration store has a system-assigned managed identity enabled. Which of the following actions should you perform to configure the App Configuration store to reference the Key Vault secret? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Assign the 'Key Vault Secrets User' role to the system-assigned managed identity of the App Configuration store at the Key Vault scope.; Create a Key Vault reference in Azure App Configuration by providing the secret URI 'https://kv-app-prod.vault.azure.net/secrets/DbPassword'.

Answer

Assign the 'Key Vault Secrets User' role to the system-assigned managed identity of the App Configuration store at the Key Vault scope, and create a Key Vault reference in Azure App Configuration by providing the secret URI.
To retrieve secrets from a Key Vault that uses Azure RBAC, the App Configuration store's managed identity must be assigned the 'Key Vault Secrets User' role. The App Configuration store references the secret using its direct URI.

Step-by-Step Solution

1
Assign the 'Key Vault Secrets User' role to the App Configuration store's managed identity at the Key Vault scope.
The App Configuration store's identity is authorized to retrieve the secret.
The Key Vault uses Azure RBAC, making role assignment the only valid way to authorize the identity.
2
Create a Key Vault reference in App Configuration by specifying the secret URI.
App Configuration successfully resolves the secret at runtime using the authorized identity.
Key Vault references in App Configuration require the direct secret URI, not the App Service reference syntax.

Key Concept

Azure Key Vault Integration with Azure App Configuration under Azure RBAC
Question 738Question

A web application for a news outlet uses Azure Cache for Redis to store articles. The articles fall into two main categories:

1. Breaking news stories, which receive a high volume of read requests shortly after publication, but traffic drops to zero within 2424 hours.
2. Evergreen features, which receive a steady, low-volume stream of read requests consistently over several months.

All cached articles are configured with a Time-to-Live (TTL) value. Under high load, the cache memory limit is reached. You need to configure an eviction policy that retains the evergreen features (consistently accessed over time) and prioritizes evicting breaking news stories whose traffic has subsided, even if those stories were accessed more recently than some evergreen features.

Which eviction policy should you choose?

Show answer & explanation

Answer: volatile-lfu

Answer

The volatile-lfu eviction policy.
The volatile-lfu policy evicts keys with an expire set (TTL) that have the lowest access frequency counter. This ensures that evergreen articles, which accumulate a high frequency of access over time, are preserved, while breaking news articles that are no longer being frequently accessed are evicted first, even if they were accessed more recently than some evergreen articles.

Step-by-Step Solution

1
Identify key characteristics of the cached items.
All items have a Time-to-Live (TTL) set. Breaking news has high initial but short-lived access. Evergreen content has low but continuous access over time.
Knowing whether keys have a TTL determines whether to use a volatile or allkeys policy. Analyzing access patterns determines whether Least Recently Used (LRU) or Least Frequently Used (LFU) is appropriate.
2
Compare LRU and LFU algorithms.
LRU evicts keys that haven't been accessed for the longest time. LFU evicts keys with the lowest total access frequency counter.
Since breaking news articles may have been accessed recently but have lower overall frequency once they go cold, LRU would mistakenly keep them and evict the consistently accessed evergreen articles.
3
Select the correct policy targeting keys with TTL.
volatile-lfu is selected.
Since all keys have a TTL configured and we want to preserve high-frequency keys (evergreen content), volatile-lfu is the correct choice.

Key Concept

Least Frequently Used (LFU) eviction policies in Azure Cache for Redis configuration
Question 739Question

You are developing a secure C# application using the `Azure.Storage.Blobs` SDK (v12) to generate a Shared Access Signature (SAS) token. The token will grant temporary access to an external partner to download a specific PDF report from a private Azure Blob Storage container.

The solution must comply with the following security constraints:
- Grant read-only access to the specific blob.
- Restrict communication to HTTPS requests only.
- Limit access to the partner's public IP address, which is `198.51.100.45`.
- Set the start time to 15 minutes before the current time to account for clock skew.
- Set the expiry time to 2 hours from the current time.

Which two of the following code segments should you use to configure the `BlobSasBuilder` instance named `sasBuilder`? (Choose two.)

Select all that apply

Show answer & explanation

Answer: sasBuilder.Protocol = SasProtocol.Https;; sasBuilder.IPRange = SasIPRange.Parse("198.51.100.45");

Answer

The correct configurations are setting the Protocol property to SasProtocol.Https and setting the IPRange property to SasIPRange.Parse("198.51.100.45").
The correct options are configuring the Protocol property of the BlobSasBuilder to Https to enforce secure-only transport, and parsing the single IP address using SasIPRange.Parse to restrict access to the partner's IP.

Step-by-Step Solution

1
Analyze the HTTPS requirement.
The SAS token must restrict traffic to HTTPS. We use the SasProtocol.Https enumeration value.
Setting the Protocol property to Https ensures the storage service rejects any HTTP requests using this SAS.
2
Analyze the IP address restriction requirement.
The SAS token must restrict traffic to the specific IP address 198.51.100.45. We use SasIPRange.Parse("198.51.100.45") to configure the range.
Setting the IPRange property restricts requests to the specified IP address, rejecting requests from other sources.
3
Verify other requirements.
The start time, expiry, and permissions are correctly configured in the rest of the builder code, and the incorrect options are avoided.
Setting Write permissions violates read-only constraints, and using HttpsAndHttp violates the HTTPS-only restriction.

Key Concept

Configuring SAS tokens with least privilege, specific protocols, and IP restrictions using the Azure Storage SDK.
Question 740Question

A corporate financial system uses an Azure Service Bus queue named `expense-claims` to process employee reimbursement requests. You are writing the message consumption logic in C# using the `Azure.Messaging.ServiceBus` SDK. To ensure reliability, if the consumer application fails mid-operation, the message must remain in the queue and be re-delivered after the lock duration expires. Once the expense claim is successfully recorded, the message must be deleted.

Which two actions should you take to implement this workflow? (Select two)

Select all that apply

Show answer & explanation

Answer: Set the receive mode in the ServiceBusReceiverOptions to ServiceBusReceiveMode.PeekLock.; Invoke the CompleteMessageAsync method on the receiver object when processing completes successfully.

Answer

To ensure reliable message processing, you must configure the ServiceBusReceiverOptions to use ServiceBusReceiveMode.PeekLock and invoke the CompleteMessageAsync method on the receiver object when processing completes successfully.
To ensure message durability and avoid data loss on application crashes, the receiver must be set to use PeekLock. This mode locks the message for the consumer while keeping it in the queue. Upon successful processing, the application must explicitly call CompleteMessageAsync to delete the message.

Step-by-Step Solution

1
Configure the receiver to lock messages on retrieval.
Initialize ServiceBusReceiverOptions with ServiceBusReceiveMode.PeekLock.
This prevents messages from being deleted immediately, keeping them in the queue if the processing instance crashes.
2
Process the message and write to the database.
The expense claim data is successfully stored.
This is the business logic execution phase.
3
Explicitly delete the message from the queue.
Invoke CompleteMessageAsync on the ServiceBusReceiver.
This signals to Azure Service Bus that processing is complete and the message can be removed.

Key Concept

Reliable message processing using PeekLock and CompleteMessageAsync
PreviousPage 37 / 49Next
All practice questions — Microsoft Azure Developer (AZ-204) | Examkin