Examkin

All practice questions

9 questions

All types972Multiple choice497Multiple select269Matching9Ordering171Fill in the blank26
Question 1Question →

You are designing autoscale rules for various Azure workloads. Match each workload requirement on the left to the correct Azure Monitor Autoscale configuration pattern on the right to optimize resource scaling and prevent flapping.

Click a left item, then click its matching right item

Items

Prevent transient CPU spikes lasting less than 55 minutes from triggering a scale-out action on an App Service plan.
Trigger a scale-out action when any individual virtual machine within a Virtual Machine Scale Set (VMSS) exceeds a memory utilization threshold.
Avoid rapid scale-out and scale-in oscillations (flapping) when configuring a scale-in rule for a queue-based processing workload.
Scale out a service based on the cumulative volume of transaction logs generated across all instances during a 1010-minute evaluation window.

Matches

Show answer & explanation

Answer

To prevent transient spikes, configure the duration to 1010 minutes with Average Time Aggregation. To scale based on any individual instance, set the Metric Statistic (Instance Aggregation) to Maximum. To prevent flapping, use a sufficient margin between thresholds and a Cool-down period. To scale based on cumulative volume, set the Time Aggregation to Total.
The correct matches align with standard Azure Monitor autoscale rules: Average Time Aggregation over a 1010-minute window smooths out transient spikes under 55 minutes; setting Metric Statistic to Maximum ensures an individual instance triggering the threshold scales the group; appropriate threshold margins and Cool-down periods prevent flapping; and Total Time Aggregation is used to measure the aggregate volume of metrics over a time window.

Step-by-Step Solution

1
Analyze transient spike prevention requirements.
Identify that short-term fluctuations must be averaged out over a window longer than the spike duration, mapping to 'Configure the metric trigger Duration to 1010 minutes and use Average Time Aggregation'.
This prevents single-minute spikes from skewing the autoscale decision prematurely.
2
Analyze individual instance behavior requirements.
Identify that the metric aggregation across instances (Metric Statistic) must be set to Maximum to catch when any single instance crosses the threshold, mapping to 'Set the Metric Statistic (Instance Aggregation) to Maximum for the Memory metric'.
By default, Azure Monitor averages metrics across all instances. Maximum ensures the highest loaded node triggers scaling.
3
Analyze flapping prevention requirements.
Identify that setting thresholds too close together or using short cool-downs causes loops. Mapping to 'Set a sufficient margin between scale-out and scale-in thresholds, and configure an adequate Cool-down period'.
Cool-down and threshold separation allow the system to reach a steady state before evaluating rules again.
4
Analyze cumulative volume scaling requirements.
Identify that cumulative counts require summing up values, mapping to 'Set the Time Aggregation to Total for the custom volume metric over the specified time window'.
Total aggregation represents the sum of all sample values in the window, capturing cumulative totals.

Key Concept

Azure Monitor Autoscale rule configuration parameters, including Time Aggregation, Metric Statistic (Instance Aggregation), Durations, and Cool-down periods to prevent flapping and optimize scaling behavior.
Estimated Time:2m 30s
Question 2Question →

Match each Azure Cosmos DB consistency level on the left with its corresponding behavior or guarantee on the right.

Click a left item, then click its matching right item

Items

Strong
Session
Bounded Staleness
Eventual

Matches

Show answer & explanation

Answer

Strong consistency matches with synchronous write updates and most recent version reads; Session consistency matches with connection-scoped read-your-writes and is the default setting; Bounded Staleness matches with configuration of staleness thresholds (KK or TT); Eventual consistency matches with no ordering guarantees and lowest latency.
Strong consistency matches with synchronous write replication because it ensures reads always receive the most recent committed state. Session consistency matches with connection-scoped guarantees and is the default level. Bounded Staleness matches with defined thresholds (KK or TT) because it guarantees reads do not lag beyond those limits. Eventual consistency matches with no ordering guarantees and lowest latency because replication is fully asynchronous.

Step-by-Step Solution

1
Identify the characteristics of Strong consistency.
Strong consistency requires synchronous quorum write agreement, meaning reads always see the absolute latest write.
To match Strong with its definition of absolute consistency at the cost of latency.
2
Identify the characteristics of Session consistency.
Session consistency is the default level and guarantees that within the same session/client connection, the client will read their own writes.
To match Session with its connection-specific guarantees.
3
Identify the characteristics of Bounded Staleness consistency.
Bounded Staleness allows configuration of a staleness window, defined by either maximum versions (KK) or time duration (TT).
To match Bounded Staleness with its defined lag parameter constraints.
4
Identify the characteristics of Eventual consistency.
Eventual consistency has no order guarantees, permitting replicas to catch up out-of-order asynchronously, yielding the lowest latency.
To match Eventual with its weakly consistent, highly performant behaviors.

Key Concept

Azure Cosmos DB Consistency Levels
Question 3Question →

Match each application scenario to the most appropriate Azure Cosmos DB consistency level that satisfies the requirements with the lowest resource overhead.

Click a left item, then click its matching right item

Items

A financial ledger application deployed to a single write region with multiple read regions that requires all clients to immediately read the most recently committed state before any subsequent transaction is processed.
A globally distributed multiplayer game using a multi-region write account that requires player updates to be viewed in chronological order by all players globally, with a guaranteed lag of no more than 100,000100,000 updates or 55 minutes.
An e-commerce shopping cart service where a user must always see the items they just added to their cart immediately upon refreshing their browser session, while other users can tolerate propagation delay.
A video streaming platform's trending list where updates must never appear out of order to readers, but no strict real-time lag bounds are required, optimizing for resource cost.

Matches

Show answer & explanation

Answer

The correct matches associate the financial ledger with Strong, the multiplayer game with Bounded Staleness, the shopping cart with Session, and the trending video list with Consistent Prefix.
The correct matching aligns the strict linearizability requirement of the financial ledger to Strong consistency; the time/version bounded ordering on multi-region writes to Bounded Staleness; the user-scoped write-read cycle to Session consistency; and the out-of-order prevention without time bounds to Consistent Prefix.

Step-by-Step Solution

1
Analyze the financial ledger requirement.
It requires absolute global consistency ('immediately read the most recently committed state') which can only be satisfied by Strong consistency.
Strong consistency guarantees that any read returns the most recent write globally, preventing stale reads across regions.
2
Analyze the multiplayer game requirement.
It runs on a multi-region write account and requires a bound on replication lag (100,000100,000 updates or 55 minutes) along with ordered reads. This corresponds to Bounded Staleness consistency.
Bounded Staleness allows multi-region writes while ensuring that reads outside the write region do not lag beyond the configured threshold of KK versions or TT time.
3
Analyze the shopping cart requirement.
It requires read-your-own-writes for a single user's browser session. Session consistency provides this guarantee within the client session.
Session consistency scope guarantees read-your-own-writes and monotonic reads for the specific client using the session token.
4
Analyze the trending list requirement.
It requires updates to never appear out of order but has no strict lag bounds. Consistent Prefix meets this ordering requirement with lower resource overhead.
Consistent Prefix ensures that readers see updates in the order they were written without incurring the higher RU cost and latency of Bounded Staleness.

Key Concept

Azure Cosmos DB consistency levels and their trade-offs regarding replication latency, throughput, ordering guarantees, and availability.
Question 4Question →

An organization is designing several applications that will use Azure Cosmos DB API for NoSQL. You must select the appropriate default consistency level for each application based on its specific requirements.

Match each application requirement on the left to its optimal Azure Cosmos DB consistency level on the right.

Click a left item, then click its matching right item

Items

A collaborative document editor where a user must always see their own modifications immediately, while other users may observe the changes after a replication lag.
A financial transaction ledger where reads must always return the absolute latest committed version of a record across all globally distributed regions.
A sports live score tracker where updates must be read in the order they occurred (e.g., scoring a goal must not appear before starting the match), but a slight delay in receiving updates is acceptable.
A weather monitoring system where reads from global read regions can lag behind the single write region, but by no more than 100 updates or 5 minutes.

Matches

Show answer & explanation

Answer

Match the collaborative document editor to Session consistency, the financial transaction ledger to Strong consistency, the sports live score tracker to Consistent Prefix consistency, and the weather monitoring system to Bounded Staleness consistency.
Matching the requirements to their respective consistency levels aligns with their architectural guarantees: Strong consistency guarantees real-time global updates; Session consistency guarantees read-your-own-writes within the client connection context; Consistent Prefix consistency ensures that updates are never observed out of order; and Bounded Staleness consistency restricts staleness to a defined time or version threshold.

Step-by-Step Solution

1
Analyze the financial transaction ledger requirement for absolute latest committed version globally.
Identify that only Strong consistency guarantees that reads always return the most recent committed version of an item across all regions.
Strong consistency offers linearizability, ensuring reads are guaranteed to return the latest committed write.
2
Analyze the collaborative document editor requirement for a user reading their own modifications immediately.
Identify that Session consistency is the optimal choice as it guarantees read-your-own-writes (RYOW) within a client session.
Session consistency provides monotonic reads and writes, scoping consistency guarantees to the client session.
3
Analyze the sports live score tracker requirement for ordered reads with acceptable lag.
Identify that Consistent Prefix consistency guarantees that reads never see out-of-order writes.
Consistent Prefix ensures that readers see updates in the exact order they were written, even if there is propagation delay.
4
Analyze the weather monitoring system requirement for lag limits of 100 updates or 5 minutes.
Identify that Bounded Staleness consistency is designed specifically to restrict staleness to a defined window of operations or time.
Bounded Staleness allows defining staleness bounds in terms of version lag (K) or time interval (T).

Key Concept

Selecting and configuring the correct Azure Cosmos DB consistency level based on application latency, throughput, and consistency requirements.
Question 5Question →

Match each Azure Monitor autoscale parameter on the left to its correct functional description on the right.

Click a left item, then click its matching right item

Items

Cool-down
Duration
Total time aggregation

Matches

Show answer & explanation

Answer

Cool-down matches the wait period after a scale event. Duration matches the collection time window. Total time aggregation matches the sum of metric values.
The correct pairings map Cool-down to the post-scale delay period, Duration to the historical metric collection window, and Total time aggregation to the metric summation method.

Step-by-Step Solution

1
Identify the purpose of the Cool-down setting in Azure Monitor autoscale rules.
Cool-down is designed to prevent rapid scale-up/scale-down cycles by enforcing a post-scale delay.
This matches the description of waiting a set time after a scale action before allowing further adjustments.
2
Analyze the meaning of the Duration parameter.
Duration specifies the time window over which the metrics are gathered prior to comparison against the threshold.
This aligns with the description of the collection and evaluation time window.
3
Determine the role of the Total time aggregation option.
Total is an aggregation type that sums up the telemetry data values over the monitoring duration.
This matches the description of the sum of all collected metric values.

Key Concept

Azure Monitor autoscale configuration settings including duration, cool-down, and metric aggregation.
Estimated Time:1m 0s
Question 6Question →

You are configuring Azure Monitor autoscale rules for different workloads. Match each scaling requirement on the left to its correct Azure Monitor metric and time aggregation configuration on the right.

Click a left item, then click its matching right item

Items

A memory-sensitive background worker running on an Azure App Service plan must scale out when the average memory usage across the instances exceeds 80%80\%.
A CPU-intensive batch rendering service on an Azure Virtual Machine Scale Set (VMSS) must scale out if any single VM instance reaches 90%90\% CPU utilization.
An API gateway on an Azure App Service plan must scale out when the total volume of network payload data received by the plan exceeds 500 MB500\text{ MB}.

Matches

Show answer & explanation

Answer

Match the memory-sensitive worker to Memory Percentage and Average; match the CPU-intensive batch rendering to CPU Percentage and Maximum; and match the API gateway network volume to Data In and Total.
The correct pairings align the metric and time aggregation with the workload constraints: Memory Percentage (Average) for overall memory usage, CPU Percentage (Maximum) to scale when any single instance peaks, and Data In (Total) to measure the cumulative incoming network payload.

Step-by-Step Solution

1
Identify the target resource metric for each scenario.
Memory-sensitive worker uses Memory Percentage; CPU-intensive worker uses CPU Percentage; network payload volume uses Data In.
Correct metric selection ensures the autoscale rule reacts to the correct resource bottleneck.
2
Determine the appropriate time aggregation based on the trigger condition.
Average is used for overall memory trend; Maximum is used to catch any single VM instance hitting the CPU limit; Total is used to sum the network data volume over the duration.
Time aggregation defines how the metric values collected over time and across instances are combined to evaluate the threshold.

Key Concept

Azure Monitor autoscale rules require selecting the correct resource metric and time aggregation (statistic) to properly align with workload requirements and prevent issues like flapping or missed scaling events.
Estimated Time:2m 0s
Question 7Question →

You are configuring Azure Monitor autoscale rules for several Azure resources. Match each workload scaling requirement on the left to the most appropriate Azure Monitor autoscale metric and time aggregation configuration on the right.

Click a left item, then click its matching right item

Items

A queue-processing backend application needs to scale out rapidly when a large burst of messages is placed in the queue, focusing on the peak volume.
A memory-intensive microservice running on an Azure App Service plan must scale out when the overall memory usage across all instances exceeds a defined threshold.
A web API hosted on an Azure App Service plan needs to scale out when requests are queued up due to server thread exhaustion.
A data-streaming service running on an Azure Virtual Machine Scale Set (VMSS) needs to scale out based on the total volume of network traffic sent from the scale set.

Matches

Show answer & explanation

Answer

Match the queue-processing application with ActiveMessageCount (Maximum); match the memory-intensive microservice with MemoryPercentage (Average); match the web API thread exhaustion with HttpQueueLength (Average); and match the data-streaming service with Network Out (Total).
The correct pairings align each resource requirement with its target resource metric and the mathematically appropriate time aggregation. ActiveMessageCount (Maximum) reacts immediately to queue spikes; MemoryPercentage (Average) tracks memory usage stably; HttpQueueLength (Average) detects IIS/App Service request queuing; and Network Out (Total) measures the total volume of data transmitted over the monitoring window.

Step-by-Step Solution

1
Analyze the queue-processing requirement.
Since it processes messages from a queue and needs to scale out based on peak volume spikes, ActiveMessageCount with a Time Aggregation of Maximum is the correct configuration.
Maximum aggregation captures the peak value within the evaluation interval, ensuring the scale-out action is triggered immediately during a burst.
2
Analyze the memory-intensive microservice requirement.
For memory usage on App Service, the MemoryPercentage metric with an Average time aggregation is appropriate.
Average resource aggregation provides a stable indicator of overall memory consumption, avoiding premature scaling based on brief spikes.
3
Analyze the web API thread exhaustion scenario.
Thread pool exhaustion in an App Service results in requests waiting in the queue. The HttpQueueLength metric aggregated as Average is the correct match.
HttpQueueLength measures the queue of requests waiting to be handled, indicating that the existing instances cannot handle the concurrency load.
4
Analyze the data-streaming service requirement.
Data-streaming outbound volume is monitored using the Network Out metric with a Total time aggregation.
Total time aggregation measures the cumulative bytes sent over the time grain, which represents the total volume of network traffic.

Key Concept

Selecting correct metrics and time aggregation types for Azure Monitor autoscale rules.
Question 8Question →

You are designing autoscale rules for several Azure solutions to optimize performance and prevent rapid oscillation (flapping). Match each Azure Monitor autoscale configuration setting on the left to the corresponding workload requirement it satisfies on the right.

Click a left item, then click its matching right item

Items

Time aggregation set to Maximum for CPU Percentage
Cool-down period set to 2020 minutes for scale-in rules
Metric set to Service Bus queue message count
Time aggregation set to Average for CPU Percentage

Matches

Show answer & explanation

Answer

Time aggregation set to Maximum for CPU Percentage matches with triggering scale-out if any single instance is overloaded. Cool-down period set to 2020 minutes for scale-in rules matches with avoiding reducing capacity too quickly. Metric set to Service Bus queue message count matches with scaling based on the total queue backlog. Time aggregation set to Average for CPU Percentage matches with scaling based on the overall, balanced resource utilization.
The correct pairings align each autoscale configuration parameter with its direct operational outcome. Time aggregation set to Maximum ensures that scale-out occurs if a single instance is overloaded. The cool-down period delays scale-in actions to prevent flapping. The Service Bus queue message count reflects the total workload backlog. Time aggregation set to Average measures overall, balanced pool utilization.

Step-by-Step Solution

1
Analyze the impact of Time Aggregation Maximum on autoscale behavior.
Maximum looks at the peak value among all instances, which correlates directly with detecting if any single instance is overloaded.
This matches the requirement to prevent individual instance degradation.
2
Evaluate the function of the scale-in cool-down period.
The cool-down period prevents the autoscale engine from performing another scale-in action for a set time (e.g., 2020 minutes) after a scaling event.
This is used to stabilize the system and allow active tasks to finish without immediate scale-down.
3
Identify the metric suitable for queue backlog workloads.
Service Bus queue message count represents the work queue backlog.
This matches the workload's scaling requirement based on pending work.
4
Determine the application of Time Aggregation Average.
Average computes the mean value across all instances, representing balanced workload pressure.
This is suitable for standard web apps where traffic is evenly distributed.

Key Concept

Azure Monitor Autoscale rule metric parameters and aggregation types are configured to match specific workload scaling patterns and prevent flapping.
Question 9Question →

You are designing a globally distributed application that utilizes Azure Cosmos DB. You need to select the most appropriate consistency level for three different application scenarios to meet their architectural requirements while optimizing for request units (RUs) and performance. Match each application scenario to its optimal Azure Cosmos DB consistency level.

Click a left item, then click its matching right item

Items

A retail checkout application uses a globally distributed Azure Cosmos DB account configured with a single-write region and multiple read regions. To prevent stock discrepancies, client applications must be guaranteed to read the most recent, fully committed write from any region, regardless of latency overhead.
An e-commerce user profile application runs on a globally distributed Azure Cosmos DB account with multiple read regions. A web application must guarantee that a user who edits their shipping address will always see the updated address on subsequent page loads within their browser session. Other users do not need to see the update immediately.
A global package tracking application uses an Azure Cosmos DB account with multiple write regions. The tracking system logs package scan events sequentially (e.g., 'Departed facility' must never be visible before 'Arrived at facility'). The application must guarantee that reads see updates in their exact write order, while keeping Request Unit (RU) costs lower than Bounded Staleness.

Matches

Show answer & explanation

Answer

The retail checkout application scenario matches Strong consistency, the e-commerce user profile application matches Session consistency, and the global package tracking application matches Consistent Prefix consistency.
The correct pairings align each scenario with the lowest-overhead consistency level that satisfies its core requirements. The checkout system requires Strong consistency to prevent stock discrepancies. The user profile updates are scoped to a browser session, making Session consistency the ideal choice for read-your-own-writes. The tracking system requires ordered updates without real-time consistency, which is satisfied by Consistent Prefix at a lower cost than Bounded Staleness.

Step-by-Step Solution

1
Analyze the requirements for the retail checkout application.
The application requires absolute global consistency to prevent stock discrepancies, meaning reads must always return the most recent write. This requires Strong consistency.
Strong consistency is the only level that guarantees reads always return the latest committed write globally.
2
Analyze the requirements for the user profile application.
The user must immediately see their own shipping address updates on subsequent page loads, which is a classic read-your-own-writes requirement scoped to a browser session. This matches Session consistency.
Session consistency is scoped to the client session and guarantees read-your-own-writes, monotonic reads, and monotonic writes.
3
Analyze the requirements for the package tracking application.
The package tracking events must be read in the exact order they were written to avoid logical inconsistencies (e.g., departed before arrived), but real-time global synchronization is not needed. The cost must be lower than Bounded Staleness, which points to Consistent Prefix.
Consistent Prefix guarantees that reads see updates as a prefix of all writes in order, with lower resource overhead than Bounded Staleness.

Key Concept

Understanding and selecting Azure Cosmos DB consistency levels based on application requirements, latency, ordering guarantees, and resource cost.
All practice questions — Microsoft Azure Developer (AZ-204) | Examkin