Examkin

All practice questions

972 questions

All types972Multiple choice497Multiple select269Matching9Ordering171Fill in the blank26
Question 881Question →

You are developing a .NET background worker service that processes media rendering tasks from an Azure Service Bus queue. The rendering tasks are computationally intensive and take between 2 to 4 minutes to complete. The queue's default lock duration is set to 30 seconds. You must ensure that tasks are not processed by multiple workers concurrently, and if a worker crashes during processing, the task must be returned to the queue without message loss. Which configuration strategy should you implement?

Show answer & explanation

Answer: Initialize the ServiceBusProcessor in PeekLock mode, and set the MaxAutoLockRenewalDuration property in ServiceBusProcessorOptions to 5 minutes.

Answer

Initialize the ServiceBusProcessor in PeekLock mode, and set the MaxAutoLockRenewalDuration property in ServiceBusProcessorOptions to 5 minutes.
The correct answer demonstrates how to handle long-running message processing safely in Azure Service Bus. By retaining PeekLock mode, messages are protected from loss if the worker fails. Configuring the MaxAutoLockRenewalDuration property in the ServiceBusProcessorOptions allows the background SDK client to renew the lock periodically up to the specified limit (5 minutes), preventing other workers from picking up the message while it is still being processed.

Step-by-Step Solution

1
Select the correct message consumption mode.
PeekLock mode is chosen because it ensures transactional safety by locking the message during processing rather than deleting it immediately.
Preventing message loss upon application crash requires PeekLock mode so that uncompleted messages return to the queue.
2
Address the 30-second lock limit for a 2-4 minute task.
Configure automatic lock renewal via ServiceBusProcessorOptions.
If the lock expires, other instances of the worker can consume the same message, causing duplicate processing. Enabling MaxAutoLockRenewalDuration lets the client SDK handle lock extensions automatically.
3
Define the renewal duration boundary.
Set MaxAutoLockRenewalDuration to 5 minutes (which is greater than the maximum 4-minute processing time).
The renewal duration must cover the maximum expected duration of the long-running process.

Key Concept

Azure Service Bus message locking mechanics, receiver modes, and automatic lock renewal properties inside the .NET SDK.
Estimated Time:2m 0s
Question 882Question →

You are developing a C# backend application that retrieves product inventory data. You must implement the Cache-Aside data pattern to cache inventory status using an Azure Cache for Redis instance and the StackExchange.Redis SDK. The cache connection must be initialized lazily and thread-safely.

Order the steps to implement the sequence of operations for retrieving product inventory data on a request.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts with initializing the ConnectionMultiplexer using a Lazy thread-safe singleton, querying the cache via StringGetAsync, returning the data immediately if a cache hit occurs, retrieving data from the backend database on a cache miss, writing the data back to the cache asynchronously using StringSetAsync with an expiration time, and finally returning the database-retrieved data to the caller.
The correct order follows the standard implementation of the Cache-Aside data pattern. First, the connection must be established thread-safely (Lazy ConnectionMultiplexer). Next, the application attempts to read from the cache. If the key exists, the cached value is deserialized and returned immediately. If a cache miss occurs, the application queries the persistent SQL database, writes the result to the cache with an expiration time, and returns the data.

Step-by-Step Solution

1
Initialize the ConnectionMultiplexer thread-safely.
A single connection instance is created lazily.
StackExchange.Redis uses a single ConnectionMultiplexer designed to be shared and reused. Initializing it thread-safely avoids socket exhaustion and race conditions.
2
Query the Redis cache.
The Redis database is queried for the key.
The Cache-Aside pattern prioritizes checking the fast memory cache first to minimize database load.
3
Evaluate the cache response.
Data is returned if it is a cache hit.
If the key exists, the cached data is deserialized and returned directly, fulfilling the Cache-Aside pattern.
4
Fetch from the SQL database on cache miss.
Data is retrieved from the database.
When the cache is empty for the requested key, the application must query the authoritative system of record.
5
Write the fetched data back to the cache.
The cache is updated with a TTL.
To ensure subsequent reads are served from the cache, the data is written back to Redis with a TTL to prevent stale data.
6
Return the data to the client.
The fresh database data is returned.
The request is completed with the authoritative database data.

Key Concept

The Cache-Aside pattern caches data on-demand from a data store, improving performance and database scalability while maintaining consistency via TTL.
Question 883Question →

You are deploying a V4 Azure Function App on a Consumption plan. The Function App contains an Azure Service Bus queue-triggered function that integrates with a legacy on-premises system. During periods of high traffic, the Function App scales out and opens too many concurrent connections to the legacy system, causing it to crash. You need to limit the scale-out of the Function App to a maximum of 10 instances while maintaining the Consumption plan to minimize costs. Which configuration should you apply?

Show answer & explanation

Answer: Add an application setting named WEBSITE_MAX_DYNAMIC_SCALE_OUT with a value of 10.

Answer

Add an application setting named WEBSITE_MAX_DYNAMIC_SCALE_OUT with a value of 10.
Adding the WEBSITE_MAX_DYNAMIC_SCALE_OUT application setting with a value of 10 enforces a maximum scale-out limit of 10 instances on the serverless Consumption plan. This prevents the app from spawning too many concurrent instances and overloading the legacy on-premises system while preserving serverless cost benefits.

Step-by-Step Solution

1
Analyze the scaling requirement and constraints.
The solution requires capping the scale-out instances to 10 while keeping the Consumption plan to minimize costs.
This rules out plan migration options.
2
Differentiate between instance concurrency limits and instance scale-out limits.
Concurrency settings in host.json restrict message processing per instance, but do not prevent the orchestrator from spinning up additional instances.
To limit the total number of VM instances, an app-level scale limit must be configured.
3
Identify the correct application setting for Consumption plan instance limits.
The WEBSITE_MAX_DYNAMIC_SCALE_OUT setting directly controls the scale-out limit on Consumption and Elastic Premium plans.
Applying this setting meets all constraints.

Key Concept

Configuring scale-out limits for Azure Functions hosted on a Consumption plan
Estimated Time:1m 30s
Question 884Question →

A cloud-native microservices application deployed on Azure Kubernetes Service (AKS) logs telemetry to a shared Azure Application Insights workspace. You need to write a Kusto Query Language (KQL) query to analyze dependency calls that failed in the last 24 hours. The query must join the dependency logs with custom event telemetry to retrieve the name of the failing dependency and the custom event name, using the `operation_Id` column.

To minimize resource consumption and query execution time, which KQL query should you use?

Show answer & explanation

Answer: dependencies
| where timestamp > ago(24h) and success == false
| join kind=inner (
customEvents
| where timestamp > ago(24h)
) on operation_Id
| project dependencyName = name, eventName = name1

Answer

The KQL query that filters both the dependencies and customEvents tables by time range before performing the inner join on operation_Id is the correct and optimized query.
The correct query applies the time range filter on both the left table (dependencies) and the right table (customEvents) before performing the join. In Kusto Query Language (KQL), filtering data as early as possible on both sides of a join is critical to minimize the dataset sizes being processed by the join operator, ensuring optimal query performance and preventing execution timeouts.

Step-by-Step Solution

1
Filter the left table (dependencies) by the time range and status.
Limits the left-side dataset to only failed dependency calls from the last 24 hours.
Filtering early reduces the volume of data sent to subsequent query operators, improving performance.
2
Filter the right table (customEvents) by the time range inside a subquery projection before the join.
Limits the right-side dataset to only custom events from the last 24 hours.
Omitting the time filter on either side of a join forces the query engine to scan the entire history of the unfiltered table to match operation IDs, causing high resource usage.
3
Perform the inner join on the operation_Id column and project the desired fields.
Successfully joins the two filtered datasets and renames duplicate column names (e.g., name to name1 for the right table).
Allows mapping specific custom event telemetry to the corresponding failed dependency call while resolving column naming conflicts.

Key Concept

KQL Query Optimization using Time-Range Filters on Joined Tables
Question 885Question →

A company hosts a high-traffic e-commerce web application named CartService on Azure App Service. The application runs on a Standard (S1) App Service plan. During flash sales, the application experiences sudden traffic surges, causing incoming requests to queue up before they can be processed by the web workers. You need to configure an Azure Monitor autoscale rule to scale out the App Service plan instances to handle the queued requests. Which metric should you select to trigger the scale-out rule?

Show answer & explanation

Answer: HTTP Queue Length

Answer

HTTP Queue Length
The HTTP Queue Length metric represents the number of requests that have entered the queue but have not yet been assigned to a worker thread. When a web application experiences sudden traffic surges, this queue grows, indicating that the existing instances are fully loaded. Autoscaling based on this metric ensures that additional instances are added to handle the excess request volume.

Step-by-Step Solution

1
Identify the bottleneck and the symptom described in the scenario.
The scenario states that requests are queuing up before being processed by the web workers.
This indicates that the worker threads are fully occupied and cannot process incoming requests fast enough.
2
Evaluate the available built-in metrics for App Service plan autoscaling.
Azure Monitor offers built-in metrics such as CPU Percentage, Memory Percentage, and HTTP Queue Length at the App Service level.
We need to select the metric that directly reflects the queuing symptom.
3
Select the metric that triggers scaling when requests queue up.
HTTP Queue Length directly measures the size of the request queue.
Scaling out when HTTP Queue Length is high ensures that additional web server instances are provisioned to clear the request queue and restore application responsiveness.

Key Concept

Autoscale metrics for Azure App Service plans
Estimated Time:1m 30s
Question 886Question →

You manage a Premium tier Azure Cache for Redis instance that supports a high-throughput session state and lookup service. The cache stores two classes of data: user session tokens configured with an explicit Time-To-Live (TTL) of 20 minutes, and static configuration metadata configured without a TTL. During peak traffic events, the cache experiences high memory pressure and latency spikes due to replication synchronization overhead between the primary and replica nodes. You must configure the cache so that under memory pressure, only the user session tokens that have not been accessed recently are evicted, the static configuration metadata is never evicted automatically, and sufficient memory is reserved to accommodate replication and failover overhead. Which combination of configuration settings should you apply?

Show answer & explanation

Answer: Set the maxmemory-policy to volatile-lru and configure maxmemory-reserved to allocate memory for replication overhead.

Answer

Set the maxmemory-policy to volatile-lru and configure maxmemory-reserved to allocate memory for replication overhead.
Configuring volatile-lru ensures that the eviction algorithm only targets keys with an expiration set (which correspond to the session tokens), preserving the static metadata keys that do not have a TTL. Additionally, configuring maxmemory-reserved reserves a buffer of memory for replication, serialization, and failover operations, preventing out-of-memory errors under heavy load during synchronization.

Step-by-Step Solution

1
Analyze the eviction requirements for the different classes of data.
Identify that session tokens have a TTL and need least-recently-used eviction, whereas static configuration metadata has no TTL and must not be evicted.
This dictates that the eviction policy must only target keys with an expiration set, pointing to a volatile policy (specifically volatile-lru rather than allkeys-lru or noeviction).
2
Evaluate the difference between LRU and TTL eviction policies for keys with an expiration.
Determine that volatile-lru targets least recently used keys, whereas volatile-ttl targets keys with the shortest remaining lifetime.
The requirement specifies that tokens not accessed recently must be evicted, which requires an LRU algorithm.
3
Identify the appropriate Azure Cache for Redis configuration setting for replication overhead.
Determine that maxmemory-reserved reserves memory for non-cache operations like replication and failover, whereas maxfragmentationmemory-reserved is for memory fragmentation.
Reserving memory for replication synchronization prevents server-side OOM errors under heavy write loads.
4
Combine the selected eviction policy and reserved memory setting.
Select the configuration with volatile-lru and maxmemory-reserved.
This is the only combination that preserves the static metadata, evicts the correct session tokens, and protects the cache from replication-induced OOM failures.

Key Concept

Azure Cache for Redis Eviction Policies and Memory Management Settings
Question 887Question →

You are deploying a containerized service to Azure Container Instances (ACI) that must pull its image from a private Azure Container Registry (ACR). Once running, the application inside the container must retrieve an API key from Azure Key Vault. You want to use a single managed identity to authenticate both the image pull from ACR and the secret retrieval from Key Vault. Which configuration should you use?

Show answer & explanation

Answer: Configure a user-assigned managed identity, assign it the AcrPull role on the ACR, grant it Get secrets permission on the Key Vault, and configure the container group to use this identity for the image pull.

Answer

Configure a user-assigned managed identity, assign it the AcrPull role on the ACR, grant it Get secrets permission on the Key Vault, and configure the container group to use this identity for the image pull.
A user-assigned managed identity is created independently of the container group, which allows it to be referenced in the container group's deployment configuration to authenticate the container image pull from a private Azure Container Registry. Because it is assigned to the container group, the same identity is available to the container at runtime to authenticate to Azure Key Vault and retrieve secrets, fulfilling the requirement of using a single identity.

Step-by-Step Solution

1
Create a user-assigned managed identity and assign it the AcrPull role on the target Azure Container Registry.
The identity gains the necessary permissions to read and pull container images from the private registry.
Because ACI must pull the container image before the container group resource is fully provisioned, a pre-existing user-assigned managed identity is required; a system-assigned identity cannot be used.
2
Grant the user-assigned managed identity Get permissions (or the Key Vault Secrets User role) on the target Azure Key Vault.
The identity is authorized to retrieve the secrets needed by the application at runtime.
By default, managed identities do not have permission to read Key Vault secrets and must be explicitly authorized.
3
Reference the user-assigned managed identity in the ACI container group definition and configure the container group to use this identity for image registry credentials.
The ACI service successfully authenticates with ACR using the identity's credentials, pulls the image, and provisions the container group with the identity assigned.
This links the managed identity to both the image pull phase and the runtime execution phase of the container.

Key Concept

Azure Container Instances supports authenticating to a private Azure Container Registry and accessing Azure Key Vault using a user-assigned managed identity.
Question 888Question →

A gaming platform uses Azure Cosmos DB API for NoSQL to store player profiles and game state. The database account has a single write region in East US and a read replica in West US. Players connect to the game via stateless Web APIs running in both regions. The platform must ensure that when a player updates their profile, they immediately see their own updates on subsequent page refreshes, even if their requests are routed to different instances of the Web API. The client application retrieves and passes the SDK session token between requests. Other players can tolerate a delay in seeing these updates. Which consistency level should you configure for the Azure Cosmos DB account to meet these requirements with the lowest Request Unit (RU) cost?

Show answer & explanation

Answer: Session

Answer

Session consistency is the optimal choice because it guarantees read-your-own-writes when the session token is passed between stateless instances, while maintaining a read cost of 1 RU1\text{ RU} and minimal latency.
Session consistency provides the required read-your-own-writes guarantee within a session. Because the client application retrieves and passes the SDK session token between stateless Web API instances, the session context is preserved. This level costs 1 RU1\text{ RU} for reads, which satisfies the requirement for the lowest RU cost.

Step-by-Step Solution

1
Analyze the requirements for read consistency and cost.
The application requires 'read-your-own-writes' consistency for individual players (updating a profile and immediately seeing it on refresh) with the lowest possible Request Unit (RU) cost.
This narrows the choices down to levels that support read-your-own-writes (Session, Bounded Staleness, Strong) and compares their RU costs (Session is 1 RU1\text{ RU}, others are 2 RUs2\text{ RUs}).
2
Evaluate the role of the session token and stateless Web API instances.
Since the client application explicitly retrieves and passes the Cosmos DB SDK session token between stateless Web API requests, Session consistency can span these stateless instances and guarantee read-your-own-writes.
Session consistency is scoped to the client session. Passing the token allows different client instances to share the same session context, avoiding the need to upgrade to Strong consistency.
3
Select the level that satisfies the consistency requirement with the lowest RU cost.
Session consistency satisfies the consistency requirement and costs 1 RU1\text{ RU} per read, whereas Strong and Bounded Staleness cost 2 RUs2\text{ RUs}.
Selecting Session consistency minimizes request costs and latency while fully meeting the functional requirements.

Key Concept

Azure Cosmos DB consistency levels and session token management
Estimated Time:1m 30s
Question 889Question →

You are developing a multiplayer gaming platform that stores player session data in Azure Cosmos DB using the SQL API and the .NET SDK v3. The Cosmos DB account is configured with Session consistency. The platform consists of two independent microservices running on separate server instances, each initializing its own CosmosClient instance.

Microservice A writes a new session document to the database. Immediately after, Microservice B must read that same session document to validate a lobby entry request. You must ensure that Microservice B reads the latest session state (read-your-writes guarantee) while maintaining the lowest possible read latency and avoiding hot partition issues under high write volume.

Which code segment should you implement to satisfy these requirements?

Show answer & explanation

Answer: Initialize containers with partition key path "/userId".

// Microservice A:
PlayerSession session = new PlayerSession { Id = "session_987", UserId = "user_123", IsActive = true };
ItemResponse<PlayerSession> writeResponse = await containerA.CreateItemAsync<PlayerSession>(
session,
new PartitionKey(session.UserId)
);
string token = writeResponse.Headers.Session;

// Microservice B:
ItemResponse<PlayerSession> readResponse = await containerB.ReadItemAsync<PlayerSession>(
session.Id,
new PartitionKey(session.UserId),
new ItemRequestOptions { SessionToken = token }
);

Answer

The correct implementation configures the container with a high-cardinality partition key path of "/userId", retrieves the Session Token from the write response headers via Headers.Session in the writing client, and explicitly applies it using ItemRequestOptions.SessionToken on the reading client.
The correct answer provides a high-cardinality partition key path ('/userId') which guarantees a uniform distribution of throughput and storage across partitions. To achieve read-your-writes consistency across two distinct CosmosClient instances, the application must capture the session token from the write operation's response headers (Headers.Session) and provide it to the subsequent read operation using ItemRequestOptions.

Step-by-Step Solution

1
Select a high-cardinality partition key.
The path "/userId" is chosen instead of low-cardinality attributes like "/isActive" to distribute write load evenly.
Choosing a poor partition key with low cardinality results in hot logical partitions and eventual rate-limiting.
2
Retrieve the session token after the write operation.
Access the session token string via writeResponse.Headers.Session.
Cosmos DB Session consistency is scoped to the client instance. Since the microservices run on separate client instances, the token must be shared externally.
3
Inject the session token into the read request configuration.
Populate the SessionToken property in the ItemRequestOptions object when calling ReadItemAsync.
This instructs the second client to read from a replica that has caught up at least to the version indicated by the session token.

Key Concept

Explicitly passing Session Tokens across independent CosmosClient instances to guarantee read-your-writes consistency while maintaining high-cardinality partition structures.
Estimated Time:2m 30s
Question 890Question →

You are developing a background worker application that runs in Azure Container Apps. The application must scale dynamically based on the message count of an Azure Service Bus queue. You plan to use a user-assigned managed identity to authenticate the container app's scale rules with the Service Bus namespace.

Which sequence of steps should you perform to configure the scaling and security?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

Create the user-assigned managed identity, assign the Service Bus Data Receiver role to it, associate the identity with the Container App, and then configure the Service Bus scale rule referencing the identity.
The correct sequence begins with creating the user-assigned managed identity. Next, you must grant it the permissions needed to read from the queue by assigning the Azure Service Bus Data Receiver role. You then associate the identity with the Container App resource. Finally, you configure the azure-servicebus scale rule, referencing the associated identity.

Step-by-Step Solution

1
Create the user-assigned managed identity.
The identity is provisioned in Azure, generating a unique principal ID and client ID.
You must have a physical identity resource before you can assign roles or link it to other Azure resources.
2
Assign the Azure Service Bus Data Receiver role to the managed identity at the queue scope.
The identity is granted permissions to read from the target Service Bus queue.
The Container App's scaling mechanism (KEDA) runs on the host environment and uses this identity to authenticate and read the queue depth.
3
Associate the user-assigned managed identity with the Container App.
The Container App resource definition is updated to include the identity in its identity block.
The Container App must explicitly own or be associated with the user-assigned identity before it can reference it in configuration settings.
4
Add the azure-servicebus scale rule referencing the associated identity.
The scaling engine uses the associated identity to read queue depth and scale the container instances.
The scale rule configures the actual KEDA scaler, which depends on the identity association and role permissions setup in the preceding steps.

Key Concept

Azure Container Apps scale rules (KEDA) require a managed identity associated with the Container App and granted appropriate permissions on the target resource (like Service Bus) to monitor metrics for autoscaling.
Estimated Time:1m 30s
Question 891Question →

You manage a web application named EduLearn that is currently hosted on a Free (F1F1) App Service plan. During peak hours, the application experiences high CPU utilization and becomes slow. You want to implement an automated scaling solution to handle the load and ensure the application remains responsive, while also preventing autoscale flapping. You plan to configure these settings via the Azure CLI.

How should you order the steps to configure the autoscaling solution?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts with upgrading the App Service plan to Standard (S1S1), creating the autoscale setting container, adding the scale-out rule, and finally adding the scale-in rule.
The correct order requires first scaling up the App Service plan from the Free (F1F1) tier to the Standard (S1S1) tier. Autoscaling is not supported on Free or Shared plans. Once upgraded, you must create the autoscale setting container using `az monitor autoscale create`. Only after the autoscale setting is created can you add specific rules to it. The scale-out rule (CPU > 80%80\%) should be added first to define the upper performance boundary, followed by the scale-in rule with a threshold of 30%30\%. Setting the scale-in threshold to 30%30\% (which is significantly lower than the scale-out threshold of 80%80\%) prevents autoscale flapping.

Step-by-Step Solution

1
Upgrade the hosting plan of the web app to Standard (S1S1).
The App Service plan is scaled up to a tier that supports custom autoscale settings.
Free (F1F1) and Basic (B1B1) plans do not support automatic scale-out; a Standard (S1S1) or Premium tier is required.
2
Create the custom autoscale setting container.
An autoscale profile with minimum, maximum, and default capacity is defined for the App Service plan.
Autoscale rules cannot be created without an existing autoscale setting to attach them to.
3
Define a scale-out rule with a CPU threshold of 80%80\%.
The application scales out by adding instances when under high CPU load.
Establishing the scale-out rule ensures that capacity increases when CPU utilization exceeds the threshold.
4
Define a scale-in rule with a CPU threshold of 30%30\%.
The application scales in by removing instances when CPU load decreases, without triggering flapping.
Setting the scale-in threshold sufficiently lower than the scale-out threshold prevents the application from repeatedly scaling in and out (flapping).

Key Concept

To configure autoscale on Azure App Service, the App Service plan must be scaled up to a supported tier (Standard or higher) before creating the autoscale setting and defining the scale-out and scale-in rules. To prevent autoscale flapping, the scale-in threshold must be significantly lower than the scale-out threshold.
Question 892Question →

You are managing a CPU-intensive web API named TelemetryProcessor that runs on an Azure App Service Web App. The application is currently hosted on a Shared (D1) App Service plan. During peak hours, the application experiences performance degradation due to CPU spikes. You need to configure the App Service plan to scale out automatically during CPU spikes, ensure the configuration is cost-effective, and prevent autoscale flapping.

Which sequence of steps should you perform to configure the scaling behavior?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To configure autoscaling for the application, first upgrade the App Service plan from the Shared (D1) tier to the Standard (S1) tier. Then, enable autoscale and configure the instance capacity limits. Next, add a scale-out rule that increases the instance count when the CPU Percentage metric exceeds 80%. Finally, add a scale-in rule that decreases the instance count when the CPU Percentage metric falls below 40% to prevent flapping.
The correct sequence ensures that you first scale up the plan to a tier that supports autoscaling, initialize the autoscale setting container, establish the scale-out rule to manage high utilization, and finally establish the scale-in rule with a safe threshold to prevent resource flapping.

Step-by-Step Solution

1
Upgrade the App Service plan from the Shared (D1) tier to the Standard (S1) tier.
The App Service plan is moved to a tier that supports scaling out and autoscale configurations.
The Shared (D1) tier has shared infrastructure and cannot scale out. Upgrading to the Standard (S1) tier is required to support autoscaling.
2
Enable autoscale on the App Service plan and define the minimum, maximum, and default instance capacity limits.
An autoscale profile is created with the specified instance boundaries.
You must establish the autoscale setting container and its capacity boundaries before adding individual metric-based rules.
3
Configure a scale-out rule that increases the instance count by 1 when the CPU Percentage metric exceeds 80%.
A metric-based trigger is added to increase resources during high-traffic CPU spikes.
This rule targets the CPU spikes and adds instances to distribute the load during peak utilization.
4
Configure a scale-in rule that decreases the instance count by 1 when the CPU Percentage metric falls below 40%.
A metric-based trigger is added to scale back down when load decreases, using a safe threshold to prevent immediate rescaling.
To prevent autoscale flapping, the scale-in threshold must be set to a level where the remaining instances can absorb the redistributed load without immediately violating the scale-out rule. A threshold of 40% is safe when scaling out at 80%.

Key Concept

Autoscaling in Azure App Service requires a supported pricing tier (Standard or higher). Once upgraded, the autoscale setting must be created to define capacity boundaries, followed by scale-out rules for performance and scale-in rules with a proper buffer threshold to prevent autoscale flapping.
Estimated Time:2m 0s
Question 893Question →

You are developing a C# (.NET Isolated process) Durable Function to transcode and analyze video files. The workflow implements a Fan-out/Fan-in pattern: it first calls a transcoding activity, then launches parallel analysis activities on the transcoded video, and finally aggregates the results.

To ensure the durability of the execution, the Durable Functions runtime uses event sourcing and replays the orchestrator function.

You need to sequence the lifecycle and replay steps of this workflow from the initial client request to the completion of the orchestration.

In which order do these events occur during the execution of this workflow?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order of events starts with the client launching the orchestration, followed by the orchestrator initiating execution and yielding at the transcoding task. Once completed, the orchestrator replays to resolve the transcoding result and then invokes the parallel analysis activities, yielding on their concurrent execution. Finally, after all analysis tasks finish, the orchestrator replays a last time to retrieve their values, runs the aggregation activity, and finishes.
The execution begins with the client starting the orchestration. The orchestrator runs and yields at the first await (transcoding). After the transcode completes, the orchestrator replays the function, retrieves the transcoding result from history, runs the parallel tasks, and yields again. Once the parallel tasks complete, the orchestrator replays to obtain all analysis results, runs the final aggregation activity, and completes.

Step-by-Step Solution

1
Trigger the orchestration.
An orchestration instance is created and a status response is returned.
The client function initiates the orchestration lifecycle using the Durable Task client.
2
Execute the orchestrator up to the first await point.
The transcoding activity is scheduled and the orchestrator yields.
The orchestrator executes sequentially until it encounters an await on an asynchronous activity task.
3
Replay the orchestrator after the transcode completes.
The transcoding result is read from the execution history.
Durable Functions use event sourcing; the orchestrator replays from the start to reconstruct its state.
4
Schedule parallel tasks and yield.
Parallel activities are scheduled, and the orchestrator yields on Task.WhenAll.
For the Fan-out pattern, multiple tasks are scheduled concurrently and awaited together.
5
Replay and complete the orchestration.
The aggregation activity runs and the orchestrator completes.
After all parallel tasks finish, the orchestrator replays one last time, processes the aggregated data, and completes.

Key Concept

Durable Functions Orchestrator Replay and Execution Lifecycle
Question 894Question →

You are developing a C# background service that must safely update the content of an existing blob named config.json in Azure Blob Storage. To prevent concurrency conflicts, your service must lock the blob using a lease before performing the upload and release the lease immediately afterward. You are using the Azure.Storage.Blobs (v12) SDK.

Order the steps required to implement this lease-based upload workflow.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order of operations is to first create the BlobClient, then instantiate the BlobLeaseClient, acquire the lease, upload the blob content with the lease ID included in the request conditions, and finally release the lease.
To safely modify a leased blob, you must establish client references, acquire the lock to obtain a lease ID, supply that lease ID with the upload request, and release the lock when the operation is complete.

Step-by-Step Solution

1
Instantiate the BlobClient client.
A BlobClient object representing config.json is created.
This object is the starting point for interacting with the blob.
2
Instantiate the BlobLeaseClient client.
A BlobLeaseClient object linked to the BlobClient is created.
The lease client manages all lock-related actions on that blob.
3
Acquire the lease.
A Lease object is returned containing the unique LeaseId.
This locks the blob against unauthorized updates.
4
Upload content with the lease ID.
The blob is updated with the new content.
Passing the lease ID in the request conditions authorizes the update.
5
Release the lease.
The lease is removed from the blob.
Releasing the lease unlocks the blob for subsequent operations.

Key Concept

Lease management workflow in Azure Storage Blobs C# SDK
Estimated Time:1m 30s
Question 895Question →

You are developing an API gateway solution using Azure API Management (APIM). The API must implement rate limiting based on a client's subscription ID and cache the backend responses to reduce backend load. The rate limiting should trigger if a client makes more than 100 requests per 60 seconds. Responses must be cached for 3600 seconds.

Complete the XML policy definition by filling in the blanks. What are the correct XML elements for blank 1, blank 2, and blank 3?

Fill in the blanks below

<policies>
<inbound>
<base />
< calls="100" renewal-period="60" counter-key="@(context.Subscription.Id)" />
< vary-by-developer="false" vary-by-developer-groups="false" downstream-caching-type="none" />
</inbound>
<outbound>
<base />
< duration="3600" />
</outbound>
</policies>
Show answer & explanation

Answer

The correct XML elements to fill in the blanks are rate-limit-by-key for blank 1, cache-lookup for blank 2, and cache-store for blank 3.
The rate-limit-by-key policy allows rate limiting based on expressions like the client subscription ID. The cache-lookup policy evaluates the incoming request against cached responses in the inbound pipeline, while the cache-store policy saves the response payload in the cache during the outbound pipeline.

Step-by-Step Solution

1
Identify the policy element that allows rate limiting with a custom key.
rate-limit-by-key
The counter-key attribute is used in the policy to track limits by subscription ID, which is only supported by rate-limit-by-key, not the standard rate-limit policy.
2
Identify the policy element that performs response cache lookup during inbound processing.
cache-lookup
The cache-lookup policy must be placed in the inbound section to check for a cached response before making a call to the backend.
3
Identify the policy element that stores response payloads in the cache during outbound processing.
cache-store
The cache-store policy must be placed in the outbound section to cache responses coming back from the backend for the specified duration.

Key Concept

Azure API Management policies configuration for rate limiting by key and response caching.
Question 896Question →

A backend service named ReportRunner handles report generation and is deployed to an Azure App Service Web App. The App Service is currently running on the Basic (B1) tier. During peak monthly billing cycles, report generation jobs stall because of resource constraints, and you must configure autoscale to automatically add instances when CPU utilization exceeds 70%70\%.

Which of the following actions should you perform first to support this requirement?

Show answer & explanation

Answer: Scale up the App Service plan to the Standard (S1) tier.

Answer

Scale up the App Service plan to the Standard (S1) tier.
Scaling up the App Service plan to the Standard (S1) tier is correct because autoscale features, including rule-based scaling on metrics such as CPU Percentage, are not available in the Basic (B1) tier. The Basic tier only supports manual scaling up to three instances. Upgrading to the Standard tier is a prerequisite for configuring autoscale.

Step-by-Step Solution

1
Verify the capabilities of the current App Service pricing tier.
Determine that the Basic (B1) tier only supports manual scaling up to three instances and does not support autoscale rules.
To evaluate if the current plan can host the required autoscale configuration.
2
Identify the minimum pricing tier required to enable automated metric-based scaling.
Determine that the Standard (S1) tier is the lowest tier that supports autoscale rules.
To establish the target tier for the scale-up action.
3
Ensure that the autoscale rules do not conflict or cause flapping.
Configure a scale-out rule at 70%70\% and a scale-in rule at a value significantly lower than 70%70\% (e.g., 50%50\%) on the new Standard plan.
To prevent the app service from constantly scaling out and scaling in repeatedly due to threshold overlap.

Key Concept

App Service Plan Tiers and Autoscale Configurations
Question 897Question →

You are developing an ASP.NET Core web application that will authenticate users using the Microsoft Identity Platform and then call a downstream web API. You need to configure Microsoft Entra ID and the application to enable this confidential client authentication scenario. Which two configuration steps are required? (Select two.)

Select all that apply

Show answer & explanation

Answer: Configure the Redirect URI in the Microsoft Entra ID app registration to match the application's sign-in callback endpoint.; Generate a client secret or upload a certificate in the Microsoft Entra ID app registration for the application to authenticate itself.

Answer

To configure a web application that authenticates users and calls a downstream web API (confidential client flow), you must configure the Redirect URI in the Microsoft Entra ID app registration and generate a client secret or certificate in the app registration to allow the confidential client to authenticate during token exchange.
For a web application that authenticates users and calls a downstream web API (confidential client), you must configure: 1) the Redirect URI so the user agent is returned to the correct endpoint after authentication, and 2) a client secret or certificate to authenticate the web app when it exchanges the authorization code for an access token. The options specifying Redirect URI configuration and generating a client secret/certificate are correct.

Step-by-Step Solution

1
Create an application registration in the Microsoft Entra admin center.
The application obtains a client ID and tenant ID required for configuring the MSAL client.
This establishes the identity of the web application in Microsoft Entra ID.
2
Add a Redirect URI of type 'Web' matching the local application URL (e.g., https://localhost:5001/signin-oidc).
Microsoft Entra ID is allowed to send the authorization code to the specified application endpoint.
Redirect URIs prevent tokens from being redirected to unauthorized endpoints.
3
Generate a client secret under the Certificates & Secrets blade of the registration.
The web app can use this secret credential to prove its identity during code exchange.
Confidential client applications must authenticate themselves when requesting access tokens using the authorization code flow.

Key Concept

Confidential Client Application configuration in Microsoft Identity Platform authentication
Estimated Time:1m 0s
Question 898Question →

An e-commerce application uses an Azure Cosmos DB SQL API container named `Orders` partitioned by `/customerId`. You are implementing two new independent microservices:

* `OrderArchiver` to archive order documents to Azure Blob Storage.
* `InventoryUpdater` to update external inventory counts.

Both microservices will scale out across multiple host instances, and both are configured to use the same lease container named `leases`. During testing, you observe that when both microservices are running, each order event is processed by either `OrderArchiver` or `InventoryUpdater`, but never by both.

You need to ensure that all instances of both microservices process every event from the change feed.

What should you do?

Show answer & explanation

Answer: Configure each microservice to use a unique `processorName` when calling `GetChangeFeedProcessorBuilder`.

Answer

Configure each microservice to use a unique `processorName` when calling `GetChangeFeedProcessorBuilder`.
The processor name parameter represents a logical group of instances (consumer group) that share the processing of the change feed. When two different workloads (like the archiver and inventory updater) share the same lease container and the same processor name, they are treated as a single consumer group. Consequently, the leases are distributed among all instances of both applications, causing each event to be processed by only one of them. Assigning a unique processor name to each microservice allows them to act as separate consumer groups, enabling both to receive a full copy of all change feed events.

Step-by-Step Solution

1
Identify the cause of the split events.
Since both microservices use the same lease container and the same default processor name, the SDK groups them together, load-balancing partition leases across all hosts of both services.
By default, the SDK treats instances with the same processor name as a single consumer group, splitting the events among them.
2
Understand consumer groups in Cosmos DB Change Feed.
Each independent functional workload must have its own logical name (processorName) so that the leases are partitioned separately.
This allows each consumer group to maintain its own checkpoint state and consume the full feed.
3
Assign a unique processorName to each microservice during builder initialization.
This creates separate leases in the lease container, allowing both microservices to consume every event.
Using separate processor names ensures that both the archiver and the inventory updater function as distinct consumer groups.

Key Concept

Cosmos DB Change Feed Processor Consumer Groups
Question 899Question →

A smart home IoT solution uses Azure Service Bus to route command messages to individual smart devices. The commands for each device must be processed in the exact order they are received to prevent state conflicts. You are configuring a .NET application using the Azure.Messaging.ServiceBus SDK to process these command messages for one device session at a time, settle the processed messages, and release the session so that other workers can pick up different device sessions.

In which order should you execute the code steps to achieve this?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct logical order is: first, instantiate the client; second, accept the next available session; third, receive the message; fourth, complete the message; and fifth, close the session receiver.
Establishing a connection via the client is a prerequisite for creating any receiver. For sessionful entities, a session receiver must be obtained using the client to lock the session before messages can be received. After receiving and processing a message, it must be completed before the session lock is released by closing the receiver.

Step-by-Step Solution

1
Create the ServiceBusClient using the namespace connection string.
An active ServiceBusClient instance is initialized.
The client is the primary object used to communicate with the Service Bus service and must be created first.
2
Request a session-specific receiver by calling AcceptNextSessionAsync.
A ServiceBusSessionReceiver instance is obtained and the next available session is locked.
To consume messages from a session-enabled queue, a receiver must bind to and lock a specific session ID.
3
Receive a message by calling ReceiveMessageAsync.
A ServiceBusReceivedMessage object representing the next message in the session is returned.
Messages can only be fetched from the queue once a session-specific receiver has successfully locked the session.
4
Settle the message by calling CompleteMessageAsync.
The message is permanently deleted from the queue.
The message must be completed to confirm successful processing and prevent it from being reprocessed.
5
Release the session by calling CloseAsync on the receiver.
The session lock is released, and the receiver resources are cleaned up.
Closing the session receiver is necessary to release the exclusive lock on the session ID, allowing other instances of the worker to process messages for this session.

Key Concept

Session-based message processing and lifecycle management using the Azure Service Bus SDK.
Question 900Question →

A globally distributed web application uses an Azure Cosmos DB API for NoSQL account with Session consistency. The account has a write region in East US and a read region in West US. Users report that when they update their profile on a mobile app and immediately view it on a web browser, the updates are not visible. You need to resolve this issue in the most cost-effective manner while maintaining low latency. Which of the following actions should you perform?

Show answer & explanation

Answer: Extract the session token from the write response on the mobile app and pass it to the read request on the web browser client.

Answer

Extract the session token from the write response on the mobile app and pass it to the read request on the web browser client.
Extracting the session token from the write response and passing it to the read request allows the session context to be shared across distinct client instances. This satisfies the read-your-writes requirement for different devices while preserving the low latency and low cost of Session consistency.

Step-by-Step Solution

1
Analyze the consistency requirements and constraints.
The application requires read-your-writes consistency across two different client sessions (mobile app and web browser) in a cost-effective manner without increasing write latency.
By default, Session consistency guarantees read-your-writes only within the same client session.
2
Evaluate how to extend Session consistency across clients.
The Azure Cosmos DB SDK allows extracting the session token from the header of a write operation response and passing it to a different client instance for subsequent reads.
This allows the second client to participate in the same session context, achieving the required consistency without changing the database account's consistency level.

Key Concept

Session consistency token passing in Azure Cosmos DB
PreviousPage 45 / 49Next