Monitor and maintain resources: free practice questions

An Alert Processing Rule with a 'Suppression' action is the correct mechanism for preventing repeat notifications for a period of time after an alert fires. It can be configured to suppress action group notifications for a specified duration (60 minutes in this case) while the underlying alert rule continues to evaluate. Option A is incorrect: changing the evaluation frequency to 60 minutes would reduce how often the query runs, which changes the detection sensitivity — but the question requires the query to continue running every 5 minutes; only notifications should be suppressed. Option C is incorrect: 'Automatically resolve alerts' refers to how long Azure Monitor waits before auto-resolving a fired alert if the condition is no longer met — it does not control notification suppression for repeat firings. Option D is incorrect: the aggregation granularity controls the time window of data evaluated in each query run, not the notification frequency.

Connection monitor is designed for continuous, automated monitoring of network connectivity between sources and destinations, including hybrid scenarios involving on-premises servers (via the Network Watcher agent) and Azure VMs. It provides ongoing latency measurements, packet loss statistics, and integrates with Azure Monitor for alerting when thresholds are breached. IP flow verify is a one-time, on-demand tool that checks whether NSG rules would allow or deny a specific packet — it does not provide continuous monitoring or latency data. Packet capture captures raw traffic for a defined session and is used for deep diagnostics, not continuous connectivity monitoring. Next hop identifies the routing next hop for a given destination from an Azure VM — it is a one-time diagnostic tool and cannot monitor on-premises sources or provide continuous latency measurements.

With the Azure Monitor Agent and a Data Collection Rule in place, guest OS metrics such as 'Available Memory Bytes' are surfaced as custom metrics in Azure Monitor. A metric alert rule can evaluate this metric at 1-minute granularity, making sub-5-minute detection possible, and an action group delivers the email notification. — Option B is wrong because the Heartbeat table only indicates whether the agent is alive; it does not report memory values. — Option C is wrong because the Azure Diagnostics extension is a legacy approach, and 'Percentage CPU' is irrelevant to a memory threshold requirement. — Option D is wrong because the Activity log records control-plane operations (start, stop, resize), not guest OS performance counters like available memory.

An Alert Processing Rule with a 'Suppress notifications' action is specifically designed for this scenario. It can be scoped to specific resources, set to a defined schedule (30-day one-time window), and will suppress action group notifications while leaving alert rules fully active and alert instances still recorded in the Azure Monitor alerts history. This meets all requirements. Option A is incorrect because disabling the alert rules would stop alert evaluation entirely, meaning alerts would not be recorded in the history — this violates the requirement to keep alerts recorded. Option C is incorrect because lowering severity to Informational does not inherently suppress action group notifications; action groups fire based on the alert condition being met, not the severity level (unless action groups are separately filtered by severity). Option D is incorrect because deleting action groups is a destructive action that removes shared configuration potentially used by other alert rules; it is operationally risky and does not suppress notifications gracefully.

Packet Capture (Option A) records actual network packets flowing through a VM's NIC to a storage account or file, making it ideal for forensic traffic analysis. Connection Monitor (Option B) is designed for recurring synthetic connectivity tests — you can configure probes from a VM to an external HTTPS endpoint on a schedule and receive alerts when connectivity degrades. IP Flow Verify (Option C) evaluates NSG rules for a specific 5-tuple (source IP, destination IP, source port, destination port, protocol) and returns whether the traffic is allowed or denied and which rule is responsible. — Option D is wrong: Network Performance Monitor (now part of Connection Monitor) measures latency/packet loss on network paths but does not capture raw packets for forensic use. — Option E is wrong: Traffic Analytics processes NSG Flow Logs to provide aggregate traffic pattern insights across a network, not real-time or scheduled endpoint reachability tests. — Option F is wrong: Next Hop determines the routing path (next hop type and IP) for traffic from a VM, which is used for routing troubleshooting, not NSG rule evaluation.