Application Change Analysis is a feature of Azure Monitor that provides a detailed view of changes to your Azure resources and applications. It is essential for troubleshooting unexpected behavior, identifying the root cause of incidents, and auditing configuration drift. On the AZ-104 exam, this topic typically appears in 5-10% of questions within the 'Monitor' domain (objective 5.4). This chapter covers the architecture, configuration, and practical usage of Change Analysis, including how to interpret change diffs, integrate with Azure Resource Graph, and use it alongside other monitoring tools like Activity Log and Resource Health.
Jump to a section
Imagine a corporate office with a central security camera system that records every single change made to the building: who entered a room, what they moved, and when. But instead of just saving raw video, the system automatically compares each new frame to the previous one and highlights only the differences—like a Git diff for the physical world. Application Change Analysis works similarly: it captures snapshots of your Azure resources (like VM configurations, network security groups, or App Service settings) and compares them over time. When you deploy a new version of an app, Azure automatically takes a 'before' snapshot of the resource properties, then an 'after' snapshot after the deployment completes. It computes a JSON diff showing exactly which properties changed, their old values, and new values. This is stored in a change analysis resource under the resource group. You can review this diff in the portal or via Azure CLI. The mechanism is powered by the Azure Resource Graph and change tracking APIs that poll resource providers every 5 minutes for configuration changes. It doesn't rely on logs or metrics—it directly queries the current state of each resource via the Azure Resource Manager. The 'snapshot' is essentially a full JSON representation of the resource at that point in time, and the diff is computed server-side using a property-level comparison algorithm. This gives you a precise, auditable record of what changed, even if the change originated from Azure Policy, a manual portal click, or an automated deployment pipeline.
What is Application Change Analysis?
Application Change Analysis is a feature within Azure Monitor that detects and displays changes to your Azure resources. It focuses on configuration changes—modifications to resource properties, settings, and tags—rather than runtime performance or availability. The feature is designed to help you answer the question: 'What changed in my Azure environment that might have caused this problem?'
Change Analysis works by taking periodic snapshots of your resources' configurations and comparing them over time. It is built on top of the Azure Resource Graph (ARG) and the Azure Resource Manager (ARM) APIs. The service is enabled automatically for all Azure subscriptions and requires no agent installation or additional configuration for basic functionality. However, to capture changes to web app code (like file changes or environment variable updates), you need to enable the Change Analysis agent for App Services.
How It Works Internally
Change Analysis operates through a combination of polling and event-driven triggers. The core mechanism is as follows:
- Snapshot Capture: Every 5 minutes, the Change Analysis service queries the Azure Resource Manager for the full configuration of each resource in your subscription. This is done via the Resource Graph API, which returns a JSON representation of the resource's properties.
- Diff Computation: Each new snapshot is compared against the previous snapshot for the same resource. The comparison is done property-by-property, generating a diff that shows added, removed, or modified fields. The diff is stored in a hidden resource group named azure-changes-rg (or similar) within your subscription.
- Change Detection Triggers: In addition to periodic polling, Change Analysis also reacts to Azure Resource Manager events (e.g., Microsoft.Resources/deployments/write). When a deployment completes, an immediate snapshot is taken, ensuring that changes from deployments are captured quickly.
- Data Retention: Change data is retained for 30 days by default. You can extend this up to 90 days by configuring the diagnostic settings for the Change Analysis resource.
Key Components and Defaults
- Change Analysis Resource: Each region has a hidden resource of type Microsoft.ChangeAnalysis/changes that stores the change data. You can view it in the portal by navigating to Azure Monitor > Change Analysis.
- Resource Types Covered: All Azure resource types that support Azure Resource Manager are covered, including VMs, storage accounts, network security groups, Azure SQL databases, App Services, and more. Changes to resource tags are also tracked.
- Change Categories: The service categorizes changes into three types:
- Configuration Changes: Modifications to resource properties (e.g., VM size, NSG rule).
- Deployment Changes: New or updated deployments (e.g., ARM template, Terraform).
- Policy Changes: Azure Policy assignments that affect the resource.
- Time Range: You can query changes for the last 30 days (90 with extended retention).
- Integration with Azure Monitor: Change Analysis results appear alongside metrics and logs in the Azure Monitor overview blade for a resource.
Configuration and Verification Commands
To view changes via Azure CLI:
az change-analysis list --resource-id /subscriptions/{subscriptionId}/resourceGroups/{rgName}/providers/Microsoft.Compute/virtualMachines/{vmName}This returns a list of changes with timestamps, old and new values.
To list all changes in a subscription:
az change-analysis list --scope /subscriptions/{subscriptionId}To configure diagnostic settings for Change Analysis (to send data to Log Analytics or Storage):
az monitor diagnostic-settings create --resource /subscriptions/{subId}/resourceGroups/{rgName}/providers/Microsoft.ChangeAnalysis/changes/{changeResourceName} --name "changeAnalysisDiag" --logs '[{"category": "Change", "enabled": true}]' --workspace {workspaceId}In the portal, you can view changes by navigating to the resource's 'Change Analysis' blade under 'Monitoring'.
Interaction with Related Technologies
Azure Resource Graph: Change Analysis uses ARG to query resource configurations. You can also use ARG directly to detect changes by comparing snapshots manually, but Change Analysis automates this.
Azure Activity Log: While Activity Log records management events (e.g., who created a VM), Change Analysis shows the resulting configuration changes. For example, Activity Log might show a 'Write' operation on an NSG, while Change Analysis shows that a specific rule was added.
Azure Policy: Policy changes are tracked separately. If a policy modifies a resource (e.g., adding a tag), Change Analysis captures the resulting configuration change, but the policy assignment change itself appears as a 'Policy Change' category.
Application Insights: For web apps, Change Analysis can be enabled via the Application Insights agent to track code-level changes (file modifications, environment variables). This is an opt-in feature.
Advanced Scenario: Web App Change Analysis
For Azure App Services, you can enable Change Analysis to track changes to your application code and configuration. This requires installing the Change Analysis agent as a site extension or using the Application Insights agent. Once enabled, you can see changes to:
Environment variables
Connection strings
Application settings
Files (e.g., web.config, appsettings.json)
Startup commands
This is especially useful for diagnosing issues after a deployment that didn't go through a proper release pipeline.
Performance and Scale Considerations
Change Analysis is designed to handle large-scale environments. The polling interval of 5 minutes means that changes may take up to 5 minutes to appear. For deployments, the immediate trigger ensures near-real-time detection. The service is throttled per subscription to prevent excessive API calls, but for practical purposes, it scales well up to thousands of resources. The hidden resource group (azure-changes-rg) can grow in size; you should not modify or delete it manually.
Common Misconfigurations
Enabling for App Services without the agent: You must install the site extension for code-level changes; otherwise, only ARM-level changes (e.g., scaling) are tracked.
Assuming real-time updates: The 5-minute polling delay means you may not see a change immediately. For critical changes, use Azure Event Grid or Activity Log alerts.
Deleting the hidden resource group: This will break Change Analysis for that subscription. Re-enabling may require a support ticket.
Summary of Internal Mechanism
At its core, Application Change Analysis is a state-comparison engine. It uses the Azure Resource Manager's ability to return the full configuration of any resource as a JSON document. By storing these documents over time and computing diffs, it provides a clear, auditable record of configuration changes. The service is integrated into Azure Monitor, making it accessible from the resource's monitoring blade. It does not require any changes to your resources or deployment processes—it works out-of-the-box for all ARM-managed resources.
Enable Change Analysis for Subscriptions
Change Analysis is enabled by default for all Azure subscriptions. There is no explicit activation step. However, for App Services, you must manually enable the Change Analysis agent. To do this, go to your App Service in the portal, select 'Change Analysis' under 'Monitoring', and click 'Enable'. This installs a site extension that monitors file and configuration changes. Alternatively, you can enable it via the App Service's 'Application Settings' blade by adding the app setting `CHANGE_ANALYSIS_ENABLED = 1`. Once enabled, the agent starts polling every 5 minutes and sends data to the Change Analysis service.
Initiate a Change (e.g., Deploy or Modify Resource)
When you make a change to an Azure resource—such as resizing a VM, adding an NSG rule, or deploying an ARM template—the Azure Resource Manager processes the request. For ARM-based changes, the Resource Manager logs the operation in the Activity Log and triggers an immediate snapshot for Change Analysis. For changes made directly via the portal, CLI, or SDK, the same mechanism applies. The snapshot captures the full resource configuration at that moment. For App Service code changes (e.g., uploading a new file via FTP), the Change Analysis agent detects the file modification and sends a notification to the service, which then takes a snapshot.
Snapshot and Diff Computation
The Change Analysis service compares the new snapshot with the previous snapshot for the same resource. The comparison is done property-by-property, using a JSON diff algorithm. For each property that changed, the service records the old value, new value, and the timestamp. The diff is stored in the hidden resource group as a change record. The service also categorizes the change: 'Configuration', 'Deployment', or 'Policy'. For example, if you add a tag, the diff shows the tag key-value pair as added. If you change a VM size, the diff shows the `hardwareProfile.vmSize` property changed from 'Standard_DS2_v2' to 'Standard_DS3_v2'.
View Changes in Azure Portal
Navigate to the resource you want to investigate. Under the 'Monitoring' section, select 'Change Analysis'. The blade shows a timeline of changes for that resource. You can filter by time range (up to 30 days) and change type. Each change entry shows the timestamp, the user or service principal that initiated the change (if available from Activity Log), and a summary of what changed. Clicking on a change expands the diff view, showing the old and new values in a side-by-side JSON format. You can also view changes at the subscription level by going to Azure Monitor > Change Analysis.
Query Changes via Azure CLI or API
For programmatic access, use the Azure CLI command `az change-analysis list` with the resource ID or subscription scope. The output is a JSON array of change objects. Each object contains properties like `resourceId`, `time`, `changeType` (e.g., 'Update'), `propertyChanges` (array of changed properties with `propertyName`, `oldValue`, `newValue`). You can also use the Azure REST API: `GET https://management.azure.com/{resourceId}/providers/Microsoft.ChangeAnalysis/changes?api-version=2021-04-01`. This is useful for integrating with automation or reporting tools. The CLI command supports `--start-time` and `--end-time` parameters to filter by time.
Enterprise Scenario 1: Post-Deployment Incident Investigation
A financial services company deploys updates to their payment processing web app using Azure DevOps pipelines. After a deployment, customers report transaction errors. The operations team uses Change Analysis to compare the web app's configuration before and after the deployment. They discover that a deployment script inadvertently changed the WEBSITE_NODE_DEFAULT_VERSION environment variable from '10.14.1' to '12.0.0', which caused a compatibility issue. Without Change Analysis, they might have spent hours checking logs. In production, they have Change Analysis enabled for all App Services and have set up diagnostic settings to export change data to a Log Analytics workspace for long-term retention and correlation with other logs. They also have alert rules that trigger when certain sensitive properties (like connection strings) change.
Enterprise Scenario 2: Auditing Compliance Changes
A healthcare organization must maintain compliance with HIPAA, which requires tracking all configuration changes to protected health information (PHI) systems. They use Azure Policy to enforce tagging and encryption standards. Change Analysis helps them audit whether policy violations were fixed or if unauthorized changes occurred. For example, a storage account containing medical records had its 'public network access' setting changed from 'Disabled' to 'Enabled'. Change Analysis showed the change occurred at 3:00 AM and was initiated by a service principal that was later found to be compromised. They now have a weekly report generated via Azure CLI script that queries Change Analysis for all resources in the subscription, filtering for changes to security-related properties (e.g., network rules, encryption settings).
Scenario 3: Troubleshooting Performance Degradation
A SaaS provider runs a multi-tier application on Azure VMs and App Services. After a routine maintenance window, they notice increased latency. Using Change Analysis, they see that a Virtual Machine Scale Set's instance count was reduced from 10 to 5 due to an autoscale rule change. The change was made by an administrator who mistakenly modified the scale-in policy. The team reverts the change and adds a lock on the autoscale settings to prevent accidental modifications. They also set up Change Analysis alerts via Azure Monitor to notify them of any changes to autoscale configurations. The key lesson: Change Analysis is not just for security—it's a first-line diagnostic tool for performance issues.
What AZ-104 Tests on Application Change Analysis
Objective 5.4: 'Monitor and troubleshoot Azure resources by using Azure Monitor, including Application Change Analysis.' The exam expects you to know:
The purpose of Change Analysis: detecting configuration changes that may affect application behavior.
How to enable Change Analysis for App Services (via site extension or application setting).
The difference between Change Analysis and Activity Log: Change Analysis shows the resulting configuration change, while Activity Log shows the management operation.
The default retention period (30 days) and how to extend it (90 days via diagnostic settings).
The polling interval (5 minutes) and the immediate trigger for deployments.
That Change Analysis is enabled by default for all ARM resources.
Common Wrong Answers and Traps
Confusing Change Analysis with Activity Log: A typical question asks, 'Which tool shows the specific configuration change that occurred after a deployment?' The wrong answer might be 'Activity Log' because it records deployments. But Activity Log shows the operation (e.g., 'Write Deployment'), not the resulting property changes. Change Analysis shows the diff. Candidates pick Activity Log because it's more familiar.
Assuming Change Analysis requires agents: Many candidates think an agent is needed for all resources. In reality, only App Services require an agent for code-level changes; ARM resources are tracked automatically.
Mistaking retention period: Some questions ask about data retention. The default is 30 days, not 90. The 90-day option requires additional configuration (diagnostic settings).
Believing Change Analysis is real-time: The 5-minute polling interval means changes may not appear immediately. Candidates may expect instant updates and choose 'real-time' answers, which are incorrect.
Specific Numbers and Terms on the Exam
30 days: Default retention.
5 minutes: Polling interval.
Hidden resource group name: azure-changes-rg (or similar, but you don't need to memorize exactly; just know it's hidden).
Change types: Configuration, Deployment, Policy.
Resource type for App Service agent: Site extension 'Change Analysis' or app setting CHANGE_ANALYSIS_ENABLED = 1.
Edge Cases and Exceptions
Changes made via Azure Policy: These appear as 'Policy Change' category. The policy assignment change itself is tracked, but the resulting resource modifications are also captured as configuration changes.
Deleted resources: Change Analysis retains data for deleted resources for 30 days after deletion, so you can still view changes that occurred before deletion.
Cross-subscription changes: Change Analysis only tracks changes within the same subscription. It does not aggregate across subscriptions.
How to Eliminate Wrong Answers
When you see a question about detecting configuration changes, ask: 'Does the tool show the before and after state of the resource?' If yes, it's Change Analysis. If it shows who did what operation, it's Activity Log. If it shows performance metrics, it's Metrics Explorer. Also, remember that Change Analysis is part of Azure Monitor, not a standalone service. If an answer says 'Requires enabling per resource', that's false for ARM resources (it's automatic), but true for App Services code changes.
Application Change Analysis is enabled by default for all Azure subscriptions and requires no agent for ARM resources.
It captures configuration changes every 5 minutes and immediately after deployments.
Default retention is 30 days; extend to 90 days by exporting to Log Analytics or storage via diagnostic settings.
Change Analysis shows the before and after values of changed properties (JSON diff).
For App Services, enable the Change Analysis site extension or set app setting `CHANGE_ANALYSIS_ENABLED = 1` to track code-level changes.
Change Analysis is complementary to Activity Log: Activity Log shows the operation, Change Analysis shows the resulting configuration difference.
Changes are categorized as Configuration, Deployment, or Policy changes.
The hidden resource group `azure-changes-rg` stores change data; do not delete it.
Use `az change-analysis list` CLI command to query changes programmatically.
Change Analysis is part of Azure Monitor and accessible from the resource's 'Change Analysis' blade under 'Monitoring'.
These come up on the exam all the time. Here's how to tell them apart.
Application Change Analysis
Shows configuration changes (before/after values) for ARM resources.
Polling interval of 5 minutes; immediate for deployments.
No agent needed for ARM resources; agent for App Service code changes.
Default retention 30 days (extendable to 90).
Part of Azure Monitor; accessible from resource's monitoring blade.
Azure Activity Log
Shows management operations (who, what, when).
Real-time logging of operations via Event Hub / Log Analytics.
No agent needed; logs are generated by ARM.
Default retention 90 days for diagnostic settings (30 days for Activity Log itself).
Part of Azure Monitor; accessible from Activity Log blade.
Mistake
Change Analysis requires an agent to be installed on all resources.
Correct
No agent is needed for Azure Resource Manager resources (VMs, storage, etc.). Only App Services require a site extension for code-level changes. ARM resource configuration changes are captured automatically via the Resource Manager API.
Mistake
Change Analysis provides real-time change detection.
Correct
The default polling interval is 5 minutes, so changes may take up to 5 minutes to appear. However, deployment events trigger an immediate snapshot, providing near-real-time detection for deployments.
Mistake
Change Analysis data is retained for 90 days by default.
Correct
The default retention is 30 days. You can extend it to 90 days by configuring diagnostic settings to export change data to a Log Analytics workspace or storage account.
Mistake
Change Analysis duplicates the information in the Activity Log.
Correct
Activity Log records management operations (e.g., 'Write VM'), while Change Analysis shows the resulting configuration changes (e.g., VM size changed from A to B). They are complementary, not duplicative.
Mistake
You must manually enable Change Analysis for each subscription.
Correct
Change Analysis is enabled by default for all subscriptions. You only need to enable it explicitly for App Services to track code-level changes.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
To enable Change Analysis for App Service code-level changes, go to your App Service in the Azure portal, then under 'Monitoring' select 'Change Analysis'. Click 'Enable' to install the Change Analysis site extension. Alternatively, you can add an application setting named `CHANGE_ANALYSIS_ENABLED` with value `1`. Once enabled, the agent polls every 5 minutes for file and configuration changes. For ARM-level changes (e.g., scaling), no agent is needed.
Activity Log records management events such as 'Create VM' or 'Update NSG', showing who performed the operation and when. Change Analysis shows the resulting configuration changes—for example, that the VM size changed from Standard_DS2_v2 to Standard_DS3_v2, or that a specific NSG rule was added. Both are useful for troubleshooting: Activity Log tells you what operation occurred, while Change Analysis tells you the exact state change.
By default, Change Analysis data is retained for 30 days. You can extend retention to up to 90 days by configuring diagnostic settings for the Change Analysis resource. Export the 'Change' category to a Log Analytics workspace or storage account. Note that the diagnostic setting is configured on the hidden resource `Microsoft.ChangeAnalysis/changes` in your subscription.
Yes, Change Analysis tracks configuration changes to VMs, such as VM size, disk changes, network interface attachments, and extensions. However, it does not track changes inside the operating system (e.g., installed software, registry changes). For OS-level changes, use Azure Automation Change Tracking or Azure Policy guest configuration.
Change Analysis operates within a single subscription. You cannot view changes across subscriptions in one view. However, you can query each subscription separately using the Azure CLI or API. For cross-subscription visibility, consider exporting change data to a central Log Analytics workspace using diagnostic settings.
Deleting the hidden resource group will remove all stored change data and break Change Analysis for that subscription. You may need to contact Microsoft Support to re-enable the feature. It is strongly recommended that you do not modify or delete this resource group. You can hide it from the portal by filtering out hidden resource types.
You can create Azure Monitor alerts based on Change Analysis data. For example, use a Log Analytics query to detect changes to a specific property and set an alert rule. Alternatively, use Activity Log alerts for management operations (e.g., 'Update VM') which often precede configuration changes. Change Analysis itself does not have built-in alerting, but you can export data to Log Analytics and alert on that.
You've just covered Application Change Analysis — now see how well it sticks with free AZ-104 practice questions. Full explanations included, no account needed.
Done with this chapter?