This chapter covers the design, configuration, and management of Log Analytics workspaces in Azure, focusing on data retention and archiving policies. For the AZ-104 exam, this topic is part of Objective 5.1 (Monitor and manage Azure resources by using Azure Monitor) and appears in approximately 5-10% of exam questions. Understanding workspace design—especially retention settings, table-level configurations, and cost implications—is critical for both the exam and real-world administration, as misconfiguration can lead to data loss or unexpected costs.
Jump to a section
Imagine a large office with a central filing cabinet used by every department. Each department generates documents (logs) of different types—sales reports, IT incident forms, HR records—each with its own retention requirements. The filing cabinet has drawers (tables) and folders (columns). You, as the office manager, configure how long each type of document is kept before shredding. Some documents, like compliance records, must be kept for 7 years; others, like daily temperature logs, are shredded after 30 days. You can also set a default retention for any document that doesn't have a specific rule. The cabinet has a limited capacity, so you might need to buy more cabinets (scale up) or link multiple cabinets together (linked workspaces). You can also set up a rule that certain documents are automatically moved to a secure archive (long-term retention) after a period. If you misconfigure the retention—say, set compliance records to 30 days—you risk legal penalties. Similarly, if you set everything to 7 years, you'll run out of space quickly and incur high costs. The filing cabinet analogy directly mirrors how Log Analytics workspaces store data in tables with configurable retention policies, default retention of 30 days, and the ability to set specific retention for individual tables. Archival policies move older data to cheaper storage, analogous to moving documents to a basement archive.
What is a Log Analytics Workspace?
A Log Analytics workspace is a unique Azure environment for storing log data from Azure Monitor and other Azure services. Each workspace has its own data repository, configuration, and permissions. Data is organized into tables, each with a schema specific to the data source (e.g., AzureActivity, Heartbeat, SecurityEvent). You can have multiple workspaces in a subscription, but best practice is to minimize the number to simplify management and querying.
Why Retention Matters
Retention policies determine how long data is kept in the workspace before being removed. The default retention for all tables in a workspace is 30 days, but you can extend it up to 730 days (2 years) for most tables, and up to 7 years for tables that support long-term retention via archive. Retention is set at the workspace level initially, but can be overridden per table. The exam tests your ability to choose the correct retention settings based on compliance, cost, and query needs.
How Retention Works Internally
When data is ingested into a Log Analytics workspace, it is stored in hot storage for the duration of the interactive retention period. During this time, data is available for fast, interactive queries. After the interactive retention period ends, data can be moved to an archive tier (if configured) where it is stored at a lower cost but requires a search job or restore to query. Once the total retention period (interactive + archive) expires, data is permanently deleted. The default interactive retention is 30 days; you can extend it up to 730 days. Archive retention can extend total retention up to 7 years (2,555 days).
Key Components and Defaults
Workspace-level retention: Applies to all tables by default. Set in days (30 to 730). Default: 30 days.
Table-level retention: Overrides workspace retention for a specific table. Can be set between 4 and 730 days. If you set table retention to less than workspace retention, the workspace retention is ignored for that table. If you set it higher, the table retention applies.
Archive retention: Available for tables that support it (e.g., ContainerLog, InsightsMetrics, and many others). You can set archive retention from 30 days up to 2,555 days (7 years) from the time of ingestion. The interactive retention must be at least 4 days, but the total (interactive + archive) cannot exceed 2,555 days.
Data expiration: Data is deleted exactly after the retention period ends, based on the ingestion timestamp. Deletion is permanent and cannot be undone.
Cost: Interactive retention is more expensive per GB per month. Archive retention is about 1/10th the cost. Queries on archived data require a search job (charged per GB scanned) or restore (charged per GB restored).
Configuration and Verification Commands
You can configure retention via Azure portal, Azure CLI, or PowerShell.
Azure CLI to set workspace retention:
az monitor log-analytics workspace update --resource-group myRG --workspace-name myWorkspace --retention-time 365Azure CLI to set table-level retention:
az monitor log-analytics workspace table update --resource-group myRG --workspace-name myWorkspace --table-name Heartbeat --retention-time 90Azure CLI to set archive retention (interactive + archive):
az monitor log-analytics workspace table update --resource-group myRG --workspace-name myWorkspace --table-name ContainerLog --retention-time 30 --total-retention-time 365Here, interactive retention is 30 days, archive retention is 335 days (365-30).
PowerShell equivalent:
Update-AzOperationalInsightsTable -ResourceGroupName myRG -WorkspaceName myWorkspace -TableName Heartbeat -RetentionInDays 90Verification:
az monitor log-analytics workspace table list --resource-group myRG --workspace-name myWorkspace --output tableThis shows retention and totalRetention for each table.
Interaction with Related Technologies
Azure Monitor: Log Analytics workspaces are the destination for Azure Monitor logs. Diagnostic settings send logs from Azure resources to workspaces.
Azure Sentinel: Uses Log Analytics workspaces as its data store. Sentinel requires workspace retention of at least 90 days.
Azure Policy: Can enforce retention settings on workspaces via built-in or custom policies.
Data Export: You can export data from a workspace to a storage account or Event Hub, which can be used for long-term archival beyond 7 years.
Linked workspaces: Not directly related to retention, but you can link multiple workspaces together for querying across them.
Retention Scenarios
Compliance: If regulations require log retention for 5 years, you cannot achieve this with Log Analytics alone (max 7 years). You would need to export data to Azure Storage or use archive retention for up to 7 years. For 5 years, archive retention works (365*5=1825 days, within 2555 limit).
Cost optimization: For tables with low query frequency, set a short interactive retention (e.g., 30 days) and enable archive retention for longer periods. This reduces hot storage costs.
Security monitoring: For security tables (e.g., SecurityEvent), you may need longer interactive retention for fast investigation. Set interactive retention to 90-365 days, and archive for up to 2 years.
Exam Traps
The exam may present a scenario where you need to retain data for 3 years. The correct answer is to use archive retention (total retention up to 7 years) or export to storage. Many candidates mistakenly think you can set workspace retention to 1095 days, but workspace retention maxes at 730 days.
Another trap: setting table-level retention to a value lower than workspace retention. The table retention overrides the workspace retention for that table, which can cause unexpected data deletion if not careful.
The exam also tests that archive retention is only available for certain tables (not all). You must check table support. For example, the 'Usage' table does not support archive.
Step-by-Step Configuration
Create a Log Analytics workspace in the Azure portal or via CLI.
Set workspace-level retention (default 30 days).
For tables requiring different retention, configure table-level retention.
For tables supporting archive, set total retention (interactive + archive) up to 7 years.
Verify settings using Azure Monitor Logs queries (e.g., Usage table shows data volume and retention).
Monitoring Retention
You can use the Usage table to track data ingestion and retention. Query:
Usage | where TimeGenerated > ago(30d) | summarize Total=sum(Quantity) by DataType, UnitThis shows how much data each table is consuming. To check retention settings per table, use the Azure portal or CLI.
Assess Compliance and Query Needs
Before designing a workspace, identify regulatory requirements (e.g., HIPAA, GDPR, PCI DSS) that dictate minimum retention periods. Also, determine which logs need fast interactive queries (e.g., security incidents) versus those that are rarely accessed. This assessment drives the retention and archiving strategy. For example, financial audit logs may need 7-year retention with occasional queries, while application performance logs may need only 30 days of interactive access. Document these requirements for each log type (table).
Create Log Analytics Workspace
In the Azure portal, navigate to Log Analytics workspaces and click Create. Choose a subscription, resource group, and unique workspace name. Select a region close to your resources to minimize latency and egress costs. The workspace will have a default retention of 30 days. After creation, note the workspace ID and primary key for agent configuration. For exam purposes, remember that workspace names are globally unique within a resource group.
Configure Workspace-Level Retention
Set the default retention period for all tables in the workspace. In the Azure portal, under the workspace's 'Usage and estimated costs' or 'Data retention' blade, adjust the slider from 30 to 730 days. This setting applies to all tables that do not have an explicit table-level retention override. For example, if you set workspace retention to 365 days, all tables will retain data for 365 days unless overridden. Use this for a baseline policy.
Override Retention for Specific Tables
For tables that require different retention (e.g., SecurityEvent needs 90 days, but Heartbeat only 30 days), configure table-level retention. In the Azure portal, go to Tables under the workspace, select a table, and set 'Retention (in days)'. This value can be between 4 and 730 days. If you set it lower than workspace retention, the table retention takes precedence. For example, if workspace retention is 365 days but you set Heartbeat to 30 days, Heartbeat data will be deleted after 30 days.
Enable and Configure Archive Retention
For tables that support archiving (e.g., ContainerLog, InsightsMetrics), enable archive retention by setting 'Total retention (in days)' to a value greater than interactive retention. Interactive retention must be at least 4 days. Total retention cannot exceed 2,555 days (7 years). For example, set interactive to 30 days and total to 365 days to archive data from day 31 to day 365. Archived data is stored in a lower-cost tier but requires a search job or restore to query. The exam tests that archive is not available for all tables (e.g., Usage table).
Verify and Monitor Retention Settings
After configuration, verify settings using Azure CLI or PowerShell. Run `az monitor log-analytics workspace table list` to see retention and totalRetention for each table. Also, monitor data volume and retention compliance using the `Usage` table in Log Analytics. Example query: `Usage | where TimeGenerated > ago(30d) | summarize by DataType, RetentionInDays`. This helps ensure that retention policies are applied correctly and that no unexpected data loss occurs. Adjust settings if needed based on changing requirements.
Scenario 1: Enterprise Compliance for Financial Services
A financial services company must retain all Azure activity logs and security events for 5 years to comply with SEC regulations. They create a Log Analytics workspace with workspace-level retention set to 730 days (max). For tables like AzureActivity and SecurityEvent, they set total retention to 1825 days (5 years) with interactive retention of 365 days. This allows fast queries for the first year, and archived data for the remaining 4 years. They also set up a data export rule to Azure Storage for a secondary backup beyond 7 years. The challenge is cost: interactive retention is expensive, so they limit it to only high-priority tables. Misconfiguration: if they accidentally set workspace retention to 730 days and forget to set table-level total retention, data older than 730 days is permanently deleted, causing compliance violation. They mitigate this by using Azure Policy to enforce minimum retention on critical tables.
Scenario 2: Cost Optimization for a SaaS Provider
A SaaS provider collects telemetry from thousands of customer environments into a single Log Analytics workspace. Most logs (e.g., Heartbeat, Perf) are only needed for troubleshooting recent issues and can be deleted after 30 days. However, error logs (e.g., AzureDiagnostics) need 90 days of interactive access for root cause analysis. They set workspace retention to 30 days, then override AzureDiagnostics table retention to 90 days. They do not use archive because the data is not needed beyond 90 days. This minimizes cost because most tables are purged quickly. A common mistake: setting workspace retention to 90 days and then trying to lower it for Heartbeat—this works but the workspace retention is effectively ignored for Heartbeat. The exam likes to test that table-level retention can be lower than workspace-level.
Scenario 3: Security Operations Center (SOC) with Azure Sentinel
A SOC uses Azure Sentinel, which requires a Log Analytics workspace with at least 90 days retention. They set workspace retention to 90 days. For security tables (SecurityEvent, CommonSecurityLog), they set interactive retention to 90 days and total retention to 365 days to allow investigation of year-old incidents. They also enable Sentinel's UEBA analytics, which requires data retention of at least 180 days. The mistake: setting workspace retention to 90 days but forgetting that Sentinel's built-in tables (e.g., SecurityAlert) might have different default retention. They verify using Usage table and adjust. The exam may test that Sentinel requires a minimum of 90 days retention, and that you cannot reduce it below that without breaking Sentinel functionality.
What AZ-104 Tests on This Topic (Objective 5.1)
The exam focuses on your ability to configure and manage Log Analytics workspace retention and archiving. Specific areas include: - Default retention: 30 days. You must know this. - Maximum interactive retention: 730 days (2 years). - Maximum total retention (interactive + archive): 2,555 days (7 years). - Table-level retention overrides workspace-level retention. - Archive retention is only available for specific tables (e.g., ContainerLog, InsightsMetrics, but not Usage). - Cost implications: Archive storage is cheaper than interactive. - Querying archived data: Requires a search job or restore (additional cost). - Azure Sentinel requirement: Minimum 90 days retention.
Common Wrong Answers and Why Candidates Choose Them
Wrong answer: Setting workspace retention to 2555 days (7 years). Why candidates choose it: They think workspace retention can be extended to 7 years. Reality: Workspace retention max is 730 days. For 7 years, you must use table-level total retention with archive.
Wrong answer: Setting table-level retention to a value lower than workspace retention causes workspace retention to apply. Why: Candidates misunderstand precedence. Reality: Table-level retention overrides workspace retention, even if lower.
Wrong answer: Archive retention is available for all tables. Why: Candidates assume archive is universal. Reality: Only certain tables support archive. Check documentation.
Wrong answer: Data in archive can be queried using normal KQL queries. Why: Candidates think archive is just a cheaper tier with same query capabilities. Reality: Archived data requires a search job or restore, which is slower and costs extra.
Specific Numbers and Terms That Appear on the Exam
30 days (default)
730 days (max interactive)
2,555 days (max total)
4 days (minimum interactive retention for tables with archive)
7 years (max total retention)
'Usage' table does not support archive
'Search job' and 'Restore' are methods to query archived data
Edge Cases and Exceptions
If you set table-level retention to 4 days and enable archive, interactive retention is 4 days, archive can be up to 2551 days (2555-4).
If you disable archive, total retention equals interactive retention.
Changing retention settings does not affect existing data retroactively; it only applies to newly ingested data? No, retention changes apply to all existing data. If you extend retention, existing data is kept longer. If you shorten retention, existing data older than the new retention is deleted within a few days.
Data deletion is not immediate; it may take up to 7 days after retention period ends.
How to Eliminate Wrong Answers
If a question asks for a retention period >730 days, eliminate any answer that only sets workspace retention. Look for answers that mention 'table-level total retention' or 'archive'.
If a question asks about querying old data, eliminate answers that suggest normal KQL queries on archive. Look for 'search job' or 'restore'.
If a question involves cost, remember that interactive is more expensive. Answers that suggest keeping all data in interactive for 7 years are wrong due to cost.
For Sentinel, any answer with retention <90 days is wrong.
Default Log Analytics workspace retention is 30 days.
Maximum interactive retention is 730 days (2 years).
Maximum total retention (interactive + archive) is 2,555 days (7 years).
Table-level retention overrides workspace-level retention.
Archive retention is only available for specific tables (e.g., ContainerLog, InsightsMetrics).
Querying archived data requires a search job or restore, incurring additional costs.
Azure Sentinel requires a minimum of 90 days retention in the workspace.
Data deletion occurs after retention period ends, typically within 7 days.
Workspace retention cannot be set to more than 730 days; use table-level total retention for longer periods.
Cost: interactive storage is more expensive than archive storage.
These come up on the exam all the time. Here's how to tell them apart.
Workspace-Level Retention
Applies to all tables by default
Set between 30 and 730 days
Cannot exceed 730 days
Is overridden by table-level retention if set
Simplicity: single setting for entire workspace
Table-Level Retention
Applies only to a specific table
Set between 4 and 730 days
Can be lower or higher than workspace retention
Overrides workspace retention for that table
Granular control: different retention per log type
Mistake
Workspace retention can be set up to 7 years (2555 days).
Correct
Workspace retention max is 730 days (2 years). To achieve 7 years, you must use table-level total retention with archive, which is only available for specific tables.
Mistake
Table-level retention must be higher than workspace retention.
Correct
Table-level retention can be lower than workspace retention. It overrides the workspace setting. For example, if workspace retention is 365 days, you can set a table to 30 days, and that table's data will be deleted after 30 days.
Mistake
Archive retention is available for all Log Analytics tables.
Correct
Archive retention is only supported for certain tables, such as ContainerLog, InsightsMetrics, and many others. Tables like 'Usage' do not support archive.
Mistake
Data in archive can be queried using standard KQL queries without additional cost.
Correct
Archived data cannot be queried with standard interactive queries. You must run a search job (charged per GB scanned) or restore data (charged per GB restored) to make it queryable.
Mistake
Changing retention settings only affects new data, not existing data.
Correct
Retention changes apply to all existing data. If you increase retention, existing data is kept longer. If you decrease retention, existing data older than the new retention will be deleted (within a few days).
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
The default retention period is 30 days. You can change it to any value between 30 and 730 days. For tables that support archive, you can extend total retention up to 2,555 days (7 years) using table-level settings.
No, workspace-level retention maxes out at 730 days. To retain data longer, you must use table-level total retention with archive, which allows up to 2,555 days (7 years) from ingestion. Alternatively, you can export data to Azure Storage for indefinite retention.
You cannot query archived data with standard interactive queries. You need to use a search job (which scans the archived data and returns results) or restore data to a temporary table for interactive querying. Both incur additional costs based on the amount of data scanned or restored.
Interactive retention is the period during which data is stored in hot storage and available for fast, interactive queries. Total retention includes interactive plus archive retention. After interactive retention ends, data moves to archive (if enabled) and is stored at lower cost. Once total retention expires, data is permanently deleted.
Yes, table-level retention overrides workspace-level retention for that specific table. If you set table retention to a value, that value applies regardless of the workspace setting. For example, if workspace retention is 365 days but table retention is 30 days, data in that table is deleted after 30 days.
Archive retention is supported for many tables, including ContainerLog, InsightsMetrics, Heartbeat, SecurityEvent, and others. However, not all tables support archive. For example, the 'Usage' table does not support archive. You can check table support in the Azure documentation or via the Azure portal table properties.
Data is permanently deleted. The deletion process may take up to 7 days after the retention period ends. There is no way to recover deleted data. Therefore, ensure retention settings meet compliance and operational needs before data is purged.
You've just covered Log Analytics Workspace Design and Data Retention — now see how well it sticks with free AZ-104 practice questions. Full explanations included, no account needed.
Done with this chapter?