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
SecurityEventandWindowsEventtables. - 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 ID | Typical activity |
|---|---|
| 4624 | Successful logon |
| 4625 | Failed logon |
| 4648 | Logon using explicit credentials |
| 4672 | Special privileges assigned to a new logon |
| 4688 | New process created |
| 4697 | Service installed |
| 4720 | User account created |
| 4728 | Member added to a security-enabled global group |
| 4732 | Member added to a security-enabled local group |
| 4740 | User account locked out |
| 4768 | Kerberos authentication ticket requested |
| 4769 | Kerberos service ticket requested |
| 4771 | Kerberos preauthentication failed |
| 5140 | Network share accessed |
| 5145 | Network 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 vAzure Monitor Agent (AMA) | | DCR defines what to collect vData Collection Rule (DCR) | vLog Analytics Workspace | vMicrosoft 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:
- Data sources
- Streams
- Destinations
- Data flows
- Filtering criteria such as XPath expressions
- 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:
- Event source configuration
- WEF subscription
- WinRM
- Event Collector service
- Event Log Readers permissions
- Security log auditing
- Event filters
15. Windows Forwarded Events Connector
Microsoft Sentinel has a Windows Forwarded Events data connector.
Its architecture is:
Windows Event Sources | | WEF vWindows Event Collector | | AMA vDCR | vLog Analytics | vWindowsEvent table | vMicrosoft Sentinel
The Windows Forwarded Events connector is different from Windows Security Events via AMA.
The key difference is the destination table:
| Collection method | Sentinel table |
|---|---|
| Windows Security Events via AMA | SecurityEvent |
| Windows Forwarded Events | WindowsEvent |
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 v10 regional WEC servers | | AMA vMicrosoft 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 | vLog Analytics | vWindowsEvent
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 SentinelOn-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 type | Possible strategy |
|---|---|
| Domain controllers | Broad security event collection |
| Tier-0 systems | Extensive security auditing |
| Production application servers | Focused collection |
| Development servers | Reduced collection |
| Workstations | Security-focused collection |
| High-volume systems | Custom 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:
| Requirement | Recommended approach |
|---|---|
| Basic threat visibility | Minimal |
| Broader security monitoring | Common |
| Specific security requirements | Custom |
| Strict ingestion-cost control | Custom |
| Specialized detection | Custom |
| Need a predefined baseline | Minimal/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
| Event | Meaning |
|---|---|
| 4624 | Successful logon |
| 4625 | Failed logon |
| 4648 | Explicit credentials used |
| 4672 | Special privileges assigned |
Process activity
| Event | Meaning |
|---|---|
| 4688 | New process created |
| 4689 | Process exited |
Account management
| Event | Meaning |
|---|---|
| 4720 | User account created |
| 4722 | User account enabled |
| 4724 | Attempt to reset account password |
| 4728 | Member added to global security group |
| 4732 | Member added to local security group |
| 4740 | Account locked out |
| 4767 | Account unlocked |
Kerberos
| Event | Meaning |
|---|---|
| 4768 | Kerberos authentication ticket requested |
| 4769 | Kerberos service ticket requested |
| 4771 | Kerberos preauthentication failed |
Network/share access
| Event | Meaning |
|---|---|
| 5140 | Network share accessed |
| 5145 | Network 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 | vSecurity event generated | vWEF or AMA | vDCR | vLog Analytics | vSentinel
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? vWEF configuration | | 2. Event forwarded? vWEC | | 3. Event in ForwardedEvents? vAMA | | 4. Agent collecting? vDCR | | 5. Correct collection rule? vSentinel
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
ForwardedEventslog. - Sentinel has no events.
Where should you troubleshoot next?
The likely problem is after WEF, because WEF itself is working.
Check:
- AMA on the WEC
- DCR
- DCR association
- Destination workspace
- Sentinel connector
- 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, notSecurityEvent.
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
| Characteristic | Windows Security Events via AMA | Windows Forwarded Events |
|---|---|---|
| Agent | AMA | AMA |
| DCR | Yes | Yes |
| Source | Windows machine | WEF collector |
| WEF required? | No | Yes |
| Primary Sentinel table | SecurityEvent | WindowsEvent |
| Multiple source servers | Directly supported | Aggregated through WEC |
| XPath filtering | Yes | Can be applied through collection configuration |
| Useful for centralized WEF architecture | Not required | Yes |
| Built-in rules commonly targeting SecurityEvent | Yes | May require adaptation/union |
| Non-Azure servers | Azure Arc + AMA | WEC 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
SecurityEventtable is preferred - Existing analytics content relies heavily on
SecurityEvent
Architecture:
Windows Server | | AMA v DCR | vSecurityEvent | vMicrosoft 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 | vNormalized 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
| Scenario | Best answer/concept |
|---|---|
| Collect Windows Security events directly into Sentinel | Windows Security Events via AMA |
| Control collection using reusable rules | DCR |
| Filter Windows events by Event ID | XPath |
| Forward events from many Windows machines to a central Windows server | WEF |
| Receive WEF events | Windows Event Collector |
| Send WEC events to Azure | AMA |
| WEF events in Sentinel | WindowsEvent |
| Direct Windows Security Events via AMA | SecurityEvent |
| Centralized source configuration through Group Policy | Source-initiated WEF |
| Collector explicitly maintains source list | Collector-initiated WEF |
| Non-Azure Windows server using AMA | Azure Arc |
| Test XPath locally | Get-WinEvent -FilterXPath |
| Check WEF subscription runtime | wecutil gr |
| Normalize security data | ASIM |
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:
- Azure Monitor Agent (AMA) is the modern agent for Windows event collection.
- Data Collection Rules (DCRs) define what AMA collects and where it sends the data.
- DCRs can be reused across multiple machines.
- XPath provides granular Windows event filtering.
- Predefined Windows Security event sets include Minimal and Common, while Custom allows XPath filtering.
- WEF forwards Windows events from source computers to a Windows Event Collector (WEC).
- WEF can use source-initiated or collector-initiated subscriptions.
- AMA can collect the forwarded events from the WEC.
- WEF events appear in the
WindowsEventtable. - Windows Security Events via AMA events appear in
SecurityEvent. - Many Sentinel Windows security analytics rules target
SecurityEvent, so table selection matters. - Windows auditing must generate an event before AMA or WEF can collect it.
- Azure Arc is important for collecting from non-Azure servers using AMA.
- Filtering events can reduce ingestion volume, cost, and investigative noise.
- 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
ForwardedEventslog. - 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 | vAre 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
