This chapter covers the Azure Activity Log and Change History, two critical monitoring tools for auditing and troubleshooting control-plane operations in Azure. For the AZ-104 exam, questions on these topics appear frequently, often integrated with alerts, diagnostics, and policy scenarios — roughly 10-15% of monitoring questions touch Activity Log directly. Mastering these concepts is essential for passing the exam and for real-world administration, as they provide the immutable record of all management operations across your Azure resources.
Jump to a section
Imagine a corporate office building with a high-end security camera system. Every camera is positioned to capture every entrance, hallway, and server room. The system records continuously, but it does not store every second forever — it has a retention policy. The footage is immutable: once a frame is recorded, it cannot be altered. The system is also searchable: you can query by time, camera ID, or event type (motion, door open, etc.). The building's security team uses this footage to investigate incidents, ensure compliance, and audit access. Now, the Azure Activity Log works exactly like this. It records every control-plane operation (management events) across your Azure subscriptions, such as creating a VM, modifying a network security group, or assigning a role. Each event is immutable and stored for 90 days by default. You can query the log using filters like time range, resource group, or operation name. You can also stream the log to a Log Analytics workspace or an event hub for longer retention and advanced analysis. The Activity Log does not capture data-plane operations (like reading from a blob) — that would be like the security cameras not recording conversations in the break room. For those, you need diagnostic settings or resource logs. The analogy holds perfectly: the camera system (Activity Log) gives you a complete, tamper-evident record of who did what, when, and where, across your entire Azure environment.
What is the Azure Activity Log?
The Azure Activity Log is a platform log in Azure that provides insight into subscription-level events. It records all control-plane operations (management operations) that occur on resources in a subscription, including writes (PUT), deletes (DELETE), and actions (POST) performed through Azure Resource Manager (ARM). It also records service health events and resource health events. The Activity Log was formerly known as 'Audit Logs' or 'Operational Logs'.
Why it exists
The Activity Log exists to answer three fundamental questions: Who did what, when, and where? It is the primary source for auditing and compliance in Azure. Without it, administrators would have no way to track changes made to resources, making it impossible to troubleshoot configuration issues, investigate security incidents, or meet regulatory requirements.
How it works internally
Every request to Azure Resource Manager (ARM) goes through a series of steps before it is executed. The Activity Log captures events at multiple stages:
Request received: When a user, application, or service submits a management operation (e.g., creating a VM via the portal, CLI, or SDK), the request is sent to ARM.
Authentication and authorization: ARM validates the caller's identity and checks RBAC permissions. If the operation is allowed, ARM passes the request to the appropriate resource provider (e.g., Microsoft.Compute for VMs).
Operation execution: The resource provider performs the operation and returns a response to ARM.
Log emission: ARM emits an event to the Activity Log. The event includes details such as the caller's identity (user, service principal, or managed identity), the operation name, the resource ID, the timestamp, the HTTP method, the request body (for writes), and the response status.
Events are stored in the Activity Log store, which is a highly available, immutable data store within each Azure subscription. The log is retained for 90 days by default. After that, events are automatically deleted. To retain logs longer, you must export them to a Log Analytics workspace, Azure Storage, or Event Hubs.
Key components, values, defaults, and timers
Retention period: 90 days, non-configurable for the default log. You cannot extend this retention; you must export to other destinations.
Event categories: Admin (management events), Service Health, Resource Health, Alert, Autoscale, Recommendation, Policy.
Operation types: Write (create/update), Delete, Action (e.g., start/stop VM).
Caller types: User (UPN), Service Principal (SPN), Managed Identity, Azure Policy, Azure Automation, etc.
Status: Succeeded, Failed, Started (for async operations), Accepted.
Event ID: A globally unique identifier (GUID) for each event.
Correlation ID: A GUID that groups related events (e.g., a single portal operation may generate multiple ARM calls).
Resource ID: The full ARM resource ID of the resource affected.
Timestamp: UTC time when the operation was initiated.
HTTP method: PUT, POST, DELETE, PATCH.
Request body: The JSON payload sent to ARM (only for writes, truncated if too large).
Response body: The JSON response from ARM (truncated if too large).
Configuration and verification commands
You can view the Activity Log in the Azure portal under Monitor > Activity Log. You can also query it programmatically:
- Azure CLI:
az monitor activity-log list --subscription <subscription-id> --start-time 2023-01-01 --end-time 2023-01-31 --max-events 50- PowerShell:
Get-AzLog -StartTime (Get-Date).AddDays(-7) -EndTime (Get-Date) -MaxRecord 100- REST API:
GET https://management.azure.com/subscriptions/{subscriptionId}/providers/microsoft.insights/eventtypes/management/values?api-version=2015-04-01&$filter=eventTimestamp ge '2023-01-01' and eventTimestamp le '2023-01-31'How it interacts with related technologies
Log Analytics Workspace: You can stream Activity Log events to a Log Analytics workspace using diagnostic settings. This allows you to query logs with KQL (Kusto Query Language), create alerts, and retain data beyond 90 days.
Azure Storage: Archive Activity Log to a storage account for long-term retention (e.g., for compliance). Use lifecycle management to transition to cool/archive tiers.
Event Hubs: Stream Activity Log to an Event Hub for integration with SIEM systems like Splunk or Azure Sentinel.
Azure Monitor Alerts: You can create alert rules that trigger on Activity Log events, such as when a VM is deleted or a security rule is modified.
Azure Policy: Policy evaluation events (e.g., non-compliant resources) are logged in the Activity Log under the Policy category.
Change History
Change History is a feature of the Activity Log that shows what changed during a management operation. When you view an Activity Log event that is a write operation, you can click on the 'Change History' tab to see the before-and-after state of the resource properties. This is powered by Azure Resource Graph (ARG). Change History is only available for resources that support it (most ARM resources). It provides a JSON diff of the resource properties, making it easy to see exactly what was modified.
To access Change History:
- Navigate to Monitor > Activity Log > select an event > Change History tab. - Or use Azure Resource Graph:
resourcechanges
| where subscriptionId == "<subscription-id>"
| where targetResourceId == "<resource-id>"
| project changeTime, properties.changesChange History retains data for 14 days by default (same as the underlying Resource Graph snapshot retention). It is useful for troubleshooting configuration drift and understanding the impact of changes.
Common exam scenarios
Tracking who deleted a resource: Use Activity Log with filter on Resource ID and Operation Name = 'Delete'.
Investigating a role assignment change: Filter by Operation Name = 'Create role assignment' or 'Delete role assignment'.
Monitoring policy violations: Filter by Category = 'Policy'.
Creating an alert when a VM is powered off: Create an Activity Log alert with condition 'Power Off Virtual Machine'.
Exporting logs for compliance: Set up diagnostic settings to export to a storage account with a retention policy.
Important notes
Activity Log does not include read operations (GET) — only writes, deletes, and actions.
Data-plane operations (e.g., reading a blob, executing a SQL query) are NOT logged in Activity Log. Use resource logs (diagnostic settings) for those.
Events are generated globally, but you can filter by region.
The Activity Log is free for the first 90 days. Exporting to other destinations incurs additional costs (data ingestion, storage, event hub).
Initiate a Management Operation
A user or application sends a management request to Azure Resource Manager (ARM). The request can be made through the Azure portal, Azure CLI, PowerShell, SDK, or REST API. For example, a user clicks 'Create VM' in the portal. The portal constructs a PUT request to ARM with the resource properties. The request includes the caller's authentication token (Azure AD token), the HTTP method (PUT for create/update), the resource ID, and the request body (JSON payload). ARM receives the request and begins processing.
Authentication and Authorization
ARM validates the caller's identity using Azure AD. It checks if the token is valid and not expired. Then ARM evaluates RBAC permissions to determine if the caller has the required role (e.g., Contributor) on the resource or resource group. If the caller lacks permissions, the operation fails with a 403 Forbidden status, and an Activity Log event is still created with status 'Failed'. If authorized, ARM proceeds to the next step.
Route Request to Resource Provider
ARM parses the resource provider namespace (e.g., Microsoft.Compute) and the resource type (e.g., virtualMachines). It then routes the request to the appropriate resource provider API endpoint. The resource provider is responsible for managing the specific resource type. For example, Microsoft.Compute handles all VM-related operations. The resource provider validates the request body, checks quotas, and ensures the resource is in a valid state.
Execute the Operation
The resource provider performs the actual operation. For a VM creation, it allocates compute capacity, configures storage, sets up networking, and deploys the VM. This may involve multiple sub-operations (e.g., create network interface, create public IP). The resource provider returns a response to ARM, including the final status (Succeeded or Failed) and the resource properties.
Emit Activity Log Event
ARM receives the response and emits an Activity Log event. The event includes the caller identity, operation name, resource ID, timestamp, status, and additional details. For write operations, the request body and response body are captured (truncated if > 1MB). The event is stored in the Activity Log store with a retention of 90 days. The event is immutable and cannot be modified or deleted. Optionally, if diagnostic settings are configured, the event is also streamed to a Log Analytics workspace, storage account, or event hub.
Enterprise Scenario 1: Security Incident Investigation
A multinational company discovers that a production virtual machine was deleted unexpectedly. The security team needs to identify who performed the deletion, when it happened, and whether any other resources were affected. Using the Azure Activity Log, they filter by resource ID of the deleted VM and set the time range to the last 24 hours. They find an event with Operation Name 'Delete Virtual Machine' and Status 'Succeeded'. The caller is a service principal named 'automation-deploy-prod'. Further investigation reveals that an automated deployment script had a bug that caused it to delete resources in the wrong resource group. The team uses the Change History tab to see the VM properties before deletion, confirming it was the correct VM. They then create an Activity Log alert to notify them of any future deletions of critical resources. In production, they also export all Activity Log events to a Log Analytics workspace for long-term retention and run periodic KQL queries to detect anomalous operations. A common misconfiguration is not setting up diagnostic settings for the Activity Log, resulting in only 90 days of data. For compliance, they archive logs to an Azure Storage account with a retention policy of 7 years.
Enterprise Scenario 2: Compliance Auditing for Role Assignments
A financial services firm must comply with SOX regulations, which require tracking all changes to privileged role assignments. The compliance team uses the Activity Log to monitor 'Create role assignment' and 'Delete role assignment' events. They set up an Activity Log alert that sends an email to the security team whenever a Global Administrator role is assigned. They also stream all Activity Log events to a Log Analytics workspace and create a KQL query that lists all role assignment changes in the last 90 days. One issue they encountered was that the Activity Log captures the caller's identity but not the reason for the change. They solved this by requiring users to include a ticket number in the resource tags, which they then correlate with the Activity Log events. Another challenge is that the Activity Log can generate a high volume of events (thousands per hour in a large subscription). They use filters to exclude routine operations (e.g., autoscale actions) and focus on security-relevant events.
Enterprise Scenario 3: Troubleshooting Configuration Drift
A cloud operations team manages hundreds of Azure resources across multiple subscriptions. They notice that a particular network security group (NSG) keeps getting modified, causing connectivity issues. Using the Activity Log, they filter by the NSG's resource ID and see multiple 'Update Network Security Group' events. The Change History tab shows the exact rule changes (e.g., a new inbound rule allowing SSH from any source). The caller is a junior administrator who was troubleshooting but forgot to revert the changes. The team implements a policy that requires all NSG changes to be approved via a change management system. They also create an Activity Log alert for any modifications to critical NSGs. In production, they use Azure Policy to enforce that all NSG changes must go through a specific pipeline, and they use the Activity Log to audit compliance. A common mistake is assuming that the Activity Log captures all changes; however, if someone modifies a resource directly through the resource provider API (bypassing ARM), the change may not be logged. But in practice, all Azure portal, CLI, PowerShell, and SDK operations go through ARM.
Exactly what AZ-104 tests
AZ-104 objective 5.1 (Monitor resources by using Azure Monitor) includes: - 5.1.1: Interpret metrics and logs in Azure Monitor. - 5.1.2: Configure diagnostic settings for resources and the Activity Log. - 5.1.3: Query the Activity Log using Azure Monitor. - 5.1.4: Create and manage alerts based on Activity Log events. - 5.1.5: Analyze the Activity Log for changes using Change History.
The exam tests your ability to:
Understand what the Activity Log captures (control-plane operations) and what it does not (data-plane operations).
Configure diagnostic settings to export Activity Log to Log Analytics, Storage, or Event Hubs.
Filter and query Activity Log events using Azure portal, CLI, or PowerShell.
Create Activity Log alert rules.
Use Change History to identify specific property changes.
Common wrong answers and why candidates choose them
'Activity Log captures all operations including read operations.' Wrong. Activity Log only captures writes, deletes, and actions (POST). Reads (GET) are not logged. Candidates confuse Activity Log with resource logs (diagnostic settings) which can capture reads for some resources.
'Activity Log is stored indefinitely.' Wrong. Default retention is 90 days. To retain longer, you must export. Candidates often assume Azure retains logs forever, but that is not the case.
'Change History is available for all Activity Log events.' Wrong. Change History is only available for write operations that modify resource properties, and only for resources that support it. Delete events do not have a 'before' state because the resource is gone.
'Activity Log can be used to track data-plane operations like reading a blob.' Wrong. Blob reads are data-plane and are not logged in Activity Log. Use storage analytics logs or diagnostic settings.
Specific numbers, values, and terms on the exam
Retention: 90 days (default, non-configurable).
Event categories: Administrative, Service Health, Resource Health, Alert, Autoscale, Policy, Recommendation.
Operation types: Write, Delete, Action.
Status values: Succeeded, Failed, Started, Accepted.
Change History retention: 14 days (tied to Resource Graph snapshots).
Diagnostic settings destinations: Log Analytics workspace, Storage account, Event Hubs.
Activity Log alert rule: Condition can be based on operation name, resource type, event severity, etc.
Edge cases and exceptions the exam loves
Activity Log events for Azure Service Health: These are logged even if no resource operation occurred. They appear under the 'Service Health' category.
Activity Log events for Azure Policy: When a policy denies a resource creation, the event is logged with status 'Failed' and category 'Policy'.
Activity Log events for autoscale: Autoscale actions (scale-out/scale-in) are logged under 'Autoscale' category.
Activity Log events for resource health: Resource health status changes (e.g., degraded, unavailable) are logged under 'Resource Health'.
Activity Log events for alerts: Alert firings are logged under 'Alert' category.
Exporting Activity Log: You can export to multiple destinations simultaneously. Each destination has separate pricing.
Activity Log for Azure Lighthouse: Events from delegated subscriptions are visible in the managing tenant if the user has appropriate permissions.
How to eliminate wrong answers
If the question mentions 'read' or 'GET', eliminate Activity Log as the answer. It is not logged.
If the question asks about 'retention longer than 90 days', the correct answer involves diagnostic settings exporting to Log Analytics or Storage.
If the question asks about 'before and after state', the answer is Change History (not Activity Log alone).
If the question asks about 'real-time alerts', Activity Log alerts are near real-time (within 5 minutes).
If the question asks about 'who performed a delete', Activity Log caller field provides the identity.
Activity Log captures control-plane operations (write, delete, action) only — not reads.
Default retention is 90 days; use diagnostic settings to export for longer retention.
Change History shows before-and-after state of resource properties for write events.
Activity Log events are immutable and cannot be modified or deleted.
You can create Activity Log alerts to notify on specific events.
Activity Log categories include Administrative, Service Health, Resource Health, Alert, Autoscale, Policy, and Recommendation.
Use Azure Resource Graph (resourcechanges table) to query Change History programmatically.
These come up on the exam all the time. Here's how to tell them apart.
Azure Activity Log
Subscription-level log for control-plane operations (management events).
Captures writes, deletes, and actions (POST) on resources.
Retained for 90 days by default; cannot extend without export.
Free for the first 90 days (no ingestion cost).
Cannot be disabled; always enabled for all subscriptions.
Azure Resource Log (Diagnostic Settings)
Resource-level log for data-plane operations (e.g., app logs, metrics).
Captures reads, writes, and other operations specific to the resource.
Retention configurable per destination (Log Analytics, Storage, Event Hubs).
Costs associated with data ingestion and storage.
Must be enabled per resource via diagnostic settings.
Mistake
The Activity Log captures all API calls, including read operations.
Correct
Activity Log only captures control-plane operations that modify resources (write, delete, action). Read operations (GET) are not logged. For data-plane reads, you need resource-level diagnostic settings.
Mistake
Activity Log events are stored indefinitely by default.
Correct
Activity Log events are retained for 90 days by default. After that, they are automatically deleted. To retain longer, you must configure diagnostic settings to export to a Log Analytics workspace, storage account, or event hubs.
Mistake
Change History is available for every Activity Log event.
Correct
Change History is only available for write operations that modify resource properties. Delete events do not have a 'before' state because the resource is removed. Additionally, not all resource types support Change History.
Mistake
You cannot create alerts based on Activity Log events.
Correct
You can create Activity Log alert rules that trigger when specific events occur, such as when a VM is deleted or a role assignment is created. Alerts can send notifications (email, SMS) or trigger action groups.
Mistake
Activity Log is only accessible through the Azure portal.
Correct
Activity Log can be accessed via Azure portal, Azure CLI, PowerShell, REST API, and through Log Analytics (if exported). You can also stream it to Event Hubs for third-party integration.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Activity Log events are retained for 90 days by default. After 90 days, they are automatically deleted. You cannot extend this retention within the Activity Log itself. To retain logs longer, you must configure diagnostic settings to export the Activity Log to a Log Analytics workspace (up to 2 years for interactive retention, or longer with archive), an Azure Storage account (unlimited retention with lifecycle management), or Event Hubs (for real-time streaming to SIEM). For exam purposes, remember the 90-day default.
Activity Log is subscription-level and captures control-plane operations (management events) like creating a VM or assigning a role. Resource logs (diagnostic settings) are resource-level and capture data-plane operations, such as application logs, security logs, or performance metrics. For example, reading a blob from a storage account is a data-plane operation logged via diagnostic settings, not Activity Log. The Activity Log is always on and free for 90 days; resource logs must be enabled per resource and incur costs.
No, Activity Log events are immutable. Once an event is written, it cannot be modified or deleted by any user, including Global Administrators. This ensures an audit trail that cannot be tampered with. However, if you export the Activity Log to a storage account, you can manage the exported data (e.g., delete old blobs) but the original events in the Activity Log store remain intact until the 90-day retention expires.
To create an alert when a resource is deleted, go to Azure Monitor > Alerts > Create > Alert rule. Set the scope to the subscription or resource group. Under Condition, select 'Activity Log' as the signal type. Then configure the condition: Operation Name = 'Delete Virtual Machine' (or relevant operation), Resource Type = 'Microsoft.Compute/virtualMachines', Status = 'Succeeded'. You can also specify the resource name. Then define an action group (e.g., email, SMS) and save the alert rule. The alert triggers within minutes of the deletion.
Change History is a feature that shows the before-and-after state of resource properties for write operations logged in the Activity Log. To use it, open an Activity Log event that is a write operation (e.g., 'Update Virtual Machine'), then click the 'Change History' tab. You will see a JSON diff showing the properties that changed. Change History is powered by Azure Resource Graph and retains data for 14 days. It is useful for troubleshooting configuration changes and understanding what exactly was modified.
Yes, Azure Policy evaluation events are captured in the Activity Log under the 'Policy' category. For example, if a policy denies the creation of a resource, the Activity Log will show an event with status 'Failed' and the policy details. Additionally, when a policy evaluates resources for compliance, it logs events. You can filter by Category = 'Policy' to see all policy-related events.
Yes, you can configure multiple diagnostic settings for the Activity Log, each with a different destination. For example, you can stream to a Log Analytics workspace for querying and alerting, and also archive to a storage account for long-term compliance. You can also send to an Event Hub for real-time integration. Each destination has its own pricing and retention settings.
You've just covered Activity Log and Change History — now see how well it sticks with free AZ-104 practice questions. Full explanations included, no account needed.
Done with this chapter?