Skip to main content

Technical Lab: Set up alert rules, action groups, and alert processing rules in Azure Monitor

Questions​

Question 1 — Multiple Choice​

You need to create an alert rule in Azure Monitor that triggers only when the CPU utilization of a specific virtual machine exceeds 85% for at least 5 consecutive minutes. When configuring the rule, you notice there are two distinct fields: Threshold and Aggregation granularity (Period).

What is the correct role of the Aggregation granularity (Period) field in this scenario?

A. Defines the percentage value that the metric must reach for the alert to be triggered.

B. Defines the time interval over which data points are aggregated before being compared to the threshold.

C. Defines the frequency with which Azure Monitor checks if the alert condition has been violated.

D. Defines how long the alert remains in the Fired state before being automatically resolved.

Question 2 — Technical Scenario​

An operations team configured the following alert rule in Azure Monitor:

Resource:      Virtual Machine — vm-prod-01
Metric:        Percentage CPU
Condition:     Greater than 90%
Aggregation:   Average
Period:        5 minutes
Frequency:     1 minute
Severity:      Sev 1
Action Group:  ag-ops-critical

During a real incident, the CPU of vm-prod-01 remained above 90% for 12 minutes. The team received only one notification, but expected to receive multiple. What is the correct explanation for this behavior?

A. The action group ag-ops-critical only allows sending one notification per hour by design.

B. The evaluation frequency of 1 minute prevents multiple triggers while the condition remains active.

C. While the alert remains in the Fired state, it does not trigger again until it is resolved and the condition is violated again.

D. The Percentage CPU metric has a native restriction that suppresses duplicate notifications in windows shorter than 15 minutes.

Question 3 — True or False​

An action group can be associated with alert rules of different types, such as metric alerts, log alerts, and service health alerts, without needing to create a separate action group for each type.

True or False?

Question 4 — Technical Scenario​

The security team requires that during scheduled maintenance periods (every Sunday between 02:00 and 06:00 UTC), no alert notifications are sent to communication channels, but alerts should continue to be evaluated and logged in the Azure Monitor history.

Which Azure Monitor feature should be used to meet this requirement?

A. Temporarily disable alert rules before the maintenance window and re-enable them after completion.

B. Configure an alert processing rule of type Suppress notifications with a recurring schedule for the defined period.

C. Remove the action group from alert rules during the maintenance period and reassign it afterwards.

D. Configure the action group to include a silence period directly in the properties of each notification channel.

Question 5 — Multiple Choice​

You are designing an incident response system and need to ensure that when a Sev 0 alert is triggered, the following actions occur automatically:

  • Send email to the on-call list
  • Create a ServiceNow ticket via webhook
  • Execute a remediation runbook in Azure Automation

What is the correct approach to configure this in a single action group?

A. Create three separate action groups, one for each type of action, and associate all of them to the alert rule.

B. Create a single action group containing three distinct action types: Email/SMS/Push/Voice, Webhook, and Automation Runbook.

C. Create a single action group with a Logic App action type, which internally orchestrates the email, webhook, and runbook.

D. Add three identical alert rules, each with a single-action action group, to ensure parallel execution.

Answer Key and Explanations​

Answer Key — Question 1​

Answer: B

The Aggregation granularity (Period) field defines the time window used to aggregate collected data points before comparing the result to the threshold. In the described scenario, CPU data collected over 5 minutes is aggregated by the chosen function (average, maximum, etc.) and the resulting value is then compared to the 85% limit.

The main misconception represented by the distractors is confusing this field with the Evaluation frequency field (alternative C), which controls how often Azure Monitor performs the condition check, and with the threshold itself (alternative A). Alternative D describes alert state behavior, which is a property independent of the aggregation window.

Choosing incorrectly here leads to configuring inadequate windows: a window that's too short may generate false positives from momentary spikes, while a window that's too long may delay detection of real problems.

Answer Key — Question 2​

Answer: C

Azure Monitor implements the concept of stateful alerts for metric alerts. When an alert rule enters the Fired state, it remains in that state while the violating condition persists. A new trigger and a new notification only occur after the alert returns to the Resolved state and the condition is violated again.

This behavior is intentional to prevent notification storms, i.e., the massive sending of repeated notifications during a single continuous incident.

Alternative B represents a common misconception: the evaluation frequency only defines how regularly the condition is checked, not how many notifications are sent. Alternatives A and D describe fictitious restrictions that don't exist in the platform.

Answer Key — Question 3​

Answer: True

An action group is an independent and reusable resource in Azure Monitor. It can be associated with any type of alert rule supported by the platform, including metric alerts, log-based alerts (Log Analytics), Activity Log alerts, and Azure Service Health alerts.

This design promotes reuse and operational consistency: the team maintains a centralized set of action groups and associates them with multiple alert rules of different types, without configuration duplication.

The opposite misconception, believing that each alert type requires its own action group, would lead to unnecessary resource proliferation and increase the likelihood of inconsistencies in incident response.

Answer Key — Question 4​

Answer: B

Alert processing rules (formerly called action rules) are the correct mechanism to suppress notifications without interfering with the alert rules' lifecycle. By configuring an alert processing rule of type Suppress notifications with a recurring schedule, alerts continue to be evaluated and logged in the history, but actions associated with action groups are blocked during the defined window.

Alternatives A and C superficially meet the silence requirement but introduce operational risks: manually disabling rules or unlinking action groups requires human intervention, is susceptible to errors, and may result in unrecorded alerts or failure to restore the original configuration.

Alternative D is incorrect because action groups don't have native silence time configuration per channel. This control belongs to the alert processing rules layer.

Answer Key — Question 5​

Answer: B

A single action group supports multiple action types configured simultaneously. In the described scenario, the three requirements map directly to available native types: Email/SMS/Push/Voice for notification to the on-call list, Webhook for ServiceNow integration, and Automation Runbook for runbook execution.

All action types configured in an action group are executed in parallel when the alert is triggered, making any of the approaches in alternatives A and D unnecessary.

Alternative C is plausible in complex orchestration scenarios but adds an unnecessary layer of indirection when native types already cover the requirements. Additionally, it concentrates logic in an external Logic App, increasing dependency and operational complexity without justifiable technical benefit in this context.