This post is a part of the "SC-500: Implementing End-to-End Security Controls for Cloud and AI Workloads" Exam Prep Hub.
This topic falls under these sections:
Manage and monitor security posture (20–25%)
--> Implement activity and event collection in Microsoft Sentinel
--> Implement data retention in Microsoft Sentinel data stores
Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 4 practice tests with 30 questions each available from the hub's main page below the exam topics section.
Introduction
Microsoft Sentinel collects large volumes of security data from cloud services, applications, operating systems, network devices, identity systems, and security products. Not all of that data needs to remain immediately available for real-time investigation.
For example:
- Authentication logs may be needed for active threat hunting.
- Firewall logs may need to be retained for compliance and historical investigations.
- Detailed diagnostic logs may have limited day-to-day value but significant forensic value.
- Regulatory requirements may require security records to be retained for several years.
Data retention in Microsoft Sentinel provides a way to balance these requirements against storage and query costs.
For the SC-500 exam, it is important to understand the difference between:
- Analytics retention
- Total retention
- Analytics tier
- Data Lake tier
- Basic Logs
- Auxiliary tables
- Querying older data
- Table-level retention configuration
- The relationship between retention, cost, and Microsoft Sentinel functionality
Microsoft’s current architecture allows security data to remain in the Analytics tier for active security operations and then be retained longer in the Data Lake tier for lower-cost historical storage.
1. Why Data Retention Matters
Security organizations frequently face a fundamental trade-off:
How long should security data be retained, and how quickly does that data need to be accessible?
Keeping every log in the highest-performance storage tier indefinitely can be expensive.
Conversely, deleting historical data too quickly can create problems for:
- Incident investigations
- Threat hunting
- Forensic analysis
- Regulatory compliance
- Internal audits
- Legal investigations
- Historical security analysis
- Detection of long-running attacks
A good retention strategy therefore classifies data according to its value.
For example:
| Data type | Typical requirement | Appropriate strategy |
|---|---|---|
| Sign-in/security events | Active threat hunting | Analytics tier |
| High-value security alerts | Real-time detection | Analytics tier |
| Verbose firewall logs | Historical analysis | Data Lake/long-term retention |
| Compliance records | Multi-year retention | Data Lake |
| Low-value diagnostic data | Occasional investigation | Lower-cost retention tier |
| Frequently queried security data | Fast investigation | Analytics tier |
The goal is not simply to maximize retention.
The goal is to retain the right data for the right amount of time at the appropriate cost and accessibility level.
2. Understanding the Analytics Tier
The Analytics tier is the high-performance tier used for active security operations.
Data in the Analytics tier supports capabilities such as:
- Real-time analytics
- Analytics rules
- Alerting
- Threat hunting
- Workbooks
- Microsoft Sentinel investigations
- High-performance KQL queries
- Other Microsoft Sentinel features
Microsoft currently describes Analytics retention as the period during which data is maintained in the high-performance state for real-time analytics.
For Microsoft Sentinel, the standard retention period has historically been associated with 90 days, although current table-level settings and integrations can have different defaults and retention behavior. The important exam concept is that Analytics retention is configurable independently of longer-term retention.
Analytics retention can be extended to as much as two years for supported Analytics tables.
Example
Suppose an organization retains:
- 90 days of Analytics data
- 2 years of total retention
The most recent 90 days are optimized for active security operations.
Older data remains available as long-term retained data rather than consuming the same high-performance Analytics capacity.
3. Understanding Total Retention
One of the most important concepts for the SC-500 exam is the distinction between Analytics retention and total retention.
Analytics retention
Determines how long data remains in the high-performance Analytics state.
Total retention
Determines how long the data remains retained overall.
For example:
Analytics retention = 90 days
Total retention = 2 years
The data is actively available in the Analytics tier for 90 days. After that, it can remain retained in the lower-cost long-term/Data Lake state for the remainder of the two-year retention period.
Microsoft currently supports total retention of up to 12 years for applicable table configurations.
This distinction is extremely important.
Think of it this way
Analytics retention answers:
“How long do I want this data optimized for active security operations?”
Total retention answers:
“How long do I want to keep this data before it is ultimately removed?”
4. Analytics Tier vs. Data Lake Tier
Microsoft Sentinel’s current retention architecture provides two primary tiers:
- Analytics tier
- Data Lake tier
| Characteristic | Analytics tier | Data Lake tier |
|---|---|---|
| Primary purpose | Active security operations | Long-term retention |
| Performance | High | Lower/cost optimized |
| Real-time analytics | Yes | Limited |
| Threat hunting | Fully supported | More limited |
| Analytics rules | Supported | Not fully supported |
| Workbooks | Supported | Limited |
| Long-term compliance storage | Possible | Excellent use case |
| Cost | Higher | Lower |
| Maximum retention | Up to 2 years for Analytics retention | Up to 12 years total retention |
| Best use | Frequently accessed data | Historical/low-touch data |
The Data Lake tier is intended for lower-cost long-term storage and is particularly useful for:
- Compliance
- Historical investigations
- Forensics
- Long-term trend analysis
- Data that is rarely accessed
5. What Happens When Analytics Retention Expires?
Consider the following configuration:
Analytics retention: 90 daysTotal retention: 2 years
The data does not disappear after 90 days.
Instead, data can move out of the high-performance Analytics retention period while remaining available for the remainder of its total retention period.
Conceptually:
Day 0 | |---- Analytics tier --------------------| | 90 days | | |---- Data Lake / long-term retention ------------------------| | Remaining retention | | |-------------------------------------------------------------| 2 years
This architecture allows organizations to avoid keeping infrequently accessed historical data in the most expensive/high-performance state.
Microsoft documents this as the distinction between Analytics retention and total retention.
6. Example: One-Year Security Retention Strategy
Imagine a company has the following requirement:
Security logs must be retained for one year, but analysts primarily investigate incidents from the most recent 90 days.
The organization could configure:
- Analytics retention = 90 days
- Total retention = 365 days
The result is:
0–90 daysHigh-performance Analytics data91–365 daysLong-term retained dataAfter 365 daysData expires
This can be considerably more economical than maintaining a full year of data in the highest-performance tier.
7. Table-Level Retention
Retention is increasingly managed at the table level.
Different tables can have different retention requirements.
For example:
| Table | Security value | Example retention strategy |
|---|---|---|
| SigninLogs | High | Longer Analytics retention |
| SecurityEvent | High | Analytics + long-term retention |
| Firewall logs | Medium | Shorter Analytics + longer Data Lake |
| Verbose diagnostics | Low/medium | Data Lake |
| Compliance logs | Historical | Long-term retention |
This allows security teams to avoid applying a single retention policy indiscriminately to every data source.
The Microsoft Defender portal provides centralized table-level configuration for supported Microsoft Sentinel and Microsoft Defender XDR tables.
8. Changing Retention Settings
When retention settings are changed, administrators need to understand the consequences.
Increasing total retention
When total retention is increased, data that has not yet expired can benefit from the new retention period.
Decreasing total retention
Microsoft provides a safety period when total retention is shortened. Current documentation states that Microsoft waits 30 days before removing the affected data, allowing administrators an opportunity to reverse an accidental configuration change.
Changing Analytics retention
Changes to Analytics retention affect how long existing data remains in the Analytics state.
For example:
Original:Analytics = 180 daysTotal = 180 daysNew:Analytics = 90 daysTotal = 180 days
The result is effectively:
0–90 days Analytics91–180 days Data Lake/long-term retention
The data has not necessarily been deleted; it has simply moved beyond the high-performance Analytics period.
9. Data Lake Retention
The Microsoft Sentinel Data Lake provides a lower-cost location for retaining large volumes of security information for extended periods.
Data can be retained in the Data Lake for as long as 12 years, depending on the table and configuration.
Typical use cases include:
- Regulatory compliance
- Long-term forensic investigations
- Historical threat analysis
- Security trend analysis
- Low-touch security telemetry
- Large volumes of security data that do not need constant real-time access
The Data Lake is therefore particularly useful when an organization has a requirement such as:
“Retain security logs for seven years, but we don’t need all seven years available for real-time detection.”
10. Data Lake Does Not Provide Identical Functionality to Analytics
This is an important exam distinction.
Moving data from Analytics to the Data Lake is not simply a storage optimization with no functional consequences.
Some Microsoft Sentinel functionality depends on data being available in the Analytics tier.
For example, the Data Lake has limitations around features such as:
- Certain analytics rules
- Some hunting capabilities
- Watchlists
- Workbooks
- Playbooks
- Other real-time security operations
Therefore:
Do not automatically move every table to the Data Lake just because it costs less.
Determine whether the table is required for active detections and investigations.
11. Promoting Historical Data Back to Analytics
Historical data does not necessarily become useless simply because it is no longer in the Analytics tier.
Microsoft Sentinel can promote appropriate data back into an Analytics context when deeper interactive investigation is required.
For example:
A security team discovers that a compromised account may have been active nine months ago.
The relevant historical data might be retained in the Data Lake.
Instead of maintaining nine months of all data in Analytics solely for this possibility, the organization can retain the historical data more economically and retrieve/promote relevant information when needed.
This is one of the important architectural advantages of separating active analytics from long-term storage.
12. Basic Logs and Auxiliary Tables
SC-500 candidates should also understand that not all tables use exactly the same retention model.
Azure Monitor Logs supports different table plans, including:
- Analytics
- Basic
- Auxiliary
Analytics tables
Designed for active querying and broad Azure Monitor/Microsoft Sentinel functionality.
Interactive retention can be configured for supported Analytics tables, with longer-term retention available separately.
Basic tables
Designed for lower-cost logging scenarios such as troubleshooting and incident response.
Basic tables have a fixed 30-day interactive query period under the current model.
Auxiliary tables
Designed for low-touch data such as verbose logs and auditing/compliance data.
Auxiliary tables are intended for lower-cost retention where data does not require the same interactive capabilities as Analytics data.
Exam Tip
Do not assume:
“Every table in Microsoft Sentinel behaves exactly like an Analytics table.”
Table plan matters.
13. Choosing the Appropriate Retention Strategy
A useful decision process is:
Step 1 — Determine the business requirement
Ask:
- How long must the data be retained?
- Is there a regulatory requirement?
- How frequently will analysts query it?
- Does it support active detections?
Step 2 — Determine operational requirements
Ask:
- Is the table used by an analytics rule?
- Is it used for threat hunting?
- Is it needed for real-time investigations?
- Is it used by workbooks or other Sentinel capabilities?
Step 3 — Determine the appropriate tier
Use:
Analytics
when data needs frequent, high-performance access.
Use:
Data Lake/long-term retention
when data primarily needs to be preserved for historical, forensic, or compliance purposes.
Step 4 — Determine retention duration
Configure:
- Analytics retention
- Total retention
based on the actual business and security requirements.
Step 5 — Monitor cost and usage
High-volume tables can produce significant storage and ingestion costs.
Table insights can help administrators examine factors such as:
- Average daily ingestion
- Estimated daily ingestion cost
- Table tier
- Retention
- Ingestion fluctuations
14. Example: Designing Retention for Firewall Logs
Suppose an organization receives:
500 GB/day of firewall telemetry.
Security analysts typically need only the most recent 30 days for active investigations.
However, corporate policy requires seven years of retention.
Keeping seven years of firewall logs in the highest-performance Analytics tier would be unnecessarily expensive.
A better architecture could be:
Firewall logs | v+-----------------------+| Analytics Tier || 30 days || Active investigations |+-----------------------+ | v+-----------------------+| Data Lake || Long-term retention || Up to 7 years || Compliance/forensics |+-----------------------+
This architecture satisfies the retention requirement while limiting the amount of data that must remain optimized for active querying.
15. Retention and Cost
Retention has a direct relationship with cost.
The cost model depends on factors such as:
- Data ingestion volume
- Table plan
- Analytics retention
- Long-term retention
- Data Lake usage
- Queries against lower-cost tiers
Microsoft notes that retention beyond included periods can incur additional charges and that Data Lake retention provides a lower-cost option for long-term security data.
Therefore, retention policies should be designed around security value, rather than simply maximizing the amount of data retained.
16. Retention vs. Backup
A common exam trap is confusing retention with backup.
Retention
Answers:
“How long should security log data remain available?”
Backup
Answers:
“How can I recover protected data after deletion, corruption, or another failure?”
Microsoft Sentinel retention is primarily concerned with preserving security telemetry for investigation, detection, compliance, and historical analysis.
It is not a replacement for a backup strategy.
17. Retention vs. Archiving
Older Microsoft Sentinel and Log Analytics terminology frequently referred to archive or archived logs.
The current architecture emphasizes the Data Lake tier and long-term retention.
For exam preparation, understand the underlying concept:
Data can move from high-performance, actively queried storage into lower-cost long-term storage while remaining retained.
If you encounter older documentation or training material using “archive,” understand that it refers to the long-term storage concept rather than assuming it represents the exact current Microsoft Sentinel terminology.
18. Important Data Lake Compliance Consideration
Data retention policies should also consider privacy and data deletion requirements.
One important current consideration is that data stored in the Microsoft Sentinel Data Lake has different deletion behavior from Analytics data.
Microsoft documents that the purge capability used for GDPR-related deletion in the Analytics tier does not affect data in the Sentinel Data Lake, and individual records cannot currently be purged from the Data Lake.
This means organizations should carefully consider:
- Data residency
- Privacy requirements
- Regulatory requirements
- Retention requirements
- Data deletion requirements
before designing a long-term Data Lake retention strategy.
19. Managing Retention in the Microsoft Defender Portal
Microsoft’s current management experience provides table-level retention and tier configuration through the Microsoft Defender portal for supported tables.
Administrators can review and configure:
- Table tier
- Analytics retention
- Total retention
- Data Lake settings
The exact controls available depend on the table type. Some tables have restrictions because Microsoft security services require them to remain available for security operations.
Basic Logs tables, for example, can be viewed from the Defender portal but currently have some management capabilities that remain in the Log Analytics workspace experience.
20. Common Mistakes
Mistake 1: Treating Analytics retention as total retention
A 90-day Analytics period does not necessarily mean the data is deleted after 90 days.
Remember:
Analytics retention ≠ total retention.
Mistake 2: Assuming Data Lake is identical to Analytics
Data Lake is designed for cost-effective, long-term storage and does not provide the complete real-time security feature set of Analytics.
Mistake 3: Moving detection data out of Analytics without checking dependencies
If an analytics rule depends on a table, moving that data exclusively into a lower-cost tier can interfere with the security capabilities that depend on Analytics data.
Mistake 4: Retaining everything for the maximum period
Maximum retention is not automatically the best security strategy.
Consider:
- Cost
- Regulatory requirements
- Security value
- Query frequency
- Detection dependencies
Mistake 5: Assuming all tables have identical retention capabilities
Table plans and table types matter.
Analytics, Basic, Auxiliary, Sentinel, custom, and XDR tables can have different retention and management characteristics.
Mistake 6: Confusing retention with backup
Keeping security logs for seven years does not mean the organization has a seven-year backup strategy.
21. Best Practices
1. Classify data by security value
Not every log deserves the same retention period or storage tier.
2. Keep active detection data in Analytics
If a table is important for real-time detections and hunting, make sure it remains available in the appropriate Analytics tier.
3. Use Data Lake for long-term, low-touch data
Use the Data Lake for compliance, historical analysis, and forensic data that does not require continuous real-time access.
4. Use table-level configuration
Avoid applying the same retention policy to every table.
5. Review retention periodically
Security requirements, regulations, data volumes, and costs change.
6. Monitor ingestion and costs
High-volume tables should be reviewed regularly for their actual security value.
7. Validate dependencies before changing tiers
Before moving or shortening retention for a table, determine whether:
- Analytics rules
- Hunting queries
- Workbooks
- Playbooks
- Investigations
- Other Sentinel capabilities
depend on that data.
8. Consider privacy requirements
Long-term retention should be evaluated against privacy and data deletion requirements, particularly when using the Data Lake.
22. SC-500 Exam Tips
For the exam, remember these distinctions:
| Concept | Remember |
|---|---|
| Analytics tier | High-performance security operations |
| Data Lake tier | Lower-cost long-term retention |
| Analytics retention | How long data remains in the Analytics state |
| Total retention | How long data remains retained overall |
| Basic Logs | Lower-cost table plan with 30-day interactive query period |
| Auxiliary | Low-touch/verbose/audit-oriented data |
| Up to 2 years | Maximum Analytics retention for supported tables |
| Up to 12 years | Maximum total/long-term retention for applicable configurations |
| Retention | Determines how long data is kept |
| Backup | Provides recoverability; different concept |
| Data Lake | Excellent for compliance and historical investigations |
| Analytics | Required for many real-time Sentinel capabilities |
A particularly important exam pattern
If the question says:
“The organization must retain logs for seven years but only needs them for active investigations for the first 90 days.”
Think:
Short Analytics retention + longer total/Data Lake retention.
If the question says:
“Security analysts need high-performance querying and real-time detection against the data.”
Think:
Analytics tier.
If the question says:
“The data is primarily retained for compliance and occasional historical investigations.”
Think:
Data Lake/long-term retention.
23. Key Takeaways
The most important concepts to remember are:
- Analytics retention controls how long data remains in the high-performance Analytics state.
- Total retention controls how long data remains retained overall.
- Microsoft Sentinel supports Analytics and Data Lake tiers for different security and cost requirements.
- Analytics is optimized for real-time detection, hunting, investigation, and other Sentinel features.
- Data Lake is optimized for long-term, lower-cost security data retention.
- Applicable Analytics tables can have Analytics retention of up to two years.
- Applicable data can have total retention of up to 12 years.
- Basic and Auxiliary tables have different retention/query characteristics from Analytics tables.
- Retention should be configured based on security value, regulatory requirements, query frequency, and cost.
- Do not confuse retention with backup.
- Before changing a table’s tier or retention, determine whether Sentinel detections and other security capabilities depend on that data.
- Long-term Data Lake retention should also be evaluated against privacy and data deletion requirements.
Practice Exam Questions
Question 1
A security team wants to retain Azure firewall logs for seven years because of a regulatory requirement. Analysts only need the most recent 60 days for routine threat hunting.
Which approach best satisfies the requirements while minimizing the amount of data kept in the high-performance tier?
A. Keep all seven years of data in the Analytics tier.
B. Configure a short Analytics retention period and a seven-year total retention period using long-term/Data Lake retention.
C. Delete the firewall data after 60 days and rely on Azure Activity Logs.
D. Store all firewall data in Basic Logs for seven years and use analytics rules against it.
Answer: B
Explanation: Analytics retention and total retention can be configured to serve different purposes. Keeping the most frequently accessed data in Analytics while retaining older data in the Data Lake provides a better balance between operational access, compliance, and cost.
Question 2
An administrator configures an Analytics table with:
- Analytics retention: 90 days
- Total retention: 365 days
What should the administrator expect?
A. All data is permanently deleted after 90 days.
B. Data remains in the Analytics tier for 365 days.
C. Data is copied to a backup service after 90 days.
D. Data can remain retained for 365 days, with the older portion outside the high-performance Analytics retention period.
Answer: D
Explanation: Analytics retention determines the high-performance period, while total retention determines how long the data remains retained overall. The 275 days after the 90-day Analytics period can therefore be retained as long-term data.
Question 3
A SOC requires real-time analytics rules and high-performance threat hunting against a particular table.
Which tier is most appropriate for the actively queried data?
A. Analytics tier
B. Data Lake tier only
C. Auxiliary tier
D. External archival storage
Answer: A
Explanation: The Analytics tier is designed for high-performance querying, analytics rules, threat hunting, alerting, and other active Microsoft Sentinel security operations.
Question 4
An organization wants to retain large volumes of historical security telemetry primarily for compliance and occasional forensic investigations. The data does not need to support continuous real-time analytics.
Which option is most appropriate?
A. Keep all data in the Analytics tier indefinitely.
B. Delete the data after 30 days.
C. Convert all security data to Azure Activity Logs.
D. Use the Data Lake/long-term retention capability.
Answer: D
Explanation: The Data Lake is designed for cost-effective long-term security data retention, including compliance, historical analysis, and forensic investigations.
Question 5
A security administrator reduces a table’s total retention from five years to one year. The administrator immediately realizes that the change was accidental.
What is an important behavior to know about reducing total retention?
A. All data older than one year is immediately destroyed.
B. Microsoft provides a 30-day period before data affected by the shortened retention is removed.
C. The table automatically changes to Basic Logs.
D. The data is automatically exported to Azure Storage.
Answer: B
Explanation: Microsoft currently provides a 30-day safety period when total retention is shortened, allowing an administrator to reverse an accidental configuration change before affected data is removed.
Question 6
A security team is evaluating whether to move a table from Analytics to the Data Lake tier.
Which consideration is most important before making the change?
A. Whether the table name contains _CL
B. Whether the table was created before Microsoft Sentinel was enabled
C. Whether security capabilities such as analytics rules or other real-time functionality depend on the table remaining in Analytics
D. Whether the table contains more than 1 GB of data
Answer: C
Explanation: Moving data out of the Analytics tier can affect functionality that depends on Analytics data. Administrators should identify detection, hunting, workbook, and other security dependencies before changing tiers.
Question 7
An organization wants to keep security data for 10 years but does not need all 10 years available for continuous high-performance queries.
Which statement best describes the appropriate strategy?
A. Keep all 10 years in the Analytics tier.
B. Keep the data for only two years because Analytics retention cannot exceed two years.
C. Use Basic Logs exclusively because Basic Logs automatically provide 10-year retention.
D. Use an appropriate Analytics retention period and longer total/Data Lake retention where supported.
Answer: D
Explanation: Analytics retention and total retention serve different purposes. Applicable data can have total retention of up to 12 years, while Analytics retention can be configured separately, up to two years for supported Analytics tables.
Question 8
Which statement correctly describes the relationship between Analytics retention and total retention?
A. Analytics retention determines how long data remains in the high-performance Analytics state, while total retention determines how long the data is retained overall.
B. Analytics retention is always longer than total retention.
C. Total retention applies only to Azure Activity Logs.
D. Analytics retention and total retention are two names for exactly the same setting.
Answer: A
Explanation: This is one of the most important concepts for the SC-500 exam. Analytics retention describes the active/high-performance retention period, whereas total retention describes the overall retention period.
Question 9
A company stores verbose auditing data that is rarely queried but must be retained for compliance.
Which characteristic best describes the type of storage strategy that should be considered?
A. Keep all data in Analytics because compliance data always requires real-time analytics.
B. Delete the data immediately after an audit.
C. Use a lower-cost long-term retention approach such as the Data Lake or an appropriate low-touch table plan.
D. Convert the audit records into Microsoft Entra authentication events.
Answer: C
Explanation: Verbose, low-touch auditing data is a strong candidate for lower-cost retention. Depending on the table and requirements, Data Lake or an appropriate lower-cost table plan can provide long-term retention without keeping all data in the highest-performance tier.
Question 10
A security engineer needs to retain historical data for privacy-sensitive investigations and is considering using the Microsoft Sentinel Data Lake.
Which consideration is particularly important?
A. Data Lake automatically purges individual records whenever they are purged from the Analytics tier.
B. Data Lake retention is limited to 30 days.
C. Data Lake data cannot be used for any historical investigation.
D. Data Lake has different data deletion behavior, and individual records cannot currently be purged from the Sentinel Data Lake.
Answer: D
Explanation: Microsoft documents that the purge capability for the Analytics tier does not affect data in the Sentinel Data Lake, and individual records cannot currently be purged from the Data Lake. This makes privacy, regulatory, and data-deletion requirements an important consideration when designing long-term retention.
Final Exam Reminder
When you see a retention scenario on the SC-500 exam, first identify how the data will be used, and then distinguish between how long it needs to be highly accessible and how long it must be retained.
A useful mental model is:
SECURITY DATA
|
+------------+------------+
| |
Active / frequently Historical /
queried compliance
| |
v v
ANALYTICS TIER DATA LAKE
| |
Fast queries, Long-term,
detections, lower-cost
hunting, retention
investigations
|
+----------+
|
TOTAL RETENTION
determines how long
the data is retained
The key distinction is:
Analytics retention = how long the data is optimized for active security operations.
Total retention = how long the data remains retained overall.
That distinction is central to understanding how Microsoft Sentinel balances security operations, compliance, historical investigation, and cost.
Go to the SC-500 Exam Prep Hub main page
