Quick Note — Recommend a Logging Solution
AZ-305 › Unit 1 › Design solutions for logging and monitoring › Recommend a logging solution
Quick Note — Recommend a Logging Solution
This lesson focuses on a single, high-impact Azure architecture decision: choosing the right Log Analytics workspace design for your organisation. A workspace is the gravitational centre of Azure observability — every diagnostic setting, every Data Collection Rule, every KQL query, and every alert rule ultimately depends on the workspace you point it at. Getting the topology, retention, access model, and pricing tier right on day one saves months of painful refactoring later. This lesson covers workspace topology patterns (centralised, decentralised, hybrid), retention and archival mechanics, RBAC and data-residency controls, and the cost levers that keep your logging bill predictable.
Retrieval target
- Recommend a Logging Solution
- Closed-book recall
- 5 minutes
- Open the full lesson after a miss
Decision anchors
| Prompt | Compact answer |
|---|---|
Log Analytics workspace | A regional, logical container that stores collected logs and metrics and is queried with KQL. Think of it as the centralized log "database" for an Azure tenant. It is the foundational sink for Azure Monitor — diagnostic, platform, and custom logs all route here. |
Basic Logs | A cheap, query-limited table plan in Log Analytics for high-volume, low-value logs (verbose application traces and debug telemetry). Lower ingestion cost than Analytics Logs but charges per query and limits each query to a single table — full KQL is available there, extendable with lookup or union against Analytics tables, and alert rules are supported as Simple Log Alerts. |
Commitment Tier | A daily-capacity pricing reservation for Log Analytics, sold from 100 GB/day up to GB/day. Trades pay-as-you-go flexibility for a discount of up to roughly 30%. Pick it once a workspace's daily ingestion is predictable. |
Long-term retention | A low-cost retention state for Log Analytics tables: data is kept up to 12 years at very low cost but is not directly queryable. To search it you must restore a time range to a temporary hot table or run a search job against the long-term retention period. |
Read the answers once, then cover the right-hand column and reconstruct each one from the prompt. A useful answer names the requirement, the recommended control or service boundary, and the nearest alternative it rejects. If you can only recognize the answer after seeing it, retrieval is not yet secure.
Ninety-second explanation
Without notes, explain:
- What requirement signals this learning objective rather than a neighbouring one?
- Which two solution families are most likely to be compared?
- Which hard constraint eliminates the strongest distractor?
- What identity, network, data, or failure boundary must appear in the design?
- Which operational test would prove the recommendation works?
Then compare your explanation with the full lesson. Record the missing decision rule—not merely the missed product name—in your error log.
When to open the full lesson
Open the curriculum-linked lesson when you cannot explain a comparison, when a scenario depends on a numeric limit or SKU feature, or when the service is on a retirement path. Use current Microsoft Learn documentation for availability, limits, pricing, naming, and migration milestones; the quick note is intentionally compact.
Source and freshness
Derived from the linked AZ-305 lesson and retrieval deck, grounded in both attached course sources. Reviewed 2026-08-02. Current Microsoft documentation controls changing product contracts.