Tag: Azure Monitor Agent (AMA)

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