AZ-305 Logging and Monitoring Design: Log Analytics Workspaces, Log Routing, Alerts and Azure Monitor

A logging and monitoring design decides what telemetry you collect, where it is stored, who can read it, where it is routed and what watches it. In Azure almost all of it runs on Azure Monitor, which keeps two kinds of data: metrics (numeric time series, near real time, kept by the platform with no ingestion cost) and logs (records stored in a Log Analytics workspace and queried with KQL). Prometheus metrics from containers are the exception: they go to an Azure Monitor workspace and are queried with PromQL.

The task has three parts, and the rest of this lesson follows them:

• A logging solution: how many Log Analytics workspaces, where they live, access control, table plans, retention, encryption and resilience.
• Routing logs: diagnostic settings, the activity log, Azure Monitor Agent with data collection rules (DCRs), ingestion-time transformations and data export rules.
• A monitoring solution: alert types, alert processing rules, Application Insights, network monitoring and container monitoring.

The same rule applies to every recommendation: pick the option that meets every stated requirement (residency, single copy, no code change, lowest cost, least effort) and nothing more. Identity design and governance structure (management groups, policy as a compliance tool) are covered in the sibling lessons of this domain. Here, Azure Policy appears only as a way to deploy logging settings at scale.

Start with one Log Analytics workspace and add more only when a specific requirement forces a split. This is Microsoft's own workspace design guidance. One workspace is the simplest to manage. Queries across all resources need no cross-workspace syntax, and all ingestion counts towards one commitment tier, which is how volume discounts are reached.

The criteria that justify more than one workspace:

Access control does not justify a split. Resource-context access and granular RBAC let teams share one workspace. Workspace replication doesn't solve residency either: the primary still stores the data in its own region.

Service providers and multiple tenants

A managed service provider (MSP) whose customers each own their data uses the distributed model: a workspace in each customer's tenant, so the customer controls it and can delete it, plus Azure Lighthouse delegation, so the provider's analysts can query those workspaces, and across them, from the provider's own tenant. A central workspace in the provider's tenant breaks customer ownership.

Access to a Log Analytics workspace is controlled by its access control mode plus Azure RBAC, which can be narrowed down to tables and rows. A well-designed shared workspace keeps one copy of the data and grants each audience exactly its slice.

Two traps. First, table-level access works per table, not per resource: if two teams' resources write to the same table, each team sees the other's rows. Resource-context access is what separates by resource. Second, switching to "Require workspace permissions" breaks resource-context access for everyone who relied on it. Resource-context access for computers outside Azure (on-premises, other clouds) works only when they are Azure Arc-enabled, because the record must be linked to an Azure resource ID.

Copying a subset of data into a second workspace to separate access always doubles ingestion of that subset. When a requirement says "one copy of the data" or "don't ingest twice", the answer is an access control, not a second destination.

Each Log Analytics table has a plan that trades ingestion price against query speed and features. Set the plan per table to match how the data is used.

How to choose:

• Analytics for high-value data used continuously: security detections, Insights, complex alerting.
• Basic for high-volume troubleshooting data that still needs fast queries and a simple alert, such as container logs during incidents. Basic is also the cheapest plan that still supports export rules and replication.
• Auxiliary for low-touch, verbose or audit data queried a few times a year, where slow queries are acceptable and no alerts, export or replication are needed.

A frequent near-twin decision: the price favours Auxiliary, but a second requirement (an export rule to a SIEM, replication, an alert, or fast incident queries) rules it out, leaving Basic as the lowest-cost plan that works. Container logs are a common Basic candidate. The current Container insights schema, ContainerLogV2, supports the Basic plan; the legacy ContainerLog table only ever worked on Analytics, and its support ended on 30 September 2026.

Retention, long-term data, search jobs and restore

A Log Analytics table keeps data in analytics retention (up to two years) and then, if you set a longer total retention, in low-cost long-term retention, up to 12 years in total. Long-term data stays in the workspace: no separate storage to manage, and it is still reachable with KQL through two tools.

• Set analytics retention to how long data is queried interactively (for example 60 days), and total retention to the compliance period (for example ten years). Keeping old data in analytics retention costs more than long-term retention and can't exceed two years anyway.
• Regular queries read only data in analytics retention. A query over six years from the Logs page doesn't scan long-term data.

Raising analytics retention to cover an old investigation window is the costly alternative: it bills analytics retention for every record in the table every month, long after the investigation ends.

Beyond 12 years, or immutable copies

No table plan keeps data beyond 12 years in the workspace, and a resource lock protects the workspace resource, not individual records. When a regulator requires longer retention or records that can't be changed or deleted, send the data with a data export rule to a storage account that has a time-based immutability policy. Storage can keep data indefinitely, and the export rule keeps the copy current as new data arrives.

Diagnostic settings are how Azure resources send their platform logs (resource logs) and platform metrics out of the platform. Without a diagnostic setting, resource logs aren't collected at all.

Destinations

Design limits to remember:

• A setting holds at most one destination of each type, so two workspaces need two settings. A storage account or event hub can sit in either one.
• A resource can have up to five diagnostic settings.
• For regional resources, storage and Event Hubs destinations must be in the same region as the resource. Resources in several regions need a storage account and Event Hubs namespace per region. Storage redundancy settings don't change where the account itself lives.
• Metrics are a category inside a setting, not a separate setting.
• Category groups (allLogs, audit) are defined by Microsoft. When a service adds categories to a group, collection follows automatically, unlike a fixed list of categories.

The activity log

The Azure activity log records control-plane operations on a subscription: who created or deleted resources, changed role assignments, plus Service Health and Resource Health events. Azure keeps it for 90 days. To keep it longer and query it with KQL, create a subscription diagnostic setting that sends it to the AzureActivity table in a workspace. Activity log ingestion into a workspace isn't charged, and its retention follows the table. Resource logs record operations inside a resource (data plane), and Microsoft Entra audit logs record directory changes. Neither replaces the activity log for Resource Manager operations.

A diagnostic setting on a management group captures only Azure Resource Manager events at that scope, not events generated directly by resource providers. Microsoft still recommends subscription-level settings for complete coverage, which leads to Azure Policy (below).

Deploying diagnostic settings at scale with Azure Policy

To make every current and future resource or subscription send logs to a central destination, assign a DeployIfNotExists policy (or built-in initiative) at a management group and run a remediation task for what already exists.

• DeployIfNotExists deploys the diagnostic setting to resources in scope that are created or updated without it, using the assignment's managed identity.
• Existing resources are only marked non-compliant. A remediation task deploys the setting to them.
• AuditIfNotExists only reports missing settings; it never creates them. Deny can't enforce a diagnostic setting, because the setting is a separate resource created after the resource it monitors. Modify changes tags and properties on the resource itself and can't create a diagnostic setting.
• Built-in policies cover resource logs per resource type, with a categoryGroup parameter (audit or allLogs), and the activity log, which deploys a subscription diagnostic setting into every subscription under the management group, including new ones.

A common failure: when you assign the policy, the managed identity automatically gets the roles from the policy definition, but only at the assignment scope. If the destination workspace sits in a subscription outside that scope, remediation fails with an authorization error until you grant the identity a role on the workspace yourself. Remediation always runs as the assignment's managed identity.

The exam guide treats Azure Policy as a compliance tool in the governance task; here it is the mechanism that keeps logging configured without manual work.

Azure Monitor Agent (AMA) is the one supported agent for collecting guest operating system data (Windows events, syslog, performance counters, text logs), and data collection rules (DCRs) define what it collects and where it sends it. The legacy Log Analytics agent (MMA/OMS) was retired in August 2024 and must never be part of a new design.

• AMA runs on Azure VMs and scale sets. On on-premises servers and other clouds (for example Amazon EC2), it is supported only on Azure Arc-enabled servers. Onboarding with the Connected Machine agent gives each machine an Azure resource ID, which AMA needs and resource-context access relies on.
• One machine can be associated with several DCRs, and each DCR (or each data flow inside one) names its own sources and destination. To send security events only to the security workspace and performance counters only to the operations workspace, use separate DCRs or flows. Sending both streams to both workspaces ingests everything twice.
• Windows event sources in a DCR accept custom XPath queries, for example Security!*[System[(EventID=4688)]] for process-creation events only. The agent sends only matching events, so ingestion falls with no extra service. A daily cap is not a filter: it stops all ingestion when reached. A cheaper table plan lowers price per GB but still ingests everything.
• The Azure Diagnostics extension is a legacy extension for Azure VMs only, and it can't cover machines outside Azure. Microsoft Defender for Servers is threat protection, not a way to define log collection.
• App Service and other PaaS services aren't monitored with AMA: their platform logs come through diagnostic settings and their application telemetry through Application Insights.

Custom applications can also send data directly with the Logs Ingestion API, which always goes through a DCR into a custom table or a supported Azure table.

Transformations change data before it is stored; data export rules copy data after it is stored. Both are routing tools, and they are often confused.

Ingestion-time transformations

A transformation is a KQL statement (transformKql) in a DCR that runs on each incoming record after Azure Monitor receives it and before it is written to the table. It can drop rows (where), remove or mask columns (for privacy) and parse nested fields into new columns (extend). Only the result is stored and billed.

Neither a saved KQL function nor diagnostic setting category selection meets a "before it is stored" requirement. A function changes only how data is read, and category selection can't filter rows or columns inside a category.

Data export rules

A data export rule continuously copies selected tables from a workspace to a storage account or Event Hubs as data arrives, with no schedule to maintain. Its behaviour:

• Only new data from the moment the rule is created. No backfill; historical data needs a query-based export.
• Whole tables only. A rule can't filter rows; filter at ingestion with a transformation instead.
• One rule can include several tables, up to a limit of active rules per workspace.
• Supports Analytics and Basic tables, not Auxiliary.
• Destinations must be in the workspace's region. For a copy in a second region, use a geo-redundant storage account (GRS or GZRS) in the workspace's region.
• A destination can't be another workspace. To land data in two workspaces, route it there at collection time.

Scheduled query exports, for example with Logic Apps, work for small data sets but are subject to query limits and need upkeep. A search job writes only into the same workspace.

Workspace replication protects ingestion and queries against a regional outage, and customer-managed keys (CMK) give an organisation control over the encryption of its log data.

Workspace replication

• Replicates a workspace to a secondary region within the same region group, for new data only from the time it is enabled.
• Switchover and switchback are manual.
• Enabling it creates a system data collection endpoint (DCE) for the workspace. Agent and Logs Ingestion API data follow their DCRs, and only DCRs associated with that system DCE keep ingesting during a switchover. This also lets you choose which streams to replicate and pay for.
• The secondary is a replica of the same workspace, not a separate destination a DCR can name. DCRs have no replication setting of their own.
• Analytics and Basic tables replicate; Auxiliary tables don't, and Microsoft advises not enabling replication on workspaces that include Auxiliary tables. Replication doesn't extend retention and doesn't satisfy data residency.

Customer-managed keys

• CMK for Azure Monitor Logs is configured on a dedicated cluster. Workspaces are linked to the cluster; they have no key setting of their own.
• A dedicated cluster requires a commitment tier, starting at 100 GB per day. Several workspaces in the same region can share one cluster to reach it.
• The key lives in Azure Key Vault or Managed HSM, with soft delete (always on) and purge protection enabled, in the same region as the cluster and workspaces.
• Linked workspaces encrypt new data with the key. Disabling or revoking the key cuts off access to that data.
• Keys on linked storage accounts protect only the features that use those accounts, not ingested log data.

Choose the alert type by the signal: metric alerts for platform metrics, log search alerts for KQL over logs, activity log alerts for control-plane events, and Service Health or Resource Health alerts for Azure's view of service and resource health. Every type notifies through an action group (email, SMS, voice, webhook, ITSM, automation).

Alert processing rules

An alert processing rule acts on alerts after they fire, so you change notification behaviour without editing alert rules. It covers existing and future rules in its scope.

• Scope: subscription, resource group or resource. Filters: severity, alert rule, monitor service, resource type and others.
• Suppress notifications: action groups don't run, but the alerts are still created and recorded for review. Use it for maintenance or batch windows. This is unlike disabling rules, which records nothing.
• Apply action group: adds an action group (for example an ITSM webhook) to every matching alert, such as every Sev2 alert in one resource group.
• Schedule: once, or recurring daily, weekly or monthly within set hours.

Combine a schedule with a severity filter when critical alerts must still page during a window. A suppression rule without the filter silences them too. Changing what happens to many rules' alerts is the processing rule's job; editing each alert rule doesn't scale.

Application Insights monitors application behaviour, Network Watcher monitors network traffic and paths, and Container insights with managed Prometheus monitors AKS.

Applications: Application Insights

• Application Insights is workspace-based: telemetry is stored in a Log Analytics workspace. It correlates requests, dependencies and exceptions into distributed traces and an application map across App Service, Functions, AKS and VMs. Microsoft's recommended instrumentation is the Azure Monitor OpenTelemetry Distro.
• Autoinstrumentation for supported runtimes, such as ASP.NET Core on App Service, is turned on from the resource's settings. It collects requests, failures, response times and dependencies such as SQL calls without code changes. Adding the SDK also works, but needs a code change and a redeploy.
• Sampling cuts ingestion while keeping each operation's request, dependencies and exceptions together, and adjusts counts so metrics stay statistically accurate. A daily cap creates blind periods. Dropping random rows with a transformation breaks correlation. Shorter retention doesn't reduce ingestion.
• Standard availability tests check an endpoint from several locations at a set frequency, and can validate the TLS certificate and warn before it expires. URL ping tests are deprecated and retire on 30 September 2028, so new designs use Standard tests.

Networks: Network Watcher

Containers: AKS

• Azure Monitor managed service for Prometheus collects Prometheus metrics into an Azure Monitor workspace, queried with PromQL and used by Prometheus alert rules, so you no longer run Prometheus servers.
• Azure Managed Grafana runs Grafana as a service and imports existing dashboards that query that workspace.
• Container insights collects container logs into ContainerLogV2, which supports the Basic plan. Scraping Prometheus metrics into a Log Analytics workspace is the costlier, KQL-based route and means rewriting PromQL dashboards.