AZ-305Chapter 62 of 103Objective 1.3

Log Analytics Workspace Design

This chapter covers the design and configuration of Log Analytics workspaces in Azure, a critical component for centralizing and analyzing log data. For the AZ-305 exam, understanding Log Analytics workspace design is essential, as it underpins monitoring, security, and compliance solutions. Approximately 10-15% of exam questions touch on Log Analytics workspaces, often in the context of designing monitoring and identity governance solutions. This chapter will provide a deep dive into workspace architecture, retention policies, data collection, and integration with other Azure services.

25 min read
Intermediate
Updated May 31, 2026

Log Analytics Workspace as a Filing Cabinet

Imagine a large office with many departments: HR, Finance, IT, and Operations. Each department generates documents (logs) daily. To manage these, the office has a central filing cabinet (Log Analytics workspace). Each department has its own drawer (table) in the cabinet, but all drawers share the same cabinet structure (schema). The cabinet has a capacity limit (500 GB/day free ingestion) and a retention policy: documents in any drawer are automatically shredded after 30 days (default retention) unless you pay for longer storage (adjustable retention up to 730 days). Each drawer can be configured with a different shredding schedule (table-level retention). The office manager can set a global shredding policy (workspace-level retention) that applies to all drawers unless overridden. If a department sends too many documents (high-volume logs), the cabinet might overflow, and you must either upgrade to a bigger cabinet (scale to multiple workspaces) or set rules to discard less important documents (data collection rules). The filing cabinet is locked (RBAC) so only authorized personnel can access specific drawers. You can also connect the cabinet to a central dashboard (Azure Monitor) to see summaries of all documents across drawers.

How It Actually Works

What is a Log Analytics Workspace?

A Log Analytics workspace is a unique environment for log data from Azure Monitor and other Azure services. Each workspace has its own data repository, configuration, and permissions. Data ingested into a workspace is stored in tables, each with a specific schema. The workspace is the fundamental unit of management for log data in Azure.

Why Use a Log Analytics Workspace?

Workspaces enable centralized log collection from multiple sources: Azure resources, on-premises servers, and other clouds. They support advanced querying with Kusto Query Language (KQL), alerting, and integration with Azure Sentinel, Azure Security Center, and other monitoring tools. For identity governance, workspaces can store sign-in logs, audit logs, and risk events from Azure AD.

How It Works Internally

When data is sent to a workspace, it goes through ingestion pipelines. The Log Analytics agent (or Azure Monitor Agent) collects data and sends it to the workspace's ingestion endpoint. The data is processed, indexed, and stored in tables. Each table has a retention policy: by default, 30 days for all tables, but you can adjust it per table. Data is stored in Azure Blob Storage, with hot and cold tiers. Queries are executed against the data using KQL, which scans the relevant tables.

Key Components

Tables: Each workspace has predefined tables (e.g., AzureActivity, SigninLogs, SecurityEvent). Custom tables can be created via data collection rules.

Retention: Workspace-level default retention (30-730 days). Table-level retention overrides workspace default. Data can also be archived to a storage account using continuous export.

Pricing Tier: Pay-as-you-go or Capacity Reservations. The free tier is limited to 500 MB/day and 7-day retention.

Data Collection Rules (DCRs): Define how data is collected and transformed before ingestion. They specify data sources, destinations (workspace or table), and transformations.

Workspace ID and Key: Used by agents and APIs to authenticate and send data.

Default Values and Timers

Default retention: 30 days for all tables.

Maximum retention: 730 days (2 years) for most tables; some tables have longer limits (e.g., Usage table is 2 years).

Ingestion latency: Typically 5-10 minutes for most data; near real-time for some sources.

Data export: Continuous export to Azure Storage or Event Hubs can be configured with a 1-hour latency.

Configuration and Verification

To create a workspace via CLI:

az monitor log-analytics workspace create --resource-group myRG --workspace-name myWorkspace --location eastus --sku PerGB2018

To view retention:

az monitor log-analytics workspace show --resource-group myRG --workspace-name myWorkspace --query retentionInDays

To set table-level retention (e.g., AzureActivity table to 90 days):

az monitor log-analytics workspace table update --resource-group myRG --workspace-name myWorkspace --table-name AzureActivity --retention-in-days 90

Interaction with Related Technologies

Azure Monitor: Workspaces are the core data store for Azure Monitor logs.

Azure Sentinel: Uses workspaces as its data repository; each Sentinel instance is tied to a workspace.

Azure Security Center: Stores security alerts and recommendations in workspaces.

Azure AD: Sends sign-in and audit logs to workspaces via diagnostics settings.

Azure Policy: Can enforce workspace creation and configuration across subscriptions.

Design Considerations

Workspace Number: Typically one workspace per region for latency optimization, but can consolidate for cross-region queries. For compliance, separate workspaces per environment (dev, prod) or per business unit.

Access Control: Use Azure RBAC to grant read/write permissions. Table-level RBAC is possible via custom roles.

Data Volume: Monitor ingestion to avoid exceeding budget. Use data collection rules to filter out noisy data.

Retention and Archiving: Adjust retention based on compliance needs. Use continuous export for long-term storage.

Integration with Azure AD: Enable diagnostics settings to stream sign-in and audit logs to workspace. This is crucial for identity governance scenarios.

Troubleshooting

No Data: Check agent connectivity, workspace ID/key, and firewall rules. Verify diagnostics settings are enabled.

High Latency: Ingestion can be delayed if workspace is in a different region than data source. Use same region if possible.

Quota Exceeded: Workspace has a daily ingestion cap (default 500 MB/day for free tier). Upgrade to paid tier or set a daily cap.

Security and Compliance

Workspace data is encrypted at rest using Microsoft-managed keys (MMK) or customer-managed keys (CMK). CMK requires Azure Key Vault.

Network isolation: Use private endpoints to ingest data without traversing the internet.

Audit: Workspace activity is logged in Azure Activity Log.

Summary

Log Analytics workspaces are central to Azure monitoring and security. Proper design ensures efficient data collection, cost management, and compliance with retention policies. For AZ-305, focus on workspace creation, retention configuration, data collection rules, and integration with Azure AD for identity governance.

Walk-Through

1

Create Log Analytics Workspace

First, you must create a Log Analytics workspace in an Azure region. Use the Azure portal, CLI, or PowerShell. Specify a name, subscription, resource group, and region. Choose a pricing tier: Per GB 2018 (pay-as-you-go) or Capacity Reservations (commitment tiers). The workspace is assigned a unique workspace ID and primary key, used by agents and APIs to send data. The default retention is 30 days, which can be changed later. The workspace is the container for all log data.

2

Configure Data Sources

Connect data sources to the workspace. For Azure resources, enable diagnostics settings to stream metrics and logs to the workspace. For virtual machines, install the Log Analytics agent or Azure Monitor Agent. For Azure AD, configure diagnostics settings to send sign-in logs and audit logs. For custom applications, use the HTTP Data Collector API. Each data source sends data to specific tables in the workspace based on the data type.

3

Set Retention and Archiving Policies

Define how long data is retained. The workspace default retention is 30 days, but you can increase it up to 730 days. You can also set table-level retention to override the default for specific tables. For long-term storage, configure continuous export to Azure Storage or Event Hubs. The export runs every hour and moves data older than a specified age. Data in the workspace is deleted after the retention period expires.

4

Implement Access Control

Use Azure RBAC to control who can read/write data in the workspace. Assign roles like Log Analytics Reader, Log Analytics Contributor, or custom roles. You can also use table-level RBAC to restrict access to specific tables. For example, grant security analysts read access to `SecurityEvent` table but not to `Heartbeat` table. Use Azure AD groups for easier management.

5

Create Data Collection Rules

Data Collection Rules (DCRs) define how data is collected and transformed. They specify which data sources to collect, how to filter or transform the data, and which table to send it to. DCRs are used primarily with the Azure Monitor Agent. You can create DCRs in the Azure portal or via CLI. They allow you to reduce data volume by filtering out unneeded logs, saving costs.

6

Integrate with Azure Sentinel

If using Azure Sentinel, enable it on the workspace. Sentinel uses the workspace as its data repository. You must assign the Sentinel role to users. Sentinel adds additional tables (e.g., `SecurityAlert`, `SecurityIncident`) and enables advanced analytics and threat detection. Ensure the workspace is in a supported region and has sufficient retention for compliance.

What This Looks Like on the Job

Enterprise Scenario 1: Centralized Monitoring for Multi-Region Deployment

A global company with Azure resources in US East, West Europe, and Southeast Asia needs to collect logs from all regions. They create one Log Analytics workspace per region to reduce latency and data transfer costs. Each workspace collects logs from local resources. For cross-region queries, they use Azure Monitor Workbooks that query multiple workspaces. They set retention to 90 days for all workspaces and use continuous export to a central storage account for long-term archival. The challenge is managing multiple workspaces; they use Azure Policy to enforce consistent configuration across workspaces. When misconfigured, they might miss cross-region correlation, so they implement a query that unions data from all workspaces.

Scenario 2: Identity Governance with Azure AD Logs

A financial institution must monitor Azure AD sign-in and audit logs for compliance. They create a dedicated workspace for identity logs. They configure diagnostics settings to stream Azure AD logs to this workspace. They set retention to 365 days for the SigninLogs and AuditLogs tables. They grant the security team Log Analytics Reader access to the workspace. They create alerts for suspicious sign-ins (e.g., from unknown IPs). They also integrate with Azure Sentinel for advanced threat detection. A common problem is high volume of logs; they use data collection rules to filter out successful sign-ins from trusted IPs, reducing costs. If retention is too short, they risk non-compliance; if too long, costs increase. They set a daily cap to avoid budget overruns.

Scenario 3: IT Operations Monitoring with Custom Logs

A SaaS company runs thousands of VMs and containers. They create a single workspace for all operational logs. They use the Azure Monitor Agent with data collection rules to collect syslog, Windows event logs, and custom application logs. They set table-level retention: 30 days for performance metrics, 90 days for error logs, and 730 days for audit logs. They use KQL to create dashboards for real-time monitoring. They also configure continuous export to a storage account for logs older than 90 days for future analysis. A misconfiguration could be accidentally setting retention too high on high-volume tables, causing unexpected costs. They monitor daily ingestion using Usage table queries and set alerts for ingestion spikes.

How AZ-305 Actually Tests This

What AZ-305 Tests on This Topic

The AZ-305 exam objectives include designing a Log Analytics workspace strategy under 'Design a monitoring solution for identity governance' (objective 1.3). Specific topics tested:

Workspace creation and location selection.

Retention policies (default 30 days, max 730 days).

Data collection rules for filtering.

Integration with Azure AD diagnostics settings.

Access control using RBAC.

Cost management (pricing tiers, daily cap).

Continuous export for long-term storage.

Common Wrong Answers and Why Candidates Choose Them

1.

Choosing multiple workspaces per region for redundancy: Candidates think multiple workspaces provide high availability, but workspaces are highly available by default. The correct reason for multiple workspaces is compliance or data sovereignty.

2.

Setting retention to 730 days for all tables: While 730 days is the max, the exam expects you to consider cost. High-volume tables should have shorter retention. The exam tests table-level retention vs workspace-level.

3.

Using the Log Analytics agent instead of Azure Monitor Agent: The exam emphasizes the Azure Monitor Agent as the modern replacement. The Log Analytics agent is legacy.

4.

Enabling continuous export on the workspace without specifying a table: Continuous export is per table, not per workspace. Candidates often think it's workspace-wide.

Specific Numbers and Terms That Appear on the Exam

Default retention: 30 days.

Maximum retention: 730 days (2 years).

Free tier: 500 MB/day, 7-day retention.

Pricing tier: Per GB 2018.

Data collection rules (DCRs).

Workspace ID and primary key.

Continuous export to Azure Storage or Event Hubs.

Table-level retention overrides workspace default.

Edge Cases and Exceptions

Workspace deletion: Deleting a workspace permanently removes all data; soft delete is not available.

Data export latency: Continuous export has a 1-hour latency.

Cross-workspace queries: You can query up to 100 workspaces in a single query.

Table schema changes: Adding custom columns to a table requires a data collection rule with a transformation.

How to Eliminate Wrong Answers

If a question asks about cost optimization, look for options that filter data (DCRs) or reduce retention.

If the question mentions compliance with retention, ensure the retention period meets the requirement (e.g., 1 year = 365 days).

For access control, check if the role is Log Analytics Reader (read-only) or Contributor (can create alerts).

For integration with Azure AD, the question will mention 'diagnostics settings' – not 'resource logs'.

Key Takeaways

Default retention for Log Analytics workspace is 30 days; max is 730 days.

Table-level retention overrides workspace-level retention.

Continuous export is per table, not per workspace, and has ~1 hour latency.

Azure Monitor Agent is the recommended agent; Log Analytics agent is legacy.

Data collection rules (DCRs) filter and transform data before ingestion.

Azure AD logs (sign-in and audit) are streamed via diagnostics settings.

RBAC roles: Log Analytics Reader (read), Log Analytics Contributor (write).

Free tier: 500 MB/day ingestion, 7-day retention.

Workspace ID and key are used for authentication by agents and APIs.

Cross-workspace queries support up to 100 workspaces.

Easy to Mix Up

These come up on the exam all the time. Here's how to tell them apart.

Single Workspace

Simpler management – one workspace to monitor.

Cross-resource queries are easier (all data in one place).

Costs are centralized; one daily cap applies.

Latency may be higher if data sources are in different regions.

Compliance may be harder if data must reside in specific regions.

Multiple Workspaces

Better latency by placing workspaces near data sources.

Can isolate data for compliance (e.g., per region or per business unit).

Costs can be separated per workspace (chargeback).

More complex management and cross-workspace queries require union.

Higher administrative overhead.

Watch Out for These

Mistake

A Log Analytics workspace can only be in one region, but data can be ingested from any region.

Correct

Data can be ingested from any region, but to reduce latency and egress costs, it's best to create workspaces in the same region as the data sources.

Mistake

Retention is set at the workspace level and cannot be changed for individual tables.

Correct

You can set table-level retention that overrides the workspace default. This is done via CLI or PowerShell.

Mistake

The free tier of Log Analytics workspaces allows unlimited data ingestion.

Correct

The free tier has a daily limit of 500 MB. Exceeding it causes data to be dropped for the rest of the day.

Mistake

Continuous export automatically exports all tables in the workspace.

Correct

Continuous export must be configured per table. Not all tables support export; check documentation.

Mistake

Data in a Log Analytics workspace is immediately available for query after ingestion.

Correct

There is typically a 5-10 minute ingestion latency. Some data sources may have near real-time latency, but it's not instant.

Do You Actually Know This?

Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.

Frequently Asked Questions

How do I change the retention period for a specific table in a Log Analytics workspace?

Use the Azure CLI command `az monitor log-analytics workspace table update --resource-group <RG> --workspace-name <workspace> --table-name <table> --retention-in-days <days>`. This overrides the workspace default for that table. For example, to set `AzureActivity` table to 90 days, run: `az monitor log-analytics workspace table update --resource-group myRG --workspace-name myWS --table-name AzureActivity --retention-in-days 90`. Note that retention cannot be set below the workspace default; you can only increase it.

What is the difference between a Log Analytics workspace and an Application Insights resource?

A Log Analytics workspace is a central repository for log data from multiple sources, while Application Insights is for application performance monitoring (APM). Application Insights can send its data to a Log Analytics workspace, enabling cross-resource queries. For AZ-305, know that Application Insights uses a separate resource type but can be integrated with workspaces.

Can I query multiple Log Analytics workspaces in a single query?

Yes, using the `workspace()` function in KQL. For example: `union workspace('workspace1').AzureActivity, workspace('workspace2').AzureActivity`. The query can include up to 100 workspaces. This is useful for cross-region or cross-subscription reporting.

How do I reduce the cost of Log Analytics?

Use data collection rules to filter out unnecessary logs, set a daily cap on ingestion, adjust retention periods (shorter for high-volume tables), use Capacity Reservations for predictable volumes, and enable continuous export to move old data to cheaper storage. Also, consider using Basic Logs tier for verbose logs that are rarely queried.

What happens when I delete a Log Analytics workspace?

The workspace and all its data are permanently deleted within 14 days. There is no soft delete option. You cannot recover the data after deletion. Ensure you have backups or continuous export before deleting.

Terms Worth Knowing

Ready to put this to the test?

You've just covered Log Analytics Workspace Design — now see how well it sticks with free AZ-305 practice questions. Full explanations included, no account needed.

Done with this chapter?