AZ-305
Deep Dive
In AZ-305 monitoring isn't "what does Azure Monitor do" but how to design the workspace topology, which tool to use for each signal (metrics, logs, traces), and how to balance retention vs cost. The recurring question: centralized or decentralized?
Contents
| Tool | Signal | When to use it in the design |
|---|---|---|
| Azure Monitor Metrics | Numeric platform metrics (near real-time) | CPU/latency alerts, autoscaling, live dashboards |
| Azure Monitor Logs (Log Analytics) | Structured logs queryable with KQL | Deep analysis, correlation, auditing, log alerts |
| Application Insights | App telemetry (requests, dependencies, exceptions, traces) | APM: app performance and failures, distributed tracing |
| Activity Log | Control-plane operations (who created/deleted what) | Change auditing — export to the workspace for retention |
| Diagnostic Settings | Router: sends resource logs/metrics to destinations | Workspace (analysis), Storage (cheap archiving), Event Hubs (external SIEM) |
| Microsoft Sentinel | SIEM/SOAR built on Log Analytics | Threat detection, hunting, automated response |
| Network Watcher | Network diagnostics (flow logs, packet capture) | Connectivity troubleshooting, NSG flow logs |
Mnemonic rule for diagnostic settings
Analyze → Log Analytics workspace. Cheap archiving → Storage Account. Integrate with SIEM/third parties → Event Hubs. A single diagnostic setting can send to several destinations at once.
General recommendation (and the CAF's): one central workspace per region in the Management subscription. Start centralized; split only when there's a real driver.
Centralized workspace (default)
When to split workspaces
Access control inside a shared workspace
What it brings to the design
Instrumentation
| Alert type | Signal | When to design it |
|---|---|---|
| Metric alert | Numeric platform metric (CPU, latency, requests) | Low latency (~1 min); ideal for autoscaling triggers, performance SLAs |
| Log alert | KQL query over Log Analytics | Complex conditions (e.g. 5 500-errors in 10 min); 1-5 min latency |
| Activity log alert | Control-plane (ARM) operation | Auditing: someone deleted an RG, changed a policy, deleted a Key Vault |
| Smart detection (App Insights) | Automatically detected anomalies | No manual threshold — ML detects degradation, dependency failures, unusual exceptions |
| Prometheus alerts (AKS) | Prometheus metrics from the cluster | Kubernetes workloads — defined with PromQL rules in Azure Monitor Workspace |
Action groups — "who to notify"
An action group is the list of actions to run when an alert fires. Reusable: multiple alert rules can point to the same group.
Alert design principles
Exam signal
"Notify the team when someone deletes a resource group" → activity log alert. "Alert when CPU > 90%" → metric alert. "Automatic ServiceNow ticket when an alert fires" → action group with ITSM connector. "Automatically restart a service when it fails" → action group with an Automation Runbook.
| Layer | Characteristic | Design use |
|---|---|---|
| Interactive retention | Data queryable with KQL at full performance (up to 2 years) | Day-to-day operations, alerts, dashboards |
| Long-term retention (archive) | Up to 12 years, cheap, not directly queryable — needs restore or search jobs | Long-term regulatory retention compliance |
| Basic/Auxiliary table plans | Cheaper ingestion, limited KQL, short retention | High-volume, low-value logs (verbose, debug) |
| Commitment tiers | Discount for committing to a GB/day volume | Predictable volumes ≥100 GB/day |
| Export to Storage | Diagnostic settings → storage account with lifecycle to Cool/Archive | Cheaper archiving outside the workspace, immutability |
| DCR transformations | Filter/transform at ingestion (Data Collection Rules) | Drop irrelevant columns/rows before paying for them |
The dominant cost is INGESTION
Log Analytics charges mainly by GB ingested. Design levers: filter at the source (DCR transformations), Basic table plans for verbose logs, App Insights sampling, and archive/export for long-term retention. If a scenario asks to "retain audit logs for 7 years at the lowest cost" → archive tier or export to storage with the Archive tier.
| Requirement | Design |
|---|---|
| Correlate logs from 50 workloads with one query | Central workspace (Management subscription) |
| Germany's logs cannot leave Germany | Dedicated workspace in the German region |
| Each team sees only its own resources' logs in a shared workspace | Resource-context RBAC |
| Trace a request across 10 microservices | Application Insights (distributed tracing / App Map) |
| Test website availability from 5 regions | App Insights availability tests |
| Retain audit data for 7 years at the lowest cost | Long-term retention (archive) or export to Storage Archive |
| Send logs to the company's Splunk SIEM | Diagnostic settings → Event Hubs |
| Reduce the ingestion cost of verbose logs | DCR transformations + Basic table plan |
| Threat detection and hunting over the logs | Microsoft Sentinel on top of the workspace |
| Notify when CPU exceeds 90% on any VM | Metric alert scoped to subscription/RG + email action group |
| Alert when someone deletes a critical resource | Activity log alert (Delete operation on that resource) |
| Open a ServiceNow ticket when an alert fires | Action group with an ITSM connector |
| Automatically restart a service on failure detection | Action group → Automation Runbook |
Did you get this topic?
Test what you just learned
A company with workloads in West Europe designs its monitoring: (1) the SOC needs to correlate security events across all workloads, (2) each application team must see only its own resources' logs, (3) audit logs must be retained for 7 years at the lowest cost. Which design satisfies all of this?
Put what you learned to the test with original AZ-305 exam questions.
Start AZ-305 mock examUnlimited mock exams with the Pro plan
Log in to track your progress.