Design identity, governance, and monitoring solutions
Logging, Log Routing, and Monitoring Architecture
CoreDesign an observability architecture that collects the right signals, routes them to appropriate destinations, and turns them into actionable health information.
Aligned to the current AZ-305 study guide, skills measured as of April 17, 2026, verified August 25, 2026.
Why this matters
Architecture teams must make telemetry useful across operational, security, compliance, and cost boundaries without treating one workspace or one dashboard as universally optimal.
Must Know
- Treat metrics, logs, and traces as complementary signals, selecting each according to the operational question it must answer.
- Route telemetry by purpose: use Log Analytics for investigation, storage for economical retention, and Event Hubs for external streaming.
- Configure diagnostic settings wherever supported resource logs or metrics must reach a chosen destination.
- Set workspace boundaries according to query, tenancy, region, retention, and access requirements.
Compare and Distinguish
- Metrics provide efficient numeric time-series signals; logs support richer querying and correlation; traces follow requests across components.
- A Log Analytics workspace supports interactive log analysis, while a storage account supports low-cost retention and an event hub supports streaming to external platforms.
- Platform metrics are collected automatically for many resources; resource logs usually require diagnostic settings and destination design.
Scenario examples
- Scenario: A regulated enterprise needs searchable operational logs for 90 days and immutable long-term retention. Think: route to Log Analytics for analysis and to storage for the retention boundary.
- Scenario: A platform team needs service-level objectives across a distributed application. Think: combine metrics, logs, traces, dependency data, and actionable alerts.
- Scenario: A security operations platform outside Azure needs a continuous feed. Think: route supported diagnostic data to an event hub rather than granting it workspace access.
Exam traps
- A dashboard does not collect telemetry.
- Activity Log records subscription control-plane events, not every guest or application event.
- Sending every signal to one destination can violate residency, access, or cost requirements.
Key takeaways
- Begin with consumers, questions, retention, region, and access boundaries.
- Select destinations independently for interactive analysis, archive, and external streaming.
- Design alert quality and ownership with the same care as collection.
How it works
- A diagnostic setting selects supported log categories or metrics at its resource scope, then asynchronously sends each record to the configured destinations; a Log Analytics table is created when its first records arrive.
- One setting can fan out to different destination types, but routing to two destinations of the same type requires separate settings, and regional resources impose location rules on Storage and Event Hubs destinations.
- Azure Monitor evaluates the selected metric or log signal against the alert rule, maintains the resulting alert state, and invokes an action group when the rule criteria are met.
Objects and administrative surfaces
- Resource and subscription diagnostic settings route supported resource logs and metrics.
- Azure Monitor workspaces and Log Analytics workspaces are chosen around query, tenancy, region, retention, and access boundaries.
- Alerts need signal, condition, evaluation behavior, action group, and ownership—not just a visualization.
When to use it
- Use a Log Analytics workspace when teams need KQL investigation inside a defined access and retention boundary.
- Route a separate copy to storage when archive duration or cost differs from the searchable window.
- Send supported diagnostic data to Event Hubs when an external platform needs a continuous feed without workspace access.
Security and governance implications
- Limit workspace query rights and diagnostic-setting changes separately, and keep regulated telemetry in approved regions and destinations.
- Protect archive integrity and avoid granting an external SIEM broad subscription ownership merely to receive selected records.
How to validate and revise the design
- When expected records are absent, verify the source category, diagnostic setting scope, destination region, table creation, and ingestion delay.
- When alerts are noisy or silent, trace the signal, aggregation, evaluation window, suppression rules, action group, and response owner.
More detail
- Centralizing logs simplifies cross-resource correlation, but workspace consolidation also expands the access, cost, residency, and retention boundary; separate workspaces can preserve boundaries at the cost of cross-workspace analysis.
- Available resource-log categories differ by service, and category groups can change as Microsoft adds categories, so the design must deliberately control collection volume and review category coverage.
- Diagnostic-setting export is not identical to native metric analysis: only exportable metrics can be routed, and exported multidimensional metrics can lose their dimensions through aggregation.
Ready for the quiz?
- Which telemetry consumer needs interactive queries, economical archive, or an external stream?
- Where should workspace, retention, region, and access boundaries be drawn without losing required correlation?
- Which alert signal, threshold, action group, and owner prove that detection will lead to a response?
Related objectives
- D1.1.S1 — Recommend a logging solution
- D1.1.S2 — Recommend a solution for routing logs
- D1.1.S3 — Recommend a monitoring solution