2.2 Log Routing Design
Key Takeaways
- Diagnostic settings route to four destination types only: Log Analytics workspace, Storage account, Event Hubs, and Azure Monitor partner solutions
- Microsoft Sentinel is a SIEM/SOAR capability enabled on an existing Log Analytics workspace, not a distinct diagnostic-setting destination
- Use immutable (WORM) storage accounts for compliance archives that must remain unaltered for years
- Use Event Hubs to stream data to non-Microsoft SIEM tools (Splunk, QRadar) or custom real-time consumers
- A single diagnostic setting can fan out to all destination types at once, satisfying compliance archival, third-party SIEM, and native detection simultaneously
Why This Topic Matters on AZ-305
Once a logging strategy defines what to collect, Design solutions for routing logs decides where that data must travel next — a distinct official AZ-305 bullet inside Domain 1 (25-30% weight). Real enterprises rarely stop at "send it to one Log Analytics workspace." They must satisfy multi-year compliance retention, feed a non-Microsoft SIEM (Security Information and Event Management) their SOC already runs, or stream telemetry into custom analytics pipelines — and the exam expects you to match each requirement to the correct destination and integration pattern.
Core Destinations for Log Routing
A diagnostic setting can fan data out to any combination of the following (up to one of each type per setting, five settings per resource):
| Destination | Best for | Key design detail |
|---|---|---|
| Azure Storage account | Cheap, indefinite archival for audit and compliance | Send to an account with an immutable (WORM — write once, read many) policy to guarantee logs can't be altered or deleted before a retention date; only Standard storage accounts are supported (not Premium, not preview DNS-zone endpoints) |
| Azure Event Hubs | Streaming to external, non-Microsoft SIEM/SOAR tools or custom real-time pipelines | Requires Manage, Send, and Listen permissions on the Event Hubs namespace; the event hub can't be a compacted event hub, since Azure Monitor doesn't attach a partition key |
| Log Analytics workspace | KQL-based querying, workbooks, native alerting | The natural backing store used by Microsoft Sentinel |
| Azure Monitor partner solutions | Specialized non-Microsoft observability integrations | Varies per partner; use when the organization has already standardized on a supported third-party platform |
Exam trap: Microsoft Sentinel is not itself a diagnostic-setting destination in the list above. Sentinel is a SIEM/SOAR capability layer enabled on top of an existing Log Analytics workspace — you route logs to the workspace (via diagnostic settings, native connectors, or the Azure Monitor Agent), and then Sentinel's analytics and automation operate on that same workspace's data.
Microsoft Sentinel as a Routing Target
Microsoft Sentinel is Microsoft's cloud-native SIEM/SOAR solution: it ingests data through data connectors (built-in connectors for Microsoft Entra ID, Azure Activity, Azure Storage, Microsoft 365, and dozens of non-Microsoft products via Syslog, Common Event Format, or REST API), normalizes it at ingestion or query time (the Advanced Security Information Model, or ASIM), and layers detection and response on top:
- Analytics rules correlate low-fidelity signals across data sources into higher-fidelity incidents, mapped against the MITRE ATT&CK framework.
- Automation rules and playbooks (playbooks are Logic Apps workflows) provide SOAR — for example, automatically opening a ServiceNow ticket or isolating a compromised account when an incident fires.
- Watchlists let you correlate ingested events against externally supplied reference lists (high-value assets, terminated employees, known-bad IPs).
A key 2026 currency point for architecture design: Microsoft Sentinel is increasingly delivered through the Microsoft Defender portal rather than the Azure portal — Azure-portal support for Sentinel is scheduled to end March 31, 2027, and new Sentinel customers as of mid-2025 are being onboarded directly into the Defender portal. Architecturally this doesn't change where the data lives (still a Log Analytics workspace), but it does affect which admin experience and licensing model you design around.
Choosing Between Native Sentinel and a Third-Party SIEM
| Requirement | Recommended routing |
|---|---|
| Organization is standardizing security operations on Microsoft tooling | Route to a Log Analytics workspace and enable Sentinel directly (no Event Hub needed) |
| Organization has an existing on-premises or non-Microsoft cloud SIEM (Splunk, QRadar, etc.) that must keep receiving Azure telemetry | Route through Event Hubs, which the third-party SIEM's forwarder or connector consumes in near real time |
| Regulatory requirement to retain unaltered logs for years, independent of any SIEM | Route to an immutable storage account, in parallel with whichever SIEM path is chosen |
| Need both real-time detection and permanent unalterable archive | Combine all three: Log Analytics workspace/Sentinel (detection), Event Hubs (external streaming), Storage (immutable archive) — a single diagnostic setting can target all of them simultaneously |
Scenario Walkthrough
A healthcare provider must keep seven years of unaltered audit logs for regulatory compliance, forward the same security-relevant logs in real time to their existing on-premises Splunk deployment, and also want Microsoft's native detection analytics available to their SOC. The correct design configures a single diagnostic setting (or a small number, respecting the five-per-resource limit and one-per-destination-type rule) that sends resource logs to: (1) a storage account with an immutable policy and a 7-year retention rule for the compliance requirement, (2) an Event Hubs namespace that the on-premises Splunk forwarder already consumes, and (3) a Log Analytics workspace with Sentinel enabled so the SOC gets native analytics rules and incident correlation without waiting on Splunk-side engineering work.
Key Takeaways
- Diagnostic settings route to four destination types: Log Analytics workspace, Storage account, Event Hubs, and partner solutions — never directly to "Sentinel" as a named destination.
- Use immutable (WORM) storage accounts for compliance archives that must never be altered or deleted early.
- Use Event Hubs to stream data to non-Microsoft SIEM platforms or custom real-time consumers.
- Microsoft Sentinel is a SIEM/SOAR capability layered on a Log Analytics workspace, using data connectors, analytics rules, and Logic Apps-based playbooks for automation.
- A single well-designed diagnostic setting can satisfy compliance archival, third-party SIEM integration, and native Microsoft detection simultaneously by fanning out to all three destination types at once.
A design requires that Azure resource logs be forwarded in near real time to an existing on-premises Splunk deployment. Which diagnostic setting destination enables this?
A compliance team requires that certain audit logs be retained for seven years and be provably unmodifiable. Which routing destination and configuration satisfies this?
Which statement about Microsoft Sentinel is most accurate for an AZ-305 architecture design?