Azure Monitor and Log Analytics explained
Azure Monitor is the platform that collects, stores and acts on telemetry from Azure resources. It keeps two kinds of data in two different stores: metrics (numbers over time, collected automatically) and logs (records you query with KQL, stored in a Log Analytics workspace). The decision rule for most exam questions: if the data is a number that needs little processing, use metrics; if you need to search, join, retain or correlate records, send logs to a workspace with a diagnostic setting or a data collection rule.
Follow one record from resource to alert
The path has four stages, and exam questions usually break at exactly one of them.
- Source. An Azure resource, a VM, an app or an on-premises server produces data.
- Collection. Something has to move the data. For Azure resources that is a diagnostic setting. For VMs and servers it is the Azure Monitor Agent, configured through a data collection rule. A collection rule can also transform or filter data before it is stored.
- Store. Metrics go to the metrics database. Logs go into tables in a Log Analytics workspace.
- Use. You query with KQL, build workbooks, raise alerts, export, or let Microsoft Sentinel and Defender for Cloud read the same tables.
What is collected without any setup
| Data | Collected automatically? | Notes |
|---|---|---|
| Platform metrics | Yes | Available in metrics explorer with no configuration |
| Activity log | Yes | Control plane operations such as creating a VM; kept for 90 days, no ingestion charge during that time |
| Resource logs | No | Data plane operations, for example reading a secret from a Key Vault. Need a diagnostic setting |
| Guest OS and application data | No | Needs the agent plus a data collection rule, or Application Insights |
The control plane versus data plane split is the most tested idea on this page. The activity log answers “who deleted the VM”, a resource log answers “who read the secret”. Longer than 90 days for the activity log means sending it to a workspace or a storage account through a diagnostic setting.
Diagnostic setting rules worth remembering (Microsoft Learn, diagnostic settings): each resource can have up to five; one setting cannot hold two destinations of the same type, so two workspaces need two settings; a storage account or Event Hubs destination must be in the same region as a regional resource; data can take up to about 90 minutes to start flowing. Destinations are a workspace (query and alert), a storage account (cheap archive, can be immutable), Event Hubs (stream to a non-Microsoft SIEM) and partner solutions.
Tables, plans and retention
A workspace holds tables, and cost is managed per table through its table plan:
| Plan | Use it for | Trade-off |
|---|---|---|
| Analytics | Monitoring, alerting, detection | Full features, highest ingestion price, query cost included |
| Basic | Troubleshooting data you query occasionally | Cheaper ingestion, query charged, only simple log alerts |
| Auxiliary (shown as Auxiliary / Lake in current docs) | Verbose audit and compliance data | Cheapest, slower queries, no alerts |
Analytics tables keep data in the interactive window for 30 days by default (90 days for Microsoft Sentinel and Application Insights data) and can be extended to two years; total retention, including low-cost long-term retention, goes up to 12 years. Requirement words like “keep for seven years but rarely query” point to long-term retention or the cheaper plans, not to a bigger Analytics window.
Workspace design: one or many
Microsoft’s guidance is to start with a single workspace and add more only when a criterion forces it. The criteria that do:
- Regions and data residency. A workspace lives in one region. A rule that data must stay in a geography means a workspace there.
- Microsoft Entra tenants. Several data sources can only send to a workspace in the same tenant, so multiple tenants usually mean a workspace in each.
- Data ownership and split billing. Separate subsidiaries or charge-back to different payers may justify separate workspaces.
- Different retention for the same table. Retention is per table, so two resource sets that need different retention in the same table need two workspaces.
- Operations versus security. Enabling Microsoft Sentinel applies Sentinel pricing to all data in that workspace, so a dedicated security workspace often saves money and separates ownership. Combining them can reach a commitment tier and give one view. See Microsoft Sentinel explained.
Access is the other half. By default a user with read access to an Azure resource can read that resource’s data in the workspace (resource-context access). Choosing “require workspace permissions” turns that off, and table-level RBAC can deny specific tables. Workspace-level access shows everything in the workspace.
Worked example: audit trail for a Key Vault
A company must record every secret read from its production Key Vault, keep the record for two years, and alert the security team when a read comes from outside the corporate network.
- Create a diagnostic setting on the Key Vault, select the
auditcategory group (orallLogs), destination: the security Log Analytics workspace. The vault logs are not collected without this. - Set table retention on the audit table to two years of total retention. The interactive window can stay short.
- Write a KQL query that filters the vault’s audit records on the caller IP, and turn it into a log search alert with an action group that notifies the team. KQL basics are in the KQL cheat sheet.
Which alert type
| Signal | Alert type |
|---|---|
| CPU above a threshold, little processing needed | Metric alert |
| Pattern in log records, joins, custom logic | Log search alert |
| A VM was deleted, a role was assigned, a service health event | Activity log alert |
| Detect an absence of data, such as a missing VM heartbeat | Metric alert (logs are more latent) |
Which exams test this
| Exam | How the topic appears | Where on this site |
|---|---|---|
| AZ-900 | Management and governance domain: describe Azure Monitor, including Log Analytics, alerts and Application Insights, at concept level | AZ-900 management and governance |
| AZ-104 | Monitor and maintain Azure resources domain: interpret metrics, configure log settings, query logs, set up alert rules, action groups and alert processing rules, use Insights | AZ-104 monitor and maintain |
| AZ-305 | Identity, governance and monitoring domain: recommend a logging solution, a way to route logs and a monitoring solution | AZ-305 identity, governance and monitoring |
| AZ-400 | Instrumentation strategy domain: configure Azure Monitor and Azure Monitor Logs for DevOps tools, collect telemetry with Application Insights and other Insights, query logs with basic KQL | AZ-400 instrumentation |
| AZ-802 | Monitor and troubleshoot domain: configure data collection rules for Azure Monitor, create alerts, use VM Insights for Azure VMs | AZ-802 monitoring and troubleshooting |
| SC-200 | Security operations environment domain: collect Azure activity logs with Azure Policy and diagnostic settings, custom tables in the workspace, table retention (outline in force from October 21, 2026) | SC-200 security operations |
| SC-300 | Identity governance domain: configure diagnostic settings that send Entra logs to a Log Analytics workspace, storage or Event Hubs, and query them with KQL | SC-300 identity governance |
| SC-500 | Security posture domain: create Sentinel workspaces, collect Windows events with data collection rules, custom log tables, data retention | SC-500 security posture |
| AI-200 | Secure, monitor and troubleshoot domain: write KQL queries to analyze logs and metrics. A minor part of this page | AI-200 secure, monitor and troubleshoot |
| DP-750 | Deploy and maintain pipelines domain: stream Databricks logs to Log Analytics and configure Azure Monitor alerts | DP-750 deploy and maintain pipelines |
| DP-800 | Secure, optimize and deploy domain: recommend Azure Monitor configurations, including Application Insights and Log Analytics. A minor part of this page | DP-800 secure, optimize and deploy |
How exam questions are built
The usual trap is choosing the right feature for the wrong data. Watch for these:
- “Who read” or “which application accessed” is a resource log. “Who created or deleted” is the activity log.
- “Without any configuration” points to platform metrics and the activity log. Resource logs always need a diagnostic setting.
- “Stream to a third-party SIEM” means Event Hubs. “Archive cheaply and keep indefinitely” means a storage account. “Query and alert” means a workspace.
- “Fewest workspaces” or “minimize administrative effort” favours a single workspace unless the scenario names a residency, tenant, billing or retention constraint.
- “Detect that a machine stopped reporting” favours a metric alert over a log search alert.
Question 1. A company must keep a record of every data plane read of secrets in an Azure Key Vault for two years. Security analysts must be able to query recent records in KQL. Which combination meets the requirement?
- A. Export the activity log to a storage account and keep it for two years
- B. Create a diagnostic setting for the vault that sends audit logs to a Log Analytics workspace and set the table retention to two years
- C. Enable platform metrics on the vault and set a metric alert
- D. Rely on the default activity log and extend it to two years
Show answer
Answer: B
Key Vault read operations are resource logs, which are not collected by default. A diagnostic setting sending the audit logs to a Log Analytics workspace makes them queryable, and the table retention can be set to two years total. The activity log records management operations, not secret reads. A storage account archive cannot be queried with KQL in the workspace. Platform metrics contain numeric counts, not who read which secret.
Question 2. You must be notified whenever a virtual machine in the production subscription is deleted. You want the simplest solution that needs no query. What should you create?
- A. An activity log alert with an action group
- B. A metric alert on VM CPU percentage
- C. A log search alert after exporting the activity log to a workspace
- D. A diagnostic setting on each virtual machine
Show answer
Answer: A
Deletion is a management operation recorded in the activity log, and an activity log alert matches such events directly and calls an action group. A metric alert watches numeric values such as CPU, which do not capture a delete. A log search alert could work after exporting the activity log to a workspace, but needs a query and extra setup. A diagnostic setting only routes data and does not notify anyone by itself.
Go deeper
- Azure Monitor Logs overview, including table plans and retention.
- Design a Log Analytics workspace architecture
- Diagnostic settings in Azure Monitor
- Types of Azure Monitor alerts
- Next topics: Microsoft Sentinel explained, KQL cheat sheet, Azure governance design. For the study approach see how to study for certification exams.