AZ-400 Implement an instrumentation strategy Practice Question

Answer analysis

Option-by-option breakdown

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

• ✗

  Use metric alerts only for simple threshold-based conditions.

  Why it's wrong here

  Metric alerts are not limited to simple threshold-based conditions; they support multiple conditions on a single or multiple metrics and dynamic thresholds that use machine learning to adapt to historical patterns. Restricting them to only static thresholds overlooks capabilities such as AND/OR logic across dimensions or separate metrics, which can express complex operational requirements without requiring multiple rules. This misconception leads to underutilizing Azure Monitor's flexible signal combination features.

• ✓

  Use dynamic thresholds for metrics with seasonal patterns.

  Why this is correct

  Dynamic thresholds employ machine learning to model historical metric behavior, continuously adjusting the baseline to account for seasonal patterns such as time-of-day, weekly, or yearly fluctuations. This adaptive behavior minimizes false positives during predictable peaks and troughs, while still detecting genuine deviations that deviate from the learned pattern. For metrics with recurring seasonality, dynamic thresholds are the recommended approach because they automatically recalibrate as the baseline shifts, unlike static thresholds that require manual updates.

• ✗

  Create separate alert rules for each condition to avoid complexity.

  Why it's wrong here

  Creating separate alert rules for each condition increases management overhead, duplicates configuration logic, and amplifies alert fatigue because the same underlying issue may trigger multiple notifications. Azure Monitor allows a single metric alert rule to contain multiple conditions combined with AND/OR operators, letting you consolidate related signals and reduce rule sprawl. The best practice is to combine related conditions into an efficient rule that simplifies maintenance and provides a clearer incident picture.

• ✓

  Configure action groups to send notifications and run automated actions.

  Why this is correct

  Action groups are the central component for defining both notifications (email, SMS, push) and automated actions (webhooks, Azure Functions, ITSM integration) that execute when an alert fires. Configuring action groups is a best practice because they are reusable across many alert rules, allowing you to centrally manage notification endpoints, severity schemas, and automation scripts. This decoupling between alert rules and response actions ensures that operational changes, such as rotating a webhook URL or adding a new team email, require updating only the action group rather than every individual alert rule.

• ✗

  Ensure each alert rule uses a unique action group to isolate notifications.

  Why it's wrong here

  Action groups are intentionally designed for reuse across multiple alert rules, enabling centralized administration of notification and automation settings. Requiring a unique action group per rule creates unnecessary duplication, makes compliance and contact-list changes tedious, and increases the risk of inconsistent configuration across the environment. This approach contradicts Azure's recommended pattern, which leverages shared action groups to reduce administrative burden and maintain a single, reliable notification model.

Go deeper

Related to this question