Design identity, governance, and monitoring solutions →hardMultiple Choice

AZ-305 Practice Question: Design identity, governance, and monitoring solutions

Exhibit

Refer to the exhibit.
{
  "type": "Microsoft.Insights/scheduledQueryRules",
  "apiVersion": "2021-08-01",
  "properties": {
    "displayName": "High CPU Alert",
    "severity": 2,
    "enabled": true,
    "scopes": ["/subscriptions/12345/resourceGroups/prod/providers/Microsoft.Compute/virtualMachines/vm1"],
    "evaluationFrequency": "PT5M",
    "windowSize": "PT15M",
    "criteria": {
      "allOf": [
        {
          "query": "Perf | where ObjectName == 'Processor' and CounterName == '% Processor Time' and InstanceName == '_Total' | where CounterValue > 90",
          "timeAggregation": "Count",
          "threshold": 5,
          "operator": "GreaterThan"
        }
      ]
    },
    "actions": {
      "actionGroups": [
        "/subscriptions/12345/resourceGroups/rg-alerts/providers/microsoft.insights/actionGroups/ag-email"
      ]
    }
  }
}

Refer to the exhibit. You deploy this Azure Monitor scheduled query rule to alert when CPU usage exceeds 90% for sustained periods. However, alerts are not firing even when the condition is met. What is the most likely cause?

⚠ Common exam trap

Microsoft often tests the misconception that any sustained high metric value will trigger an alert, ignoring how the 'Count' aggregation and threshold value interact with the number of data points in the evaluation window.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

The threshold of 5 with 'Count' aggregation requires more than 5 data points above 90% in the window, which may not be happening.

The alert rule uses a 'Count' aggregation with a threshold of 5, meaning the alert fires only when the number of data points exceeding 90% CPU within the evaluation window is greater than 5. If the sustained high CPU usage produces fewer than 5 such data points (e.g., due to a short burst or insufficient sampling), the condition is not met, and the alert will not fire. This is a common misconfiguration where the threshold value is set too high relative to the actual data point frequency.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
The KQL query syntax is incorrect and returns no results.
Why it's wrong here
The KQL query is syntactically valid, as confirmed by Azure Log Analytics where it parses without error. If the syntax were incorrect, the alert rule would fail validation with a specific Kusto error and the rule could not be deployed. Since the rule is active and running, the absence of alerts stems from the query's results or threshold, not from a malformed query.
✗
The action group is not configured with a valid email address.
Why it's wrong here
Action group email configuration is unrelated to whether the alert condition fires; a valid email address is only used after the alert trigger. Even with a correctly configured SMTP address, the action group will not be invoked unless the log alert's threshold query returns the required count. Therefore, the lack of email notification points to the alert logic, not the notification channel.
✗
The evaluation frequency is too short compared to the window size.
Why it's wrong here
An evaluation frequency of 5 minutes with a 15-minute window is a valid overlapping configuration commonly used to capture recent data every few minutes. The frequency being shorter than the window size allows the alert to re-evaluate the full window repeatedly, which is expected and does not suppress alerts. The actual problem lies in the alert condition's exclusivity, not in the scheduling parameters.
✓
The threshold of 5 with 'Count' aggregation requires more than 5 data points above 90% in the window, which may not be happening.
Why this is correct
With 'Count' aggregation, the alert fires only if the query returns more than 5 records, where each record corresponds to a data point with CPU usage above 90%. In a 15-minute window with, say, 1-minute metrics, there are 15 possible samples, but not all will necessarily exceed 90%; sustained high CPU is needed. If spikes are brief or stay just below the threshold, the count may remain below 6, leaving the alert silent.

Go deeper

AZ-305 Practice Question: Design identity, governance, and monitoring solutions

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question