MICROSOFT AZ-104 STUDY TOPIC

Azure Activity Log vs resource logs: connect telemetry, diagnostic settings and alerts.

Azure Monitor questions become easier when you separate the signal Azure already collects, the data you must route, the query you use to investigate, and the rule that notifies or automates a response.

Updated 18 August 2026 · Original ITCertPath learning resource

Use four questions to design Azure monitoring

What happened to the Azure resource configuration? Start with the Activity Log. It records control-plane operations such as creating a virtual machine, changing access configuration, deleting a resource or receiving an Azure Resource Manager deployment error.

What happened inside the service? Use resource logs when the Azure service exposes the required category. Key Vault secret access, firewall flows or database operations are data-plane or service-specific events, not ordinary resource-management changes.

How is the resource performing right now? Use platform metrics for numerical time-series values such as CPU, request rate, latency or capacity. Azure collects platform metrics automatically, although the available signals vary by resource type.

Who should act when a condition is met? An alert rule evaluates a signal and an action group defines the notification or automated response. Diagnostic settings route data; they do not themselves evaluate a threshold or notify an operator.

Fast AZ-104 rule

Control-plane change → Activity Log. Service operation → resource log. Numerical threshold → metric alert. KQL-based condition → log search alert. Route telemetry → diagnostic setting. Notify or automate → action group.

Activity Log vs resource logs vs metrics

SignalWhat it answersCollection behavior
Activity LogWho changed, deleted, deployed or acted on an Azure resource?Collected automatically at subscription/control-plane scope; currently retained for 90 days
Resource logsWhat happened inside a particular Azure service?Not collected by default; enable categories through a diagnostic setting
Platform metricsHow did a numerical resource signal change over time?Collected automatically; use a diagnostic setting only when routing to another destination
Guest OS dataWhat happened inside the VM operating system or application?Requires the appropriate agent, data collection rule or application instrumentation
Service or Resource HealthIs Azure reporting a service incident or a resource availability event?Use the relevant health experience and Activity Log alert type

The Activity Log normally records create, update, delete and action events rather than routine read operations. If a Key Vault resource was reconfigured, inspect the Activity Log. If an application retrieved a secret, inspect the appropriate Key Vault resource-log category after diagnostic collection has been enabled.

Metrics are designed for efficient numerical analysis and alerting. Logs contain richer records and dimensions that can be queried with Kusto Query Language (KQL). Choose logs when the condition requires filtering, parsing, joining or aggregating records that a simple metric does not express.

Diagnostic settings are telemetry routing rules

A diagnostic setting selects supported logs and metrics from a source and sends them to one or more destinations. Create it at the resource scope for resource logs or at subscription scope to export the Activity Log. Each Azure resource type exposes its own categories, so never assume that a category available on one service exists on another.

LOG ANALYTICS

Query and alert

Use KQL, workbooks and log search alerts. Choose this destination when operators need investigation, correlation and proactive conditions across collected telemetry.

STORAGE ACCOUNT

Archive and retain

Use for audit, long-term retention or static analysis. Retention and immutability requirements belong in the storage design.

EVENT HUBS

Stream externally

Send telemetry to external SIEM, observability or processing systems. Validate authorization, region and network requirements.

PARTNER SOLUTION

Use supported integration

Route data to a supported Azure Monitor partner when the organization uses another monitoring platform.

A resource can currently have up to five diagnostic settings, and one setting can define no more than one destination of each type. To send the same resource's logs to two Log Analytics workspaces, create separate settings. The destination must already exist, and regional destination constraints can apply to Storage and Event Hubs.

Azure resource→ categories →Diagnostic setting→ route →Workspace, Storage or Event Hubs

Diagnostic settings do not copy historical events that occurred before collection was enabled. After configuration, allow for ingestion latency and verify that new test events arrive in the expected table or destination.

Choose the alert from the signal and condition

An alert rule identifies the resource scope, signal, condition and evaluation behavior. When the condition is met, Azure creates a fired alert and invokes associated action groups. The action group is reusable across alert rules and can notify people or trigger supported automation.

Alert typeUse whenExample
Metric alertA numerical time-series signal crosses a thresholdAverage VM CPU is above 85% for 10 minutes
Log search alertA KQL query produces a result that meets a conditionMore than five failed administrative operations appear in collected logs
Activity Log alertA matching control-plane or health event occursA production network security group is deleted
Resource Health alertAzure reports an availability change for selected resourcesA VM becomes unavailable because of an Azure platform event
Service Health alertAn Azure service issue, maintenance event or advisory affects selected subscriptions or regionsA regional Azure incident affects a service your workload uses

An alert processing rule changes how fired alerts are handled—for example, suppressing notifications during planned maintenance or adding another action group for a defined scope and schedule. It does not replace the alert rule that detects the condition.

Action groups can send email, SMS, push or voice notifications and invoke mechanisms such as webhooks, Functions, Logic Apps, runbooks, ITSM or Event Hubs. Multiple alert rules can reuse the same group. Test the action group and verify the recipient or endpoint instead of assuming a saved configuration delivers successfully.

Scenario 1: alert when a production NSG is deleted

The required signal is a control-plane delete operation. Create an Activity Log alert scoped to the correct subscription or resource and filter for the relevant resource type, operation and status. Attach an action group that reaches the responsible team. A VM CPU metric and a resource-log diagnostic setting would not detect this management event.

Correct reasoning

The event already exists in the Activity Log. The alert rule matches the event, and the action group controls the response. Export the Activity Log only if longer retention or cross-data querying is also required.

Scenario 2: investigate who retrieved a Key Vault secret

Secret retrieval is a data-plane operation. Enable the appropriate Key Vault resource-log category in a diagnostic setting and send it to Log Analytics or the organization's required destination. Generate a safe test event, wait for ingestion, then query the resource-specific or legacy table used by the selected collection mode.

Correct reasoning

The Activity Log can show changes to the vault resource, but it is not the audit trail for routine secret retrieval. Resource logs must be collected before the operation can be investigated later.

Scenario 3: notify only when repeated failures occur

When the failure records are in Log Analytics and the condition requires counting or filtering within a time window, create a log search alert based on a tested KQL query. Use dimensions or resource identifiers carefully so alerts have useful scope, then connect the correct action group.

These are original learning scenarios, not customer incidents or recalled Microsoft exam questions.

Production-style failure: the diagnostic setting exists but no logs appear

  1. Confirm the source and scope. A resource-level setting does not export the subscription Activity Log, and a setting on one resource does not collect another resource's logs.
  2. Check the selected categories. Verify the exact resource-log category or category group is enabled. AllMetrics does not mean all logs.
  3. Generate a new event. Diagnostic settings do not backfill earlier resource logs. Produce a safe test event after the setting is active.
  4. Allow for ingestion latency. Query a wide enough time range and use UTC timestamps when comparing events.
  5. Check the destination. Confirm the workspace, Storage account or Event Hubs namespace exists and the setting points to the intended identifier.
  6. Check network and regional constraints. Storage and Event Hubs destinations can require trusted Microsoft services firewall bypass and compatible regional placement.
  7. Find the correct table. Resource-specific collection and legacy AzureDiagnostics mode can place records in different tables.

Production-style failure: the alert fired but nobody was notified

  1. Open the fired alert and verify the alert condition, resource, time and associated action group.
  2. Distinguish system condition from user response; acknowledging an alert does not change whether its underlying condition remains fired.
  3. Check whether an alert processing rule suppressed or replaced action groups for that scope and schedule.
  4. Use the action-group test feature and verify email confirmation, SMS support, webhook responses or automation permissions.
  5. Check the common alert schema expected by the receiver and ensure the endpoint accepts the action's request type.
  6. Review rate limits, recipient filtering and downstream workflow logs before changing the alert condition.

Common AZ-104 exam mistakes

  • Using the Activity Log to find routine data-plane operations inside a service.
  • Assuming resource logs are stored automatically without a diagnostic setting.
  • Creating a diagnostic setting when the requirement is to notify an operator.
  • Sending metrics to Log Analytics when a native metric alert already expresses the required threshold.
  • Using a metric alert for a condition that requires KQL filtering or joins.
  • Confusing an alert rule, an action group and an alert processing rule.
  • Assuming an action group runs its actions in a guaranteed sequence.
  • Expecting diagnostic settings to backfill events from before configuration.
  • Creating a resource-level diagnostic setting when the requirement is to export the subscription Activity Log.
  • Ignoring category selection, destination firewalls, ingestion latency and table choice when logs appear missing.

Frequently asked questions

What is the difference between the Azure Activity Log and resource logs?

The Activity Log records subscription-level control-plane events such as creating, updating or deleting Azure resources. Resource logs describe data-plane or service-specific operations inside a resource. Activity Log events are collected automatically; resource logs require a diagnostic setting before they are collected.

Do diagnostic settings create alerts?

No. A diagnostic setting selects telemetry categories and routes data to destinations such as Log Analytics, Storage or Event Hubs. An alert rule separately evaluates a metric, log query or Activity Log signal and can invoke an action group when its condition is met.

When should I use a metric alert instead of a log search alert?

Use a metric alert for a numeric time-series signal such as CPU percentage, request count or available storage when the platform exposes the metric. Use a log search alert when the condition needs a KQL query, joins, filtering or aggregation over data stored in Log Analytics.

What is an Azure Monitor action group?

An action group is a reusable collection of notification and automation actions. It can send email, SMS, push or voice notifications and can invoke supported workflows such as webhooks, functions, Logic Apps or runbooks when an alert fires.

How long is the Azure Activity Log retained by default?

Microsoft currently retains Activity Log events for 90 days. To keep them longer or query them with other data, create a subscription-level diagnostic setting and route the required categories to a suitable destination.

Official Microsoft references

Confirm current behavior in Microsoft Learn: the AZ-104 study guide, Activity Log overview, diagnostic settings, Azure Monitor alerts and action groups.