Recommend a Logging Solution
Before you start: This course is independent of Microsoft and can't promise you a pass. The official AZ-305 study guide belongs to Microsoft. It isn't reproduced here, and you can read it free on Microsoft Learn. You need a score of 700 or more to pass. To earn the Microsoft Certified: Azure Solutions Architect Expert certification, you must also hold Microsoft Certified: Azure Administrator Associate.
As an administrator, you have already turned on diagnostic settings and run KQL queries. AZ-305 asks a different question: how should the whole logging estate be designed? This lesson walks through the decision in five steps, using the Requirements → Options → Trade-offs → Recommendation method from Level 1.
Step 1: Map each log type to where it lands
Azure Monitor Logs stores log data in a Log Analytics workspace, which is a data store made up of tables. Different kinds of log reach it in different ways. Learn this map first.
| Log type | What it records | How it is collected | Where it lands |
|---|---|---|---|
| Activity log (platform) | Subscription-level control plane events, such as creating a VM or changing a policy | Collected automatically and kept by Azure for 90 days at no charge | Send it to a workspace with a diagnostic setting (AzureActivity table, no ingestion charge) |
| Resource logs (platform) | Data plane operations inside a resource, such as reading a Key Vault secret | Not collected by default. You must create a diagnostic setting | A workspace, a storage account or an event hub |
| Microsoft Entra sign-in and audit logs | Identity activity | Diagnostic setting | A workspace, storage or an event hub |
| Guest OS logs (Windows Events, Syslog, text and IIS logs) | Activity inside the VM | Azure Monitor Agent (AMA) plus a data collection rule (DCR) | Workspace tables |
| Application logs | Requests, exceptions, traces | Application Insights | The workspace you choose when you onboard the app |
Do: For every workload in a scenario, list which of these log types it needs. A common exam trap is assuming resource logs show up without a diagnostic setting. They don't.
Step 2: Decide how many workspaces you need
Microsoft's guidance is clear: start with a single workspace, and add more only when a specific requirement forces it. Use the fewest workspaces that meet the requirements. The amount of data in a workspace doesn't limit its performance.
These requirements justify an extra workspace:
- Data residency: each workspace lives in one Azure region. If EU data must stay in Europe, create a workspace there.
- Multiple Microsoft Entra tenants: most resources can send data only to a workspace in their own tenant, so you usually need one workspace per tenant.
- Data ownership: subsidiaries that need their data segregated.
- Split billing: this applies only if Cost Management or a usage query can't report costs in enough detail.
- Different retention for the same table: retention is set per table, so different settings for different resources need separate workspaces.
- Security and operations separation: you can give Microsoft Sentinel its own workspace, or combine it with operational data for wider visibility.
These factors favour consolidating:
- Commitment tiers apply to the volume in a single workspace. Spreading data across workspaces can lose the discount, unless the workspaces share a dedicated cluster.
- Querying and managing one workspace is simpler.
Step 3: Control access inside a workspace
You don't need a separate workspace just to restrict who sees what. Use these options instead:
- Workspace permissions: users see all data in the workspace. This suits central operations or security teams.
- Resource-context access: under the default access control mode, Use resource or workspace permissions, anyone with read access to a resource can see that resource's logs.
- Require workspace permissions: change to this mode when every user must be granted access explicitly.
- Table-level RBAC: grant or deny access to specific tables. For example, you can hide security tables from application teams.
Step 4: Choose a table plan for each table
The plan is set per table. Azure tables use Analytics by default.
| Analytics | Basic | Auxiliary (shown in the portal as Auxiliary / Lake) | |
|---|---|---|---|
| Best for | High-value data for continuous monitoring and real-time detection | Medium-touch data for troubleshooting and incident response | Low-touch, verbose data kept for audit and compliance |
| Ingestion cost | Standard | Reduced | Minimal |
| Query charge | Included | Billed per query | Billed per query |
| Alerts | Yes | Simple log alerts | No |
| Insights | Yes | No | No |
| Query performance | Optimized | Optimized | Slower |
Two more rules:
- Not every Azure table supports Basic or Auxiliary. Custom tables based on data collection rules support all three plans.
- You can switch a table's plan only once a week.
Step 5: Set retention
- Analytics retention is the period when data can be queried interactively. The default is 30 days, or 90 days for Microsoft Sentinel and Application Insights tables. You can extend it to two years on Analytics tables.
- Basic tables have a fixed 30-day query period. Auxiliary data can be queried for its whole total retention period, though queries are slower.
- Total retention can be set up to 12 years on any plan. After the Analytics period ends, the remaining time is low-cost long-term retention. You read Analytics and Basic data in that period with a search job.
Do: Match retention to the compliance requirement, not to habit. Thirty-one days of retention are included in the Analytics ingestion price, so setting a shorter period saves nothing.
Case study: Fabrikam Retail
Requirements:
- Stores operate in the UK and the US.
- UK log data must stay in the UK.
- Store application teams may see only their own resources' logs.
- Firewall logs are very large and are queried only during audits, but must be kept for 7 years.
- Security alerts must fire in near real time.
Recommendation:
- Create two workspaces, one in UK South and one in a US region, because of the residency requirement.
- Keep the default resource-context access mode, so application teams see only their resources.
- Put the security event tables that drive alerts on the Analytics plan.
- Send the verbose firewall logs to a table on the Auxiliary plan, with total retention set to 7 years.
- Enable diagnostic settings for the resource logs, and deploy AMA with DCRs to the VMs.
What the exam asks about this
- One workspace or several: expect scenarios where residency, multiple tenants or ownership is the only valid reason to add a workspace. "Easier access control" is not a valid reason, because RBAC options cover it.
- Plan from usage: "queried rarely, kept for years, lowest cost" points to Auxiliary. "Needs alerts and Insights" points to Analytics. "Occasional troubleshooting" points to Basic.
- Where logs land: know that resource logs need diagnostic settings, guest OS data needs AMA with DCRs, and the activity log is kept for 90 days unless you export it.
Key takeaways
- Start with one Log Analytics workspace. Add workspaces only for residency, tenant, ownership, billing or retention requirements.
- Restrict access with resource-context access and table-level RBAC rather than extra workspaces.
- Analytics suits real-time use and alerting, Basic suits troubleshooting, and Auxiliary is the cheapest option for long-term audit data.
- Analytics retention can be extended to 2 years, and total retention to 12 years.
- The activity log is automatic and kept for 90 days. Resource logs need a diagnostic setting. Guest OS logs need AMA with a DCR. Application logs come from Application Insights.