Technical Lab: Interpret metrics in Azure Monitor
Questions
Question 1 — Multiple Choice
An operations team needs to identify if a virtual machine is experiencing memory pressure over time. When accessing Azure Monitor, the engineer navigates to the metrics section and selects the correct resource.
Which of the following statements correctly describes the behavior of platform metrics regarding virtual machine memory in Azure Monitor?
A) Platform metrics automatically include available RAM usage, as this data is collected by the underlying hypervisor without needing an agent.
B) RAM usage is not available as a platform metric for VMs; it's necessary to install the Azure Monitor Agent and configure a Data Collection Rule to collect this metric as a guest metric.
C) The available memory metric is automatically collected by Azure Monitor and stored in the Log Analytics Workspace without any additional configuration.
D) To obtain memory metrics, simply enable Diagnostic Settings at the subscription level, redirecting the data to a Storage Account.
Question 2 — Technical Scenario
An engineer is analyzing the following chart in Azure Monitor for a production VM:
Metric: Percentage CPU
Time range: Last 24 hours
Granularity: 1 hour
Selected aggregation: Maximum
The chart shows 95% CPU spikes at specific moments, but the development team claims the application "never uses that much CPU". The engineer suspects the reading is incorrect.
What is the most likely explanation for the discrepancy?
A) The Maximum aggregation displays the highest value recorded within each granularity interval, which can capture momentary spikes that the team doesn't notice in daily usage.
B) The 1-hour granularity is calculating the average of values, smoothing the data and generating artificially elevated readings.
C) The Percentage CPU metric in Azure Monitor measures consumption relative to the vCPU throttling limit, not actual processor usage, which distorts the values.
D) Azure Monitor stores metrics with up to 1 hour delay, so the visualized spikes correspond to events from other VMs on the same physical host.
Question 3 — True or False
Statement: In Azure Monitor, when creating a metrics chart in Metrics Explorer, it's possible to plot metrics from different Azure resources on the same chart, as long as those resources are in the same subscription.
True or False?
Question 4 — Technical Scenario
An SRE team configured the following alert in Azure Monitor:
Resource: Storage Account (prodstg01)
Metric: Transactions
Aggregation: Total
Granularity: 5 minutes
Condition: Total > 10000
Frequency: Every 1 minute
After deployment, the team observes that the alert fires repeatedly even when the actual number of transactions is below expected. The Storage Account is high-demand and processes short bursts of requests.
What is the most likely cause of the unexpected behavior?
A) The Transactions metric doesn't support Total aggregation; the correct approach would be to use Average, which explains the inflated count.
B) The combination of 5-minute granularity with 1-minute evaluation frequency causes the aggregation window to accumulate transactions from multiple overlapping periods, artificially elevating the evaluated value.
C) Azure Monitor is summing transactions from all Storage Accounts in the subscription because the alert scope wasn't filtered by Resource Group.
D) The 1-minute evaluation frequency is less than the 5-minute granularity, forcing Azure Monitor to fill missing intervals with the last recorded value, duplicating counts.
Question 5 — Multiple Choice
An administrator needs to compare CPU consumption across three different VMs using Azure Monitor's Metrics Explorer. They want to visualize all three series on the same chart to facilitate comparative analysis.
Which approach is correct to achieve this objective?
A) Create three separate charts, one per VM, since Metrics Explorer doesn't allow adding metrics from multiple individual resources on the same chart.
B) Use the Add metric functionality multiple times, selecting each VM as a resource with the same metric, resulting in distinct series on the same chart.
C) Create a Log Analytics Workspace and write a KQL query to join data from the three VMs, since metrics from multiple resources are only comparable via logs.
D) Group the three VMs in a dedicated Resource Group and select the Resource Group as scope, applying resource division (Split by) to display each VM as a separate series.
Answer Key and Explanations
Answer Key — Question 1
Answer: B
Platform metrics for VMs are collected by the Azure fabric and cover externally observable aspects, such as Percentage CPU, Disk Read/Write Bytes, and Network In/Out. RAM usage, however, requires visibility inside the guest operating system, something the hypervisor doesn't natively expose as a platform metric. To collect this information, it's necessary to install the Azure Monitor Agent on the VM and associate it with a Data Collection Rule that defines which guest metrics should be collected.
The main error in the distractors is confusing what the hypervisor can observe externally with what depends on internal operating system instrumentation. Choosing alternative A would lead the engineer to look for a metric that simply doesn't exist in the platform scope, causing unperceived observability gaps.
Answer Key — Question 2
Answer: A
The Maximum aggregation instructs Azure Monitor to return the highest sampled value within each granularity interval. With 1-hour granularity, any momentary spike occurring in any second of that interval will be represented as the point value on the chart. This is technically accurate but can be interpreted as "constant high usage" if the observer doesn't understand the aggregation semantics.
Alternative B reverses the logic: granularity doesn't "smooth" data with Maximum aggregation. Alternative C describes behavior that doesn't exist: the Percentage CPU metric measures actual usage of the vCPU allocated to the VM. Alternative D confuses ingestion latency with incorrect data attribution between resources. Understanding the differences between Average, Maximum, Minimum, and Total is fundamental for interpreting charts without analytical distortions.
Answer Key — Question 3
Answer: False
Metrics Explorer allows adding metrics from different resources on the same chart, but the restriction isn't the subscription: resources need to be in the same region and be of the same resource type. Additionally, when using multiple scopes, there are limitations on which combinations are supported. The statement is false because the "same subscription" condition is insufficient as the only criterion: resources of different types or different regions cannot be plotted together directly on the same Metrics Explorer chart. Correct understanding of this limit prevents design errors when building operational dashboards.
Answer Key — Question 4
Answer: B
When the evaluation frequency is less than the metric granularity, Azure Monitor evaluates overlapping time windows. With 5-minute granularity and 1-minute frequency, each evaluation considers a 5-minute window that slides every minute. For a Total aggregation metric, this means the same transactions can be counted in multiple consecutive windows, inflating the evaluated value and triggering false positive alerts.
Alternative A is incorrect because Total is a valid aggregation for counting metrics like Transactions. Alternative C is incorrect because the alert scope was defined directly on the resource. Alternative D describes gap-filling behavior that doesn't apply to the described problem. The practical solution would be to align granularity and frequency, or increase the threshold considering the effective counting window.
Answer Key — Question 5
Answer: D
The most robust and native Metrics Explorer approach for comparing the same metric across multiple resources of the same type is to select a scope that groups them (like the Resource Group or multiple resource selection) and use the Split by resource functionality so each resource appears as a distinct series on the same chart. This is more scalable than alternative B, which is also functionally possible but requires repetitive manual additions and can become impractical with many resources.
Alternative A is incorrect because Metrics Explorer supports multiple resources on the same chart. Alternative C is a valid path for advanced analysis via KQL, but unnecessarily complex for a simple visual comparison that Metrics Explorer solves natively. Recognizing when to use Metrics Explorer versus Log Analytics is an essential operational judgment skill in AZ-104.