Tag: Data Collection Rules (DCRs)

Implement and configure collection of Windows Security events by using data collection rules, including Windows Event Forwarding (WEF) (SC-500 Exam Prep)

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 and configure collection of Windows Security events by using data collection rules, including Windows Event Forwarding (WEF)


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.

Overview

Windows systems generate a large amount of security-relevant telemetry, including successful and failed logons, account changes, process creation, privilege use, authentication activity, and other security events.

For Microsoft Sentinel, these events can be collected using the Azure Monitor Agent (AMA) and controlled through Data Collection Rules (DCRs).

The SC-500 exam expects security engineers to understand not only how to enable Windows event collection, but also how to:

  • Configure Azure Monitor Agent.
  • Create and associate Data Collection Rules.
  • Select appropriate Windows Security event sets.
  • Use XPath queries to filter events.
  • Understand Windows Event Forwarding (WEF).
  • Configure a Windows Event Collector (WEC).
  • Understand source-initiated versus collector-initiated WEF.
  • Send forwarded Windows events to Microsoft Sentinel.
  • Understand the difference between the SecurityEvent and WindowsEvent tables.
  • Troubleshoot event collection.
  • Design collection policies that balance security visibility, performance, and ingestion cost.

Also, for this topic, it is important to distinguish direct Windows Security event collection with Azure Monitor Agent (AMA) from Windows Event Forwarding (WEF), because both use AMA and DCRs but have different architectures and target different Sentinel tables.


1. Why Windows Security Events Matter

Windows Security event logs provide valuable evidence about activity occurring on Windows computers.

Examples include:

Event IDTypical activity
4624Successful logon
4625Failed logon
4648Logon using explicit credentials
4672Special privileges assigned to a new logon
4688New process created
4697Service installed
4720User account created
4728Member added to a security-enabled global group
4732Member added to a security-enabled local group
4740User account locked out
4768Kerberos authentication ticket requested
4769Kerberos service ticket requested
4771Kerberos preauthentication failed
5140Network share accessed
5145Network share object checked

These events can help security teams detect:

  • Credential attacks
  • Account compromise
  • Privilege escalation
  • Lateral movement
  • Persistence
  • Suspicious process execution
  • Unauthorized account creation
  • Changes to security-sensitive objects

Microsoft provides predefined event sets for Windows Security Events, including Minimal and Common, as well as the ability to define a Custom collection set using XPath queries.


2. The Azure Monitor Agent Is the Modern Collection Agent

The Azure Monitor Agent (AMA) is the primary Microsoft agent used for collecting Windows event data into Azure Monitor and Microsoft Sentinel.

For Microsoft Sentinel, AMA replaces the older Log Analytics agent/Microsoft Monitoring Agent (MMA/OMS) approach.

AMA can collect Windows events from:

  • Azure virtual machines
  • Azure Arc-enabled Windows servers
  • On-premises Windows servers
  • Windows VMs hosted in other clouds

For machines that are not Azure VMs, Azure Arc is used to provide the Azure-connected resource representation needed for AMA-based collection. Microsoft specifically identifies Azure Arc as a prerequisite for non-Azure machines using AMA-based Sentinel connectors.

A simplified architecture is:

Windows Server
|
| Windows Event Log
v
Azure Monitor Agent (AMA)
|
| DCR defines what to collect
v
Data Collection Rule (DCR)
|
v
Log Analytics Workspace
|
v
Microsoft Sentinel

The key concept for the exam is:

AMA collects the data; the DCR determines what data is collected and where it goes.


3. What Is a Data Collection Rule?

A Data Collection Rule (DCR) defines how Azure Monitor collects and processes monitoring data.

A DCR can specify:

  1. Data sources
  2. Streams
  3. Destinations
  4. Data flows
  5. Filtering criteria such as XPath expressions
  6. In some scenarios, transformations

For Windows event collection, the DCR can specify which Windows Event Logs and which events should be collected.

Conceptually:

DCR
|
+-- Data source
| |
| +-- Windows Security log
| +-- Event IDs
| +-- XPath filters
|
+-- Destination
|
+-- Log Analytics workspace

One of the major advantages of DCRs is that they are independent of individual virtual machines. A DCR can be associated with multiple machines, allowing administrators to apply consistent collection policies across groups of systems.


4. DCR Associations

Creating a DCR alone does not cause a VM or server to begin sending events.

The DCR must be associated with the resources that should use it.

For example:

DCR-Windows-Security
|
+---- DC01
|
+---- DC02
|
+---- APP01
|
+---- APP02

This allows an organization to create different collection policies for different groups of machines.

For example:

  • Domain controllers → extensive security auditing
  • Application servers → authentication + process events
  • Workstations → selected security events
  • High-volume servers → carefully filtered events

This is an important security and cost-management principle.


5. Microsoft Sentinel’s Windows Security Events via AMA Connector

Microsoft Sentinel provides a dedicated Windows Security Events via AMA data connector.

The connector uses:

  • Azure Monitor Agent
  • Data Collection Rules
  • Log Analytics
  • Microsoft Sentinel

The collected events are written to the:

SecurityEvent

table.

This distinction is extremely important for SC-500.

Many Microsoft Sentinel analytics rules for Windows security events are designed to query the SecurityEvent table.


6. Windows Security Event Collection Sets

The Windows Security Events via AMA connector provides predefined event sets.

The important concepts are:

Minimal

The Minimal set focuses on a relatively small group of security events that may indicate potential compromise.

For example:

  • Successful logons
  • Failed logons
  • Process creation
  • Important account/security changes

The objective is to obtain useful threat-detection telemetry without collecting the entire Security log.

Common

The Common set collects a broader set of commonly useful security events.

It provides greater visibility than Minimal but can generate substantially more data.

Custom

The Custom option allows the administrator to define the events using XPath.

This provides the greatest control.

For example:

Security!*[System[(EventID=4624) or
(EventID=4625) or
(EventID=4688)]]

This could be used to collect only successful logons, failed logons, and process creation events.

The AMA Windows event collection interface supports XPath 1.0 expressions. Microsoft also recommends testing XPath expressions with Get-WinEvent before deploying them in a DCR.


7. Why XPath Filtering Matters

Collecting everything from every Windows machine can produce:

  • High ingestion volume
  • Higher costs
  • Increased network traffic
  • More data for analysts to search
  • Greater storage requirements
  • More noise in security investigations

Instead, organizations should collect events that support their security objectives.

For example:

Security
|
+-- 4624 Successful logon
+-- 4625 Failed logon
+-- 4688 Process creation
+-- 4720 Account created
+-- 4740 Account locked

A custom XPath filter can reduce collection to the events that matter.

Example:

Security!*[System[
(EventID=4624) or
(EventID=4625) or
(EventID=4688) or
(EventID=4720) or
(EventID=4740)
]]

This is particularly useful when an organization has thousands of Windows servers.


8. Testing an XPath Expression

A common troubleshooting technique is to test the XPath expression locally before placing it into a DCR.

For example:

$XPath = '*[System[EventID=4688]]'
Get-WinEvent `
-LogName 'Security' `
-FilterXPath $XPath

If matching events exist, the command returns them.

This can help determine whether a problem is caused by:

  • An invalid XPath expression
  • No matching events
  • Incorrect event IDs
  • Incorrect log selection

Microsoft documents Get-WinEvent -FilterXPath as a method for validating XPath expressions used with AMA.


9. Windows Security Events versus Generic Windows Events

There is an important distinction between using a generic Windows Event Logs data source and the Microsoft Sentinel Windows Security Events connector.

A generic Azure Monitor Windows Event Logs DCR can collect Windows events into the Event table.

The Microsoft Sentinel Windows Security Events via AMA connector is specifically designed for security-event ingestion and sends those events to:

SecurityEvent

This matters because Sentinel analytics content often expects particular tables.

Therefore, if a question asks:

You need Windows security events in the table used by Sentinel’s built-in Windows security analytics rules. Which connector should you use?

The answer is generally:

Windows Security Events via AMA

rather than simply configuring a generic Windows Event Log DCR.

Microsoft explicitly notes that the Windows Security Events via AMA connector sends events to SecurityEvent.


10. Windows Event Forwarding (WEF)

Windows Event Forwarding (WEF) is a Windows capability that allows events generated on one or more Windows computers to be forwarded to a central Windows Event Collector (WEC).

Instead of installing a monitoring agent on every source solely to aggregate the events, organizations can use native Windows event forwarding.

The architecture looks like this:

Windows Server 1 ──┐
|
Windows Server 2 ──┤
|
Windows Server 3 ──┤
v
Windows Event
Collector
|
| AMA
v
DCR
|
v
Log Analytics
|
v
Microsoft Sentinel

This is particularly useful in environments with many Windows systems.


11. What Is a Windows Event Collector?

The Windows Event Collector (WEC) is the central Windows computer that receives forwarded events.

The source machines forward events to the collector, where the events are stored in the ForwardedEvents log.

The WEC machine then becomes the system from which AMA collects the forwarded events.

Microsoft’s current Sentinel Windows Forwarded Events connector requires:

  • Windows Event Collection (WEC) enabled and running
  • Azure Monitor Agent installed on the WEC machine

The forwarded events are written to the Sentinel WindowsEvent table.


12. Source-Initiated versus Collector-Initiated WEF

This is an important SC-500 concept.

There are two primary WEF subscription models.

Source-Initiated Subscription

In a source-initiated subscription, the collector defines the subscription, but the event sources determine themselves that they should forward events to that collector.

The event sources can be configured through Group Policy.

Conceptually:

             WEC
              |
       Subscription defined
              |
       +------+------+
       |             |
      DC01          DC02
       |             |
       +------->-----+
        forward events

This model is useful when many machines need to participate in the same collection policy.

Microsoft describes source-initiated subscriptions as allowing the collector to define the subscription without having to individually define all event source computers.


Collector-Initiated Subscription

In a collector-initiated subscription, the collector explicitly specifies the event sources.

For example:

WEC
|
+-- DC01
+-- DC02
+-- APP01
+-- APP02

The collector maintains the list of source computers.

This can be useful when the organization wants explicit control over which computers participate in a particular subscription.

Microsoft distinguishes collector-initiated subscriptions from source-initiated subscriptions by whether the event sources are explicitly defined in the subscription.


13. Configuring WEF

A typical WEF implementation includes:

On the event source

Configure:

  • Windows Event Forwarding
  • Windows Remote Management (WinRM)
  • Subscription Manager configuration
  • Appropriate Group Policy settings

On the collector

Configure:

  • Windows Remote Management
  • Windows Event Collector service
  • WEF subscription
  • Appropriate permissions

For a source-initiated subscription, Group Policy can configure the source computers to communicate with the Subscription Manager.

Microsoft documents wecutil as a command-line utility that can be used to configure and manage WEF subscriptions.


14. Forwarding the Windows Security Log

Security logs are more sensitive than many other Windows logs.

When configuring WEF to forward Security events, permissions must be considered.

Microsoft documents that forwarding the Security log requires the NETWORK SERVICE account to be added to the Event Log Readers group in the applicable WEF configuration.

This is a classic exam-style detail.

If a WEF subscription appears correctly configured but Security events are not being forwarded, check:

  1. Event source configuration
  2. WEF subscription
  3. WinRM
  4. Event Collector service
  5. Event Log Readers permissions
  6. Security log auditing
  7. Event filters

15. Windows Forwarded Events Connector

Microsoft Sentinel has a Windows Forwarded Events data connector.

Its architecture is:

Windows Event Sources
|
| WEF
v
Windows Event Collector
|
| AMA
v
DCR
|
v
Log Analytics
|
v
WindowsEvent table
|
v
Microsoft Sentinel

The Windows Forwarded Events connector is different from Windows Security Events via AMA.

The key difference is the destination table:

Collection methodSentinel table
Windows Security Events via AMASecurityEvent
Windows Forwarded EventsWindowsEvent

Microsoft explicitly states that WEF events, including events forwarded from the Windows Security log, are written to WindowsEvent, not SecurityEvent.


16. A Critical Exam Distinction: SecurityEvent versus WindowsEvent

Consider this scenario:

An organization uses WEF to forward Security log events from 1,000 Windows servers to a central WEC. AMA is installed on the WEC, and Microsoft Sentinel is receiving the forwarded events.

Where will the events appear?

Answer:

WindowsEvent

They will not automatically appear in SecurityEvent merely because the original source was the Windows Security log.

This distinction can have a major impact on analytics.

Some Microsoft Sentinel analytics rules are written specifically against SecurityEvent.

Therefore, an organization using WindowsEvent may need:

  • Analytics rules that query WindowsEvent
  • Queries that normalize or union the two tables
  • Appropriate ASIM normalization

Microsoft notes that many built-in Windows security analytics rules query SecurityEvent, so forwarded events in WindowsEvent may not automatically satisfy those rules.


17. Why Use WEF?

WEF can be attractive in environments where:

  • Many Windows servers must be monitored
  • Centralized event collection is desired
  • Security policies already use Windows event forwarding
  • Organizations want a centralized collection architecture
  • The environment includes systems where installing/configuring a Sentinel collection agent directly is less desirable

For example:

2,000 Windows servers
|
| WEF
v
10 regional WEC servers
|
| AMA
v
Microsoft Sentinel

This architecture can simplify centralized event collection.

However, WEF introduces additional infrastructure and operational dependencies.


18. WEF Is Not the Same as AMA

A common exam trap is to treat WEF and AMA as competing alternatives.

They solve different problems.

WEF

WEF is a Windows-native event forwarding mechanism.

Its job is:

Windows source → Windows Event Collector

AMA

AMA is an Azure monitoring agent.

Its job in this architecture is:

Windows Event Collector → Azure Monitor / Sentinel

Therefore:

WEF can be used to aggregate Windows events, while AMA collects the resulting forwarded events into Azure.


19. WEF and DCRs Work Together

A DCR controls what AMA collects from the WEC.

For example:

Windows servers
|
| WEF
v
WEC
|
| ForwardedEvents
|
v
AMA
|
| DCR
|
+---- select collection
|
v
Log Analytics
|
v
WindowsEvent

The WEF subscription controls what gets forwarded to the WEC.

The DCR controls what AMA collects from the WEC.

This distinction is extremely important.


20. Two Levels of Filtering

In a WEF architecture, filtering can occur at more than one stage.

Stage 1: WEF filtering

The WEF subscription can determine which events are forwarded.

Stage 2: DCR filtering

The DCR can determine which events AMA collects from the WEC.

Therefore:

Windows source
|
| WEF filtering
v
WEC
|
| DCR filtering
v
Sentinel

This provides multiple opportunities to control data volume.

However, overly aggressive filtering can result in missing security telemetry.


21. Data Collection Rules Can Be Reused

DCRs are designed to be reusable.

For example:

DCR: DomainController-Security
|
+----+----+
| | |
DC01 DC02 DC03

Another DCR could be used for application servers:

DCR: ApplicationServer-Security
|
+----+----+
| | |
APP01 APP02 APP03

This supports a security architecture based on:

  • Role
  • Environment
  • Risk
  • Regulatory requirements
  • Data volume
  • Business criticality

22. DCRs and Azure Arc

Azure Arc is particularly important for hybrid environments.

Suppose an organization has:

  • Azure VMs
  • VMware VMs
  • Physical Windows servers
  • AWS Windows servers

Non-Azure machines can be onboarded to Azure Arc and then managed as Azure resources for applicable Azure management capabilities.

For AMA-based Sentinel collection, Microsoft requires non-Azure systems to be Azure Arc-enabled.

Architecture:

Azure VM
|
+---- AMA
|
v
DCR
|
v
Sentinel
On-prem VM
|
+---- Azure Arc
|
+---- AMA
|
v
DCR
|
v
Sentinel

23. DCR Scope and Least Privilege

DCRs should be designed according to the principle of least privilege.

Avoid creating a single enormous collection rule that collects every possible event from every server.

Instead, consider:

  • Critical servers
  • Domain controllers
  • Privileged-access systems
  • Production servers
  • Development systems
  • Security appliances
  • Regulatory workloads

For example:

Server typePossible strategy
Domain controllersBroad security event collection
Tier-0 systemsExtensive security auditing
Production application serversFocused collection
Development serversReduced collection
WorkstationsSecurity-focused collection
High-volume systemsCustom XPath filtering

24. Security Event Collection and Cost

Security event collection has a direct relationship with ingestion volume.

Suppose an organization collects:

500 MB/day/server

from:

1,000 servers

That represents approximately:

500 GB/day

before considering additional retention and processing considerations.

Therefore, event selection matters.

The goal should not simply be:

Collect everything.

The goal should be:

Collect enough telemetry to support detection, investigation, compliance, and response while controlling unnecessary volume.


25. Choosing Between Minimal, Common, and Custom

A practical decision model is:

RequirementRecommended approach
Basic threat visibilityMinimal
Broader security monitoringCommon
Specific security requirementsCustom
Strict ingestion-cost controlCustom
Specialized detectionCustom
Need a predefined baselineMinimal/Common

Custom collection is especially valuable when an organization knows exactly which event IDs its detection rules require.


26. Important Windows Security Event IDs to Know

For SC-500, it is useful to recognize several high-value event IDs.

Authentication

EventMeaning
4624Successful logon
4625Failed logon
4648Explicit credentials used
4672Special privileges assigned

Process activity

EventMeaning
4688New process created
4689Process exited

Account management

EventMeaning
4720User account created
4722User account enabled
4724Attempt to reset account password
4728Member added to global security group
4732Member added to local security group
4740Account locked out
4767Account unlocked

Kerberos

EventMeaning
4768Kerberos authentication ticket requested
4769Kerberos service ticket requested
4771Kerberos preauthentication failed

Network/share access

EventMeaning
5140Network share accessed
5145Network share object checked

The exact events you collect should depend on the detection, investigation, and compliance requirements.


27. Windows Event Collection and Security Auditing

Collecting an event is not the same thing as generating the event.

This is an important troubleshooting concept.

For example, if you want Event ID 4688, process creation auditing must be configured appropriately on the Windows system.

The architecture is:

Windows audit policy
|
v
Security event generated
|
v
WEF or AMA
|
v
DCR
|
v
Log Analytics
|
v
Sentinel

If the Windows system never generates the event, changing the Sentinel DCR will not create it.


28. Troubleshooting Windows Security Events via AMA

If events are missing, troubleshoot from the source toward Sentinel.

Step 1 — Verify the event exists locally

On the Windows machine:

Get-WinEvent -LogName Security -MaxEvents 20

Determine whether the expected events are actually being generated.

Step 2 — Verify AMA

Confirm that:

  • AMA is installed
  • AMA is running
  • The machine is properly onboarded
  • The machine is associated with the appropriate DCR

Step 3 — Verify the DCR

Check:

  • Windows Event Logs data source
  • Security log selection
  • XPath
  • Event IDs
  • Destination
  • DCR association

Step 4 — Verify the workspace

Check:

SecurityEvent
| where TimeGenerated > ago(1h)
| take 50

Step 5 — Verify the expected event ID

For example:

SecurityEvent
| where TimeGenerated > ago(24h)
| where EventID == 4625
| summarize Count=count() by Computer

29. Troubleshooting WEF

For WEF, the troubleshooting path is longer.

Source
|
| 1. Event generated?
v
WEF configuration
|
| 2. Event forwarded?
v
WEC
|
| 3. Event in ForwardedEvents?
v
AMA
|
| 4. Agent collecting?
v
DCR
|
| 5. Correct collection rule?
v
Sentinel

On the WEC, verify that events are appearing in:

ForwardedEvents

Windows provides wecutil commands that can be used to inspect subscription information and runtime status. For example:

wecutil gr <SubscriptionID>

can be used to retrieve runtime status for a subscription.


30. A Key WEF Troubleshooting Question

Suppose:

  • Windows servers generate Security events.
  • WEF is configured.
  • The WEC is running.
  • Events appear in the WEC’s ForwardedEvents log.
  • Sentinel has no events.

Where should you troubleshoot next?

The likely problem is after WEF, because WEF itself is working.

Check:

  1. AMA on the WEC
  2. DCR
  3. DCR association
  4. Destination workspace
  5. Sentinel connector
  6. Ingestion/query results

This is an excellent SC-500 troubleshooting pattern.


31. Querying Windows Forwarded Events

If WEF is being used, query:

WindowsEvent
| where TimeGenerated > ago(1h)
| take 50

For a particular event:

WindowsEvent
| where TimeGenerated > ago(24h)
| where EventID == 4625
| project TimeGenerated, Computer, EventID, EventData
| order by TimeGenerated desc

Remember:

WEF Security events are stored in WindowsEvent, not SecurityEvent.


32. Querying Direct Security Events

When using Windows Security Events via AMA:

SecurityEvent
| where TimeGenerated > ago(1h)
| where EventID == 4625
| project TimeGenerated, Computer, Account, IpAddress
| order by TimeGenerated desc

This distinction should become second nature for the exam.


33. SecurityEvent versus WindowsEvent

CharacteristicWindows Security Events via AMAWindows Forwarded Events
AgentAMAAMA
DCRYesYes
SourceWindows machineWEF collector
WEF required?NoYes
Primary Sentinel tableSecurityEventWindowsEvent
Multiple source serversDirectly supportedAggregated through WEC
XPath filteringYesCan be applied through collection configuration
Useful for centralized WEF architectureNot requiredYes
Built-in rules commonly targeting SecurityEventYesMay require adaptation/union
Non-Azure serversAzure Arc + AMAWEC can be hybrid; AMA host must be supported/onboarded

Microsoft’s current connector documentation explicitly identifies SecurityEvent for Windows Security Events via AMA and WindowsEvent for Windows Forwarded Events.


34. A Typical Enterprise Architecture

Consider a large enterprise with 5,000 Windows servers.

Instead of sending every server directly to Sentinel, the organization could implement:

                 ┌── Windows Server
                 ├── Windows Server
                 ├── Windows Server
                 └── Windows Server
                         |
                         | WEF
                         v
                Windows Event Collector
                         |
                         | AMA
                         v
                       DCR
                         |
                         v
                 Log Analytics
                         |
                         v
                 Microsoft Sentinel

The organization might have:

  • Regional WEC servers
  • Different WEF subscriptions
  • Different DCRs
  • Security-event filtering
  • Sentinel analytics rules
  • Automated incident response

This architecture can provide centralized security monitoring while retaining control over collection volume.


35. When Direct AMA Collection Is Better

WEF is not automatically the best solution.

Direct AMA collection may be preferable when:

  • The number of servers is manageable
  • Central WEC infrastructure is unnecessary
  • The organization wants a simpler architecture
  • Machines can be directly onboarded to Azure Arc
  • Sentinel’s SecurityEvent table is preferred
  • Existing analytics content relies heavily on SecurityEvent

Architecture:

Windows Server
|
| AMA
v
DCR
|
v
SecurityEvent
|
v
Microsoft Sentinel

This eliminates the additional WEF/WEC layer.


36. When WEF Is Attractive

WEF can be attractive when:

  • Existing Windows infrastructure already uses WEF
  • A centralized Windows event collection architecture is desired
  • Many Windows systems need to feed a smaller number of collectors
  • Security teams want centralized event forwarding before cloud ingestion
  • Network architecture favors regional collectors

However, WEF adds infrastructure that must be maintained.


37. Advanced Security Information Model (ASIM)

Microsoft Sentinel supports the Advanced Security Information Model (ASIM) to normalize security data across different sources.

This can be useful when security events arrive in different tables or formats.

For example:

Windows Security Events
|
+---- SecurityEvent
|
+---- WindowsEvent
|
v
ASIM
|
v
Normalized security analytics

This can reduce dependence on a single underlying table structure when building analytics and hunting queries.

Microsoft recommends ASIM parsers in connection with Windows Forwarded Events to support data normalization.


38. Common Mistakes

Mistake 1: Assuming installing AMA is enough

Installing AMA does not automatically define what data should be collected.

Remember:

AMA + DCR + Association

are central to the architecture.


Mistake 2: Creating a DCR but not associating it

A DCR that isn’t associated with the target machine won’t provide the intended collection configuration.


Mistake 3: Confusing WEF with AMA

WEF forwards events between Windows computers.

AMA sends monitoring data to Azure.

They are not interchangeable technologies.


Mistake 4: Assuming WEF Security events go to SecurityEvent

They don’t.

The Windows Forwarded Events connector writes them to:

WindowsEvent

Mistake 5: Collecting every event

More data isn’t necessarily better.

Excessive collection can increase:

  • Cost
  • Noise
  • Storage
  • Investigation complexity

Mistake 6: Using the wrong event table in KQL

If the data was collected using Windows Forwarded Events:

WindowsEvent

If it was collected using Windows Security Events via AMA:

SecurityEvent

Mistake 7: Forgetting Windows auditing

If the operating system isn’t configured to generate the desired event, Sentinel cannot collect it.


Mistake 8: Assuming a valid XPath guarantees data

A valid XPath expression may return zero events simply because the machine has not generated matching events.

Microsoft specifically notes this distinction when testing XPath queries.


39. SC-500 Exam Decision Matrix

ScenarioBest answer/concept
Collect Windows Security events directly into SentinelWindows Security Events via AMA
Control collection using reusable rulesDCR
Filter Windows events by Event IDXPath
Forward events from many Windows machines to a central Windows serverWEF
Receive WEF eventsWindows Event Collector
Send WEC events to AzureAMA
WEF events in SentinelWindowsEvent
Direct Windows Security Events via AMASecurityEvent
Centralized source configuration through Group PolicySource-initiated WEF
Collector explicitly maintains source listCollector-initiated WEF
Non-Azure Windows server using AMAAzure Arc
Test XPath locallyGet-WinEvent -FilterXPath
Check WEF subscription runtimewecutil gr
Normalize security dataASIM

40. Exam-Focused Mental Model

The following model is worth memorizing:

                 DIRECT COLLECTION

Windows Security Log
        |
        v
       AMA
        |
        v
       DCR
        |
        v
   SecurityEvent
        |
        v
   Microsoft Sentinel

And:

                    WEF COLLECTION

Windows Server 1 ──┐
Windows Server 2 ──┤
Windows Server 3 ──┤
Windows Server 4 ──┘
          |
          | WEF
          v
      WEC Server
          |
          | AMA
          v
         DCR
          |
          v
    WindowsEvent
          |
          v
   Microsoft Sentinel

The most important distinction is:

Direct AMA security collection → SecurityEvent

WEF → WEC → AMA → WindowsEvent


41. Key Takeaways

For SC-500, remember these principles:

  1. Azure Monitor Agent (AMA) is the modern agent for Windows event collection.
  2. Data Collection Rules (DCRs) define what AMA collects and where it sends the data.
  3. DCRs can be reused across multiple machines.
  4. XPath provides granular Windows event filtering.
  5. Predefined Windows Security event sets include Minimal and Common, while Custom allows XPath filtering.
  6. WEF forwards Windows events from source computers to a Windows Event Collector (WEC).
  7. WEF can use source-initiated or collector-initiated subscriptions.
  8. AMA can collect the forwarded events from the WEC.
  9. WEF events appear in the WindowsEvent table.
  10. Windows Security Events via AMA events appear in SecurityEvent.
  11. Many Sentinel Windows security analytics rules target SecurityEvent, so table selection matters.
  12. Windows auditing must generate an event before AMA or WEF can collect it.
  13. Azure Arc is important for collecting from non-Azure servers using AMA.
  14. Filtering events can reduce ingestion volume, cost, and investigative noise.
  15. Troubleshoot from the source → agent/WEF → DCR → workspace → Sentinel.

Practice Exam Questions

Question 1

An organization wants to collect Windows Security events directly from Azure virtual machines into Microsoft Sentinel. The security team wants the events to appear in the table commonly used by Microsoft Sentinel’s built-in Windows security analytics rules.

Which solution should you implement?

A. Windows Forwarded Events connector with a WEC server
B. Generic Windows Event Logs DCR targeting the Event table
C. Windows Security Events via AMA connector with a DCR
D. Azure Activity Log connector

Answer: C

Explanation

The Windows Security Events via AMA connector uses Azure Monitor Agent and Data Collection Rules and sends the collected security events to the SecurityEvent table. This is the table used by many built-in Windows security analytics rules.

A WEF architecture instead writes forwarded events to WindowsEvent.


Question 2

You need to collect only Windows Security events with IDs 4624, 4625, and 4688. You want to avoid collecting unrelated Security log events.

Which feature should you use in the Data Collection Rule?

A. Resource locks
B. Azure Policy
C. Microsoft Entra Conditional Access
D. XPath filtering

Answer: D

Explanation

XPath filtering allows a DCR to specify exactly which Windows events should be collected.

For example:

Security!*[System[
(EventID=4624) or
(EventID=4625) or
(EventID=4688)
]]

Azure Policy and resource locks do not perform Windows event filtering.


Question 3

An organization has 2,000 Windows servers. The organization wants the servers to forward selected Windows events to several centralized Windows Event Collector servers before the data is sent to Microsoft Sentinel.

Which technology provides the Windows-to-WEC forwarding capability?

A. Azure Monitor Agent
B. Windows Event Forwarding
C. Azure Private Link
D. Microsoft Defender for Cloud

Answer: B

Explanation

Windows Event Forwarding (WEF) is the Windows-native mechanism used to forward events from Windows event sources to a Windows Event Collector.

AMA can subsequently collect the forwarded events from the WEC and send them to Azure.


Question 4

A company uses WEF to forward Windows Security events from 500 servers to a central WEC. AMA is installed on the WEC, and the Windows Forwarded Events connector is configured in Microsoft Sentinel.

Which table should the security team query?

A. SecurityEvent
B. AzureActivity
C. SigninLogs
D. WindowsEvent

Answer: D

Explanation

The Windows Forwarded Events connector writes forwarded events to the WindowsEvent table.

This remains true even when the original events came from the Windows Security log.

The SecurityEvent table is associated with the Windows Security Events via AMA connector.


Question 5

A security engineer creates a Data Collection Rule containing Windows Security event filters but does not associate the DCR with any virtual machines.

What is the most likely result?

A. The DCR automatically applies to every VM in the subscription
B. The DCR collects events only from the Log Analytics workspace
C. No target machines receive the intended DCR collection configuration
D. Sentinel automatically converts the DCR into an Azure Policy

Answer: C

Explanation

A DCR must be associated with the resources from which data should be collected.

Creating a DCR by itself does not automatically cause every VM in a subscription to use it.


Question 6

An administrator wants to verify whether an XPath expression for Event ID 4688 returns matching events on a Windows server before deploying the expression in a DCR.

Which command is most appropriate?

A.

Get-WinEvent -LogName Security -FilterXPath '*[System[EventID=4688]]'

B.

Get-AzActivityLog -EventId 4688

C.

Get-AzSecurityEvent -EventId 4688

D.

Get-SentinelEvent -EventId 4688

Answer: A

Explanation

Get-WinEvent supports the -FilterXPath parameter and can be used to test XPath expressions against Windows event logs.

This is a useful way to determine whether the XPath is valid and whether matching events exist locally.


Question 7

An organization has configured a source-initiated WEF subscription. Administrators want newly added domain computers to participate in the subscription without manually adding each computer to the subscription configuration.

What is the primary mechanism commonly used to configure the event sources?

A. Azure Resource Manager locks
B. Microsoft Entra Conditional Access
C. Group Policy
D. Azure Policy remediation

Answer: C

Explanation

With a source-initiated WEF subscription, event source computers can be configured through Group Policy to communicate with the appropriate Subscription Manager.

This makes source-initiated subscriptions particularly useful for managing large numbers of Windows systems.


Question 8

A WEF deployment is configured as follows:

  • Windows servers generate Security events.
  • WEF forwards the events.
  • The WEC receives the events.
  • The events are visible in the WEC’s ForwardedEvents log.
  • No events appear in Microsoft Sentinel.

Which component should be investigated first?

A. Windows Security auditing on the source servers
B. AMA and its DCR association on the WEC
C. The Windows Event Forwarding subscription
D. The Windows Security event IDs

Answer: B

Explanation

The fact that events appear in the WEC’s ForwardedEvents log demonstrates that the source-to-WEC WEF portion is functioning.

The next logical part of the pipeline is:

WEC → AMA → DCR → Log Analytics → Sentinel

Therefore, the AMA installation, DCR, and DCR association on the WEC should be investigated.


Question 9

An organization wants to reduce the volume of Windows Security data sent to Microsoft Sentinel while retaining only the events required by several custom detection rules.

Which approach provides the most granular control?

A. Collect the entire Security log and filter only after ingestion
B. Enable all Windows Security events and rely on Sentinel workbooks
C. Use a Custom Windows Security event collection configuration with XPath filtering
D. Use an Azure resource lock

Answer: C

Explanation

A Custom Windows Security event collection configuration allows the administrator to use XPath expressions to select specific event IDs or other event criteria.

Filtering at collection time can reduce unnecessary ingestion and noise.


Question 10

A security engineer wants to use WEF to collect Security events from Windows servers. The WEF subscription appears configured correctly, but Security events are not being forwarded.

Which Windows permission should the engineer specifically investigate?

A. Whether the Network Security Group allows TCP 443 from Azure
B. Whether the VM has a resource lock
C. Whether the Azure subscription has Microsoft Sentinel enabled
D. Whether the NETWORK SERVICE account has the required Event Log Readers membership

Answer: D

Explanation

Forwarding the Windows Security log through WEF requires appropriate permissions. Microsoft documents adding the NETWORK SERVICE account to the Event Log Readers group for Security log forwarding.

This is a particularly useful troubleshooting and exam detail because WEF may successfully operate for other logs while Security log forwarding fails because of permissions.


Final SC-500 Exam Tip

When you see a scenario involving Windows events, first identify where the events originate and how they reach Sentinel.

Ask yourself:

Are events going directly from Windows to Sentinel?
|
+--> AMA + DCR
| |
| +--> SecurityEvent
|
v
Are events being centrally forwarded first?
|
+--> WEF
|
+--> WEC
|
+--> AMA + DCR
|
+--> WindowsEvent

If you can reliably distinguish AMA, DCR, WEF, WEC, SecurityEvent, and WindowsEvent, you will have mastered one of the most important architectural concepts in this portion of the SC-500 exam.


Go to the SC-500 Exam Prep Hub main page

Create custom log tables in the workspace to store ingested data (SC-500 Exam Prep)

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
      --> Create custom log tables in the workspace to store ingested data


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.

Overview

Microsoft Sentinel is built on Azure Monitor Logs, with a Log Analytics workspace serving as the underlying data store. While Microsoft Sentinel provides many predefined tables for common security data sources, organizations frequently need to ingest data that doesn’t fit an existing schema.

For these situations, you can create custom log tables in the Log Analytics workspace and use Data Collection Rules (DCRs) to control how the incoming data is collected, transformed, and routed into those tables.

This topic is part of the Manage and monitor security posture (20–25%) skill area of the SC-500 exam, specifically the Implement activity and event collection in Microsoft Sentinel area.

The key concepts to understand are:

  • Custom Log Analytics tables
  • The _CL naming convention
  • Table schemas and column data types
  • TimeGenerated
  • Data Collection Rules (DCRs)
  • Data Collection Endpoints (DCEs)
  • Logs Ingestion API
  • Ingestion-time transformations
  • Table plans
  • Analytics, Basic, and Auxiliary/Lake tables
  • Custom columns
  • Schema changes
  • KQL querying of custom tables
  • Cost and performance considerations

1. Why Create Custom Log Tables?

Microsoft Sentinel can ingest data from many Microsoft and third-party sources. Standard connectors typically send information into predefined tables such as:

  • SecurityEvent
  • CommonSecurityLog
  • Syslog
  • SigninLogs
  • AzureActivity

However, an organization may have a proprietary application, security product, network device, or custom process that produces information in a format that doesn’t correspond to an existing table.

For example, a company might have an internally developed security application that produces records like:

Timestamp
ApplicationName
UserName
RiskScore
SourceIP
Action
ThreatCategory

Rather than attempting to force this information into an unrelated standard table, the organization can create a custom table such as:

ContosoSecurityEvents_CL

The custom table defines the schema needed to store the incoming data.

Custom tables are particularly useful for:

  • Custom applications
  • Proprietary security solutions
  • Third-party security products
  • Custom scripts
  • Application telemetry
  • Specialized audit data
  • Logs received through the Logs Ingestion API
  • Data that requires a specialized schema

Azure Monitor provides custom tables specifically for situations where the predefined Azure table schemas don’t meet the requirements of the incoming data.


2. Microsoft Sentinel and the Log Analytics Workspace

One of the most important SC-500 concepts is understanding the relationship between Microsoft Sentinel and Azure Monitor Logs.

Conceptually:

                Data Sources
                     |
                     v
          Data Collection / Ingestion
                     |
                     v
          Data Collection Rules
              (DCRs)
                     |
                     v
          Azure Monitor Logs
                     |
                     v
           Log Analytics Workspace
                     |
          +----------+----------+
          |                     |
    Standard Tables       Custom Tables
          |                     |
          +----------+----------+
                     |
                     v
             Microsoft Sentinel
                     |
          +----------+----------+
          |          |          |
       Queries    Analytics   Incidents

Microsoft Sentinel does not maintain a completely separate log database. Sentinel uses Azure Monitor Logs, and the logs are stored in the associated Log Analytics workspace.

Therefore, when an SC-500 question asks you to create a custom table “in the workspace,” think:

Log Analytics workspace → custom table → DCR/ingestion → Microsoft Sentinel queries and analytics


3. What Is a Custom Log Table?

A custom table is a Log Analytics table whose schema is defined by the organization rather than being a predefined Azure service schema.

A typical custom table might be:

ContosoSecurityEvents_CL

The _CL suffix identifies a custom log table.

For example:

Table: ContosoSecurityEvents_CL
Columns:
TimeGenerated datetime
ApplicationName string
UserName string
SourceIP string
RiskScore int
Action string
ThreatCategory string

The table schema determines the structure of the data that can be stored and queried.

The Azure portal automatically adds _CL when you create a custom table through the portal. When creating a custom table through other methods, such as APIs or CLI, the _CL suffix needs to be specified.

SC-500 Exam Tip

If a question asks:

“Which table naming convention should be used for a custom Log Analytics table?”

The expected answer is generally:

_CL

For example:

NetworkThreats_CL
ApplicationAudit_CL
CustomSecurityEvents_CL

4. Custom Table Schema

The schema defines the columns and data types available in the table.

Common data types include:

Data TypeTypical Use
stringUsernames, IP addresses, application names
intInteger values
longLarge integer values
realDecimal/numeric values
booleanTrue/false values
datetimeTimestamps
dynamicJSON or complex structured data

For example:

ContosoSecurityEvents_CL
TimeGenerated datetime
ApplicationName string
UserName string
SourceIP string
RiskScore int
IsMalicious boolean
EventData dynamic

The choice of data type matters because it affects how the information can be queried and analyzed.

For example, if RiskScore is stored as an integer, queries can perform numerical comparisons:

ContosoSecurityEvents_CL
| where RiskScore >= 80
| order by RiskScore desc

If the same value were stored as a string, numerical analysis would be more cumbersome.


5. The Importance of TimeGenerated

A particularly important requirement is the TimeGenerated column.

Log Analytics tables use TimeGenerated to represent the time associated with the log record. Custom tables must have a TimeGenerated column.

If the incoming sample data doesn’t contain an appropriate TimeGenerated value when creating a custom table, Azure Monitor can create a transformation to add one.

For example:

TimeGenerated datetime
EventType string
SourceIP string
UserName string
Action string

This allows queries such as:

ContosoSecurityEvents_CL
| where TimeGenerated > ago(24h)
| summarize Count=count() by Action

Exam Tip

Remember:

Every Log Analytics table needs TimeGenerated.

It is one of the easiest details for an SC-500 question to test.


6. Data Collection Rules (DCRs)

Creating the table is only part of the process.

You also need a mechanism to control how the incoming data reaches the table.

That is where Data Collection Rules (DCRs) come into play.

A DCR defines how data is:

  1. Collected
  2. Filtered
  3. Transformed
  4. Routed
  5. Sent to a destination

Conceptually:

Source Data
|
v
+----------------------+
| Data Collection Rule |
| |
| Collect |
| Filter |
| Transform |
| Route |
+----------------------+
|
v
Custom Table
|
v
Log Analytics Workspace

DCRs can therefore provide an ingestion-time processing layer between the source and the destination table.


7. DCR Data Flows

A DCR can define the relationship between an incoming data stream and the destination table.

For example:

CustomSecurityStream
|
v
DCR
|
+---- Transformation
|
v
ContosoSecurityEvents_CL

The destination table name in the DCR must correspond to the custom table.

For example:

ContosoSecurityEvents_CL

The DCR data flow must target:

ContosoSecurityEvents_CL

A mismatch between the table definition and the DCR is a common configuration problem.


8. Ingestion-Time Transformations

One of the most powerful capabilities associated with custom ingestion is ingestion-time transformation.

A DCR can use a KQL transformation to manipulate incoming records before they are stored.

For example, suppose incoming records contain:

UserName
SourceIP
RiskScore
Action

A transformation could:

  • Remove unwanted records
  • Rename or derive values
  • Normalize information
  • Add calculated information
  • Mask sensitive information
  • Convert values
  • Enrich records
  • Reduce unnecessary data

Conceptually:

Raw Data
|
v
DCR
|
v
KQL Transformation
|
+---- Filter unwanted records
|
+---- Transform fields
|
+---- Enrich/normalize data
|
v
Custom Table

Microsoft Sentinel supports DCR-based transformations for custom data ingestion, and transformations can filter, enrich, or mask incoming data before it is stored.


9. Example Transformation

Suppose incoming data contains a numeric risk score:

RiskScore

You might want to classify the event during ingestion.

Conceptually, a transformation could produce:

RiskLevel

based on the score.

For example:

source
| extend RiskLevel =
case(
RiskScore >= 90, "Critical",
RiskScore >= 70, "High",
RiskScore >= 40, "Medium",
"Low"
)

The resulting record can then be stored in the destination custom table.

This approach is useful because the data is normalized before analysts and Sentinel analytics rules consume it.


10. Logs Ingestion API

The Logs Ingestion API provides another important method for sending custom-format data into Azure Monitor Logs.

It is particularly useful when an application or external system needs to send data programmatically.

Conceptually:

Custom Application
|
| HTTPS
v
Logs Ingestion API
|
v
DCR
|
v
Transformation
|
v
Custom Table

The Logs Ingestion API can send custom-format logs into Log Analytics tables, including custom tables, while DCRs define the data flow and transformations.

Example Scenario

A company has an internally developed fraud-detection application.

The application generates:

{
"user": "jsmith",
"sourceIP": "10.10.20.15",
"riskScore": 94,
"action": "Blocked"
}

The application could send these records through the Logs Ingestion API.

The DCR could transform the data and route it to:

FraudDetection_CL

Microsoft Sentinel could then query that table for detections.


11. Data Collection Endpoints (DCEs)

A Data Collection Endpoint (DCE) can provide an ingestion endpoint for Azure Monitor data collection scenarios.

A common architecture is:

Application
|
v
Data Collection Endpoint
|
v
Data Collection Rule
|
v
Log Analytics Workspace
|
v
Custom Table

Not every DCR scenario requires a separately created DCE. For example, current Azure Monitor documentation describes a DCR with kind set to Direct that can create its own Logs Ingestion endpoint.

Exam Tip

Do not automatically assume:

“Every custom table requires a DCE.”

Instead, determine what ingestion mechanism the scenario specifies.


12. Creating a Custom Table in the Azure Portal

A typical portal workflow is:

Step 1 — Open the Log Analytics workspace

Navigate to the appropriate:

Log Analytics workspace

Step 2 — Open Tables

Select:

Tables

Step 3 — Create a table

Select:

Create

Step 4 — Specify the table name

For example:

ContosoSecurityEvents

The portal creates the custom table as:

ContosoSecurityEvents_CL

Step 5 — Select the table plan

Choose the appropriate table plan.

Step 6 — Associate a DCR

Select an existing DCR or create a new one.

Step 7 — Select the DCE if required

Depending on the ingestion scenario, select an appropriate Data Collection Endpoint.

Step 8 — Provide sample data

A JSON sample can be used to help define the schema.

For example:

{
"TimeGenerated": "2026-09-13T14:30:00Z",
"ApplicationName": "FraudDetection",
"UserName": "jsmith",
"SourceIP": "10.10.20.15",
"RiskScore": 94,
"Action": "Blocked"
}

Step 9 — Configure transformations

If required, use the transformation editor.

Step 10 — Review the schema

Verify:

  • Column names
  • Data types
  • TimeGenerated
  • Destination table
  • Transformation
  • Table plan

Step 11 — Create the table

After validation, create the custom table.

This workflow is supported directly through the Log Analytics workspace Tables experience.


13. Custom Table Naming Rules

There are several schema rules worth remembering.

A custom table uses:

<TableName>_CL

For example:

FirewallEvents_CL

Custom column names have their own restrictions. They must:

  • Start with a letter
  • Use letters, digits, and underscores
  • Avoid spaces
  • Avoid dots
  • Avoid dashes
  • Avoid other punctuation
  • Follow the applicable length restrictions

Custom column names added to Azure tables use the _CF suffix.

Good examples

SourceIP
UserName
RiskScore
ThreatCategory
DeviceName

Poor examples

Source-IP
Source IP
Source.IP
123SourceIP

14. Updating a Custom Table Schema

Custom tables aren’t necessarily static.

For example, you might initially have:

TimeGenerated
UserName
SourceIP
Action

Later, the application begins producing:

ThreatCategory

You may add a custom column to accommodate the new information.

However, there is an important consideration:

When the table schema changes, the DCR that sends data to the table must also be updated as appropriate.

Azure Monitor does not automatically update your DCR simply because you modified the destination table schema.

This is a very useful SC-500 exam distinction.

Think of it this way:

Table Schema
^
|
Must remain compatible with
|
v
DCR Schema / Data Flow
^
|
Incoming Data

If these components don’t agree, ingestion can fail or produce unexpected results.


15. Table Plans

A custom table can use different table plans depending on the organization’s requirements.

Current Azure Monitor Logs supports:

Table PlanTypical Purpose
AnalyticsFrequent querying, monitoring, detections, and complex analysis
BasicCost-effective storage for data that is queried less frequently
Auxiliary / LakeHigh-volume or verbose data where inexpensive long-term storage is important

Analytics is the default plan when creating a custom table through the standard workflow. DCR-based custom tables support the available table plans, subject to the capabilities and limitations of each plan.

Choosing a plan

Consider:

  • How frequently the data will be queried
  • Whether the data supports active security detections
  • Query capabilities required
  • Data volume
  • Retention requirements
  • Cost

For example:

High-value security events

Authentication failures
Critical threat alerts
Security detections

These are likely candidates for an Analytics plan when frequent investigation and detection are required.

Large-volume historical data

Verbose application telemetry
Long-term diagnostic information
High-volume historical records

A lower-cost storage-oriented plan may be more appropriate, depending on the required capabilities.


16. Custom Tables Versus Standard Tables

Understanding the difference is important for the SC-500 exam.

CharacteristicStandard TableCustom Table
SchemaPredefinedOrganization-defined
NamingMicrosoft-defined_CL suffix
Typical sourceMicrosoft service/connectorCustom or specialized source
Schema flexibilityMore constrainedMore flexible
DCR supportDepends on connectorCommonly used
TransformationDepends on ingestion methodStrongly supported through DCR
ExampleSecurityEventSecurityAlerts_CL

The general principle is:

Use a standard table when the data naturally belongs to an existing Microsoft schema; use a custom table when the data requires its own schema.


17. Querying a Custom Table with KQL

Once data is successfully ingested, it can be queried using Kusto Query Language (KQL).

Suppose the table is:

ContosoSecurityEvents_CL

A simple query is:

ContosoSecurityEvents_CL
| take 100

To retrieve recent events:

ContosoSecurityEvents_CL
| where TimeGenerated > ago(24h)
| order by TimeGenerated desc

To identify high-risk events:

ContosoSecurityEvents_CL
| where RiskScore >= 80
| project TimeGenerated, UserName, SourceIP, RiskScore, Action
| order by RiskScore desc

To summarize events by action:

ContosoSecurityEvents_CL
| summarize EventCount=count() by Action
| order by EventCount desc

18. Custom Tables and Microsoft Sentinel Analytics Rules

Once data exists in a custom table, Microsoft Sentinel can use that data for security monitoring.

For example:

Custom Application
|
v
SecurityEvents_CL
|
v
Microsoft Sentinel
|
+---- Analytics Rule
|
+---- Hunting Query
|
+---- Workbook
|
+---- Investigation
|
+---- Automation

Suppose an organization wants to detect:

A user generating three or more high-risk fraud events within 10 minutes.

A Sentinel analytics rule could query:

FraudDetection_CL
| where TimeGenerated > ago(10m)
| where RiskScore >= 90
| summarize EventCount=count() by UserName
| where EventCount >= 3

This illustrates an important concept:

Creating the custom table does not itself create a security detection.

The table stores the data. Sentinel analytics rules, hunting queries, workbooks, and other capabilities consume the data.


19. Permissions

Managing tables requires appropriate permissions on the Log Analytics workspace.

For example, permissions such as:

Microsoft.OperationalInsights/workspaces/*

at the appropriate workspace scope can allow table management. The Log Analytics Contributor role is an example of a built-in role that can provide the necessary permissions.

This should not be confused with permission to simply query the data.

There is an important distinction between:

Managing the table

and:

Reading/querying the data

An SC-500 scenario may therefore provide a user who can query logs but cannot create or modify a table.


20. Security and Privacy Considerations

Custom tables can contain sensitive information.

Avoid placing sensitive information in:

  • Table names
  • Column names unnecessarily
  • Diagnostic metadata
  • Uncontrolled raw log fields

For example, don’t name a table:

CustomerSocialSecurityNumbers_CL

even if the table happens to contain that information.

Instead, use a neutral operational name such as:

CustomerSecurityEvents_CL

Azure documentation specifically cautions against including sensitive information in custom table names because table names are used for billing.

DCR transformations can also be used to reduce unnecessary data, mask information, or remove irrelevant records before they are stored.


21. Controlling Ingestion Volume

One of the biggest operational concerns with custom logging is simply collecting too much data.

Suppose an application produces:

10 million events/day

but only:

100,000 events/day

are relevant to security monitoring.

Sending everything to Sentinel may increase:

  • Ingestion costs
  • Storage requirements
  • Query time
  • Noise
  • Investigation complexity

A DCR transformation can help filter irrelevant information before storage.

Conceptually:

10,000,000 Events
|
v
DCR
|
Filter/Transform
|
v
100,000 Useful Events
|
v
Custom Table

This is one of the strongest reasons to understand DCRs rather than thinking of them simply as “connectors.”


22. Example: Custom Security Application

Consider an organization with an internal security application called ThreatWatch.

ThreatWatch produces:

Timestamp
DeviceName
UserName
SourceIP
ThreatType
Severity
Action

The security team wants the data available in Microsoft Sentinel.

Step 1 — Create the table

ThreatWatchEvents_CL

Step 2 — Define the schema

TimeGenerated datetime
DeviceName string
UserName string
SourceIP string
ThreatType string
Severity int
Action string

Step 3 — Configure ingestion

The application sends records through an appropriate Azure Monitor ingestion mechanism.

Step 4 — Configure the DCR

The DCR:

  • Defines the incoming stream
  • Maps the fields
  • Applies transformations
  • Routes the records to ThreatWatchEvents_CL

Step 5 — Validate ingestion

Run:

ThreatWatchEvents_CL
| take 20

Step 6 — Create detections

For example:

ThreatWatchEvents_CL
| where Severity >= 8
| summarize HighSeverityEvents=count() by DeviceName
| where HighSeverityEvents >= 5

The resulting data can then participate in Sentinel investigations and detections.


23. Troubleshooting Custom Table Ingestion

When data isn’t appearing in a custom table, troubleshoot from the source toward the destination.

Step 1 — Verify the source

Is the application actually generating the expected data?

Step 2 — Verify the ingestion mechanism

Is the application correctly sending records?

Step 3 — Verify the DCE, if applicable

Is the ingestion endpoint correctly configured and reachable?

Step 4 — Verify the DCR

Check:

  • Data source
  • Stream
  • Transformation
  • Destination
  • Table name
  • Schema

Step 5 — Verify the table

Confirm:

TableName_CL

exists in the intended workspace.

Step 6 — Verify the schema

Make sure the incoming data matches the expected column types.

Step 7 — Query the table

For example:

ThreatWatchEvents_CL
| take 10

Step 8 — Check the time range

Don’t forget that the portal’s default query time range may exclude newly arriving data.


24. Common SC-500 Exam Traps

Trap 1: Confusing a custom table with a DCR

A DCR controls data collection and processing.

A custom table stores the resulting data.

They are related but are not the same thing.


Trap 2: Forgetting _CL

Custom tables use the _CL suffix.

MySecurityData_CL

Trap 3: Forgetting TimeGenerated

Custom Log Analytics tables require a TimeGenerated column.


Trap 4: Assuming the table automatically changes the DCR

It doesn’t.

If the table schema changes, review and update the DCR as necessary.


Trap 5: Assuming all data belongs in standard tables

If a data source has a unique schema that doesn’t fit an existing table, a custom table may be appropriate.


Trap 6: Confusing ingestion with detection

A custom table stores data.

A Sentinel analytics rule detects conditions in that data.

Creating the table doesn’t automatically create an incident.


Trap 7: Assuming all custom data must use the same table plan

Table-plan selection should be based on how the data will be used, queried, and retained.


Trap 8: Assuming a DCE is mandatory in every scenario

The required ingestion architecture depends on the ingestion mechanism and DCR configuration.


25. Best Practices

1. Design the schema before collecting data

Determine:

  • What fields are actually required
  • Appropriate data types
  • Which fields analysts will query
  • Which fields support detections

2. Use meaningful table names

For example:

FirewallThreats_CL
IdentityRiskEvents_CL
ApplicationSecurity_CL

3. Keep schemas consistent

Avoid frequently changing schemas unless there is a genuine requirement.

4. Use appropriate data types

Don’t store numeric values as strings unless there is a reason to do so.

5. Use DCR transformations

Filter unnecessary records and normalize data before ingestion when appropriate.

6. Minimize sensitive information

Don’t collect or retain sensitive information unnecessarily.

7. Select the table plan based on actual usage

Consider query frequency, detection requirements, retention, and cost.

8. Validate ingestion before creating detections

First confirm:

Data source
↓
DCR
↓
Custom table
↓
KQL query

Then build analytics rules.

9. Monitor ingestion volume

Unexpected increases in custom log volume can have both financial and operational consequences.

10. Treat the DCR and table schema as a coordinated design

A healthy ingestion architecture requires the source, DCR, transformation, and destination schema to agree.


26. SC-500 Exam-Focused Summary

For this topic, remember the following relationships:

ConceptWhat You Should Remember
Log Analytics workspaceStores the logs used by Microsoft Sentinel
Custom tableStores data using an organization-defined schema
_CLCustom log table naming suffix
TimeGeneratedRequired time column for Log Analytics tables
DCRControls collection, transformation, and routing
DCEProvides an ingestion endpoint for applicable ingestion scenarios
Logs Ingestion APIProgrammatic ingestion of custom-format data
TransformationProcesses incoming data before storage
Analytics planBest suited to active querying/analytics
Basic planCost-oriented storage for less-frequent access
Auxiliary/LakeHigh-volume/inexpensive storage scenarios
KQLUsed to query the resulting table
Sentinel analytics ruleUses the data to identify security conditions

The most important architectural model is:

                DATA SOURCE
                     |
                     v
          +---------------------+
          | Ingestion Mechanism |
          +---------------------+
                     |
                     v
          +---------------------+
          |        DCR          |
          |                     |
          | Collect             |
          | Transform           |
          | Filter              |
          | Route               |
          +---------------------+
                     |
                     v
          +---------------------+
          | Custom Log Table    |
          |     *_CL            |
          +---------------------+
                     |
                     v
          Log Analytics Workspace
                     |
                     v
            Microsoft Sentinel
                     |
          +----------+----------+
          |          |          |
       Hunting   Analytics   Workbooks
                     |
                     v
                Incidents

27. Key Takeaways

Before taking the SC-500 exam, make sure you can explain:

  1. Why an organization would create a custom Log Analytics table.
  2. How a custom table differs from a standard Azure Monitor table.
  3. Why custom tables use the _CL suffix.
  4. Why TimeGenerated is important.
  5. How a DCR controls data collection and routing.
  6. How ingestion-time transformations work.
  7. When the Logs Ingestion API can be used.
  8. The purpose of a DCE in applicable ingestion architectures.
  9. How table schemas and DCR schemas must remain consistent.
  10. How to choose between Analytics, Basic, and Auxiliary/Lake table plans.
  11. How to query a custom table using KQL.
  12. Why controlling ingestion volume is important for both cost and security operations.
  13. The difference between storing security data and creating a Sentinel detection.
  14. How to troubleshoot a custom ingestion pipeline from source to destination.

Practice Exam Questions

Question 1

A security team has developed an internal application that generates security events in a proprietary JSON format. No existing Microsoft Sentinel table has an appropriate schema for the data.

The team wants to store the events in the Log Analytics workspace.

What should you create?

A. A Microsoft Sentinel workbook
B. A custom Log Analytics table
C. An automation rule
D. A resource lock

Answer: B

Explanation

A custom Log Analytics table is appropriate when incoming data has a schema that doesn’t fit an existing standard table. The table allows the organization to define the columns and data types required for the proprietary data.

A workbook visualizes data, an automation rule responds to conditions, and a resource lock protects Azure resources; none provides the required storage schema.


Question 2

A security engineer creates a custom Log Analytics table named:

NetworkThreats

The table is created through an Azure management interface that requires the complete table name.

Which name should be used?

A. NetworkThreats_LOG
B. NetworkThreats_CUSTOM
C. NetworkThreats_SENTINEL
D. NetworkThreats_CL

Answer: D

Explanation

Custom Log Analytics tables use the _CL suffix.

Therefore, the table should be:

NetworkThreats_CL

The Azure portal can add the suffix automatically when creating the table through the portal, but when using other creation mechanisms, the _CL suffix must be specified as required.


Question 3

A company creates a custom table for application security events. The application sends records containing:

UserName
SourceIP
RiskScore
Action

The records don’t contain a timestamp.

Which column must be available in the custom table to satisfy the Log Analytics table requirement?

A. TimeGenerated
B. EventID
C. SourceComputer
D. Severity

Answer: A

Explanation

Log Analytics tables require a TimeGenerated column. If the incoming sample does not provide an appropriate TimeGenerated value, Azure Monitor can create a transformation to add one during the custom-table creation process.

The other columns aren’t universally required for custom tables.


Question 4

A company sends custom application logs to Microsoft Sentinel. Before the logs are stored, the security team wants to remove irrelevant records and calculate a new field called RiskLevel.

Which capability is most appropriate?

A. Microsoft Sentinel workbook
B. Azure resource lock
C. DCR-based ingestion-time transformation
D. Microsoft Entra Conditional Access

Answer: C

Explanation

A DCR-based ingestion-time transformation can process incoming records before they are stored. KQL can be used to filter records, calculate values, normalize data, enrich records, or mask information.

A workbook operates on data after ingestion, a resource lock protects Azure resources, and Conditional Access controls identity access.


Question 5

A developer needs to send proprietary application logs programmatically to a custom table in a Log Analytics workspace.

Which Azure capability is specifically designed for programmatic ingestion of custom-format logs?

A. Logs Ingestion API
B. Azure Resource Graph
C. Microsoft Sentinel workbook API
D. Azure Policy

Answer: A

Explanation

The Logs Ingestion API allows applications and other data sources to send custom-format log data into Azure Monitor Logs. DCRs can define the data flow and transformations, and the data can be stored in a custom table.

Azure Resource Graph is primarily used to query Azure resource metadata, while Azure Policy governs resource configuration.


Question 6

An administrator adds a new column to an existing custom table. The DCR that sends data to the table has not been modified.

What should the administrator do?

A. Delete the Microsoft Sentinel workspace
B. Review and update the DCR so its schema/data flow remains compatible with the table
C. Recreate every Sentinel analytics rule
D. Disable Microsoft Sentinel and enable it again

Answer: B

Explanation

When the schema of a custom table changes, the associated DCRs should also be reviewed and updated as necessary. Azure Monitor doesn’t automatically update DCRs when the destination table schema changes.

This is an important exam concept:

Table schema changes and DCR schema/data-flow definitions must remain synchronized.


Question 7

A security operations team needs to store a very high volume of verbose application telemetry. The data is primarily intended for inexpensive long-term storage and aggregated trend analysis rather than frequent interactive security investigations.

Which table plan is most appropriate to investigate first?

A. Analytics
B. Premium
C. Basic
D. Auxiliary/Lake

Answer: D

Explanation

The Auxiliary/Lake plan is designed for high-volume, verbose data scenarios where inexpensive long-term storage and aggregated analysis are important.

Analytics is generally better suited to frequently queried operational and security analytics workloads. Basic can provide cost-effective storage for less frequently accessed data, but the scenario specifically emphasizes high-volume verbose data and inexpensive long-term storage.


Question 8

A security team wants a custom table containing security events that analysts will query frequently and that will be used for continuous monitoring and threat detection.

Which table plan is generally the best starting point?

A. Analytics
B. Auxiliary/Lake
C. Basic
D. Archive-only

Answer: A

Explanation

The Analytics plan is designed for active querying, continuous monitoring, real-time detection, and more comprehensive analytics capabilities.

Because the scenario emphasizes frequent querying and security detections, Analytics is the most appropriate choice.


Question 9

A security engineer successfully creates:

ThreatEvents_CL

in a Log Analytics workspace.

However, when running:

ThreatEvents_CL
| take 10

no records are returned.

The engineer verifies that the table exists.

What should be investigated next?

A. The ingestion source, DCR, transformation, destination mapping, and schema
B. Whether the workspace has a resource lock
C. Whether a Sentinel workbook has been created
D. Whether Conditional Access requires MFA

Answer: A

Explanation

Creating a table does not automatically populate it.

The administrator should trace the ingestion pipeline:

Source
↓
Ingestion mechanism
↓
DCR
↓
Transformation
↓
Destination table

The DCR configuration, stream, transformation, destination table name, and schema should all be validated.


Question 10

A company wants to use custom security data in Microsoft Sentinel to generate incidents when suspicious activity is detected.

Which statement correctly describes the relationship between the custom table and the Sentinel analytics rule?

A. Creating the custom table automatically creates an analytics rule
B. The analytics rule replaces the custom table after the first detection
C. The custom table stores the data, while the analytics rule evaluates the data for detection conditions
D. The custom table can only be queried by workbooks

Answer: C

Explanation

The custom table stores the ingested data.

A Microsoft Sentinel analytics rule can query that data and determine whether a specified security condition has occurred. If configured appropriately, the analytics rule can generate an alert or incident.

The two components therefore serve different purposes:

Custom Table
↓
Stores security data
Analytics Rule
↓
Evaluates security data
↓
Generates detection/alert/incident

This distinction is fundamental to understanding Microsoft Sentinel’s architecture.


Go to the SC-500 Exam Prep Hub main page