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 syslog and Common Event Format (CEF) event collections

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 designed to collect security telemetry from a wide variety of sources, including Azure services, Microsoft services, Windows systems, Linux systems, network devices, firewalls, security appliances, and third-party applications.

Two important technologies for collecting events from external and Linux-based sources are:

• Syslog
• Common Event Format (CEF)

For the SC-500 exam, it is important to understand not only what Syslog and CEF are, but also how they are collected by Microsoft Sentinel, how Azure Monitor Agent (AMA) and Data Collection Rules (DCRs) fit into the architecture, how log forwarders work, how filtering is configured, and how to troubleshoot ingestion problems.

Microsoft’s current architecture uses the Syslog via AMA and CEF via AMA connectors. These connectors use Azure Monitor Agent on a Linux machine and use DCRs to define what data is collected and where it is sent.

1. What Is Syslog?

Syslog is a standard protocol and message format used to send logging information between applications, servers, network devices, and security appliances.

It is especially common in:

• Linux and Unix systems
• Firewalls
• Routers
• Network switches
• VPN appliances
• Intrusion detection/prevention systems
• Security appliances
• Network monitoring systems
• Applications that support Syslog

Syslog messages contain information such as:

• Priority
• Timestamp
• Host
• Application/process
• Process ID
• Message content

Azure Monitor Agent supports Syslog messages formatted according to RFC 3164 (BSD Syslog) and RFC 5424 (IETF Syslog). Syslog can be transported using protocols such as UDP, TCP, or TLS, depending on the source and configuration.

Why Syslog matters to Sentinel

Many security devices do not provide a native Microsoft Sentinel connector. Instead, they can send Syslog messages to a Linux-based collector, which forwards those messages to Microsoft Sentinel.

This allows Sentinel to ingest security events from a large ecosystem of third-party devices.

2. What Is Common Event Format (CEF)?

Common Event Format (CEF) is a vendor-neutral security event format designed to make events from different security products easier for SIEM systems to consume and analyze.

CEF is commonly used by:

• Firewalls
• Intrusion detection systems
• Intrusion prevention systems
• Endpoint security products
• Security appliances
• Network devices
• Web security products
• Detection and response platforms

CEF is essentially a standardized security-event structure transported using Syslog.

A CEF message contains a standardized header followed by optional extension fields.

A simplified structure looks like this:

<Priority>Timestamp Hostname CEF:Version|Device Vendor|Device Product|Device Version|Device Event Class ID|Name|Severity|Extension

For example:

Jan 18 11:07:53 host CEF:0|Contoso|Firewall|1.0|100|Blocked Connection|5|src=10.0.0.10 dst=10.0.0.20

The CEF header identifies the product and event, while the extension section can contain additional information such as:

• Source IP
• Destination IP
• Source port
• Destination port
• Username
• URL
• File name
• Action
• Protocol

Microsoft Sentinel parses CEF events into the CommonSecurityLog table.

3. Syslog vs. CEF

Although Syslog and CEF are closely related, they are not the same thing.

Exam tip

Remember:

Syslog → Syslog table

CEF → CommonSecurityLog table

This is one of the simplest and most useful SC-500 facts to remember.

4. Current Microsoft Sentinel Architecture

The current Microsoft Sentinel architecture for Syslog and CEF uses:

Log Source → Linux Syslog Daemon → Azure Monitor Agent → DCR → Log Analytics Workspace → Microsoft Sentinel

For example:

Firewall
   |
   | CEF
   v
Linux Log Forwarder
   |
   | rsyslog / syslog-ng
   |
   v
Azure Monitor Agent
   |
   | DCR filtering
   v
Log Analytics Workspace
   |
   +---- Syslog table
   |
   +---- CommonSecurityLog table
   |
   v
Microsoft Sentinel

Microsoft’s current connectors install Azure Monitor Agent on the Linux collection machine and use Data Collection Rules to determine what data should be collected and filtered.

5. What Is Azure Monitor Agent?

Azure Monitor Agent (AMA) is Microsoft’s current agent for collecting telemetry from supported systems and sending it to Azure Monitor and Microsoft Sentinel.

For Syslog and CEF collection, AMA runs on a Linux machine.

That Linux machine can be:

• An Azure Linux VM
• An Azure Arc-enabled server
• A Linux VM in another cloud
• An on-premises Linux server
• A dedicated log-forwarding server

The machine can either generate the logs itself or act as a log forwarder for other systems.

Microsoft specifically supports using a Linux machine as a forwarder for network and security appliances that cannot have an agent installed directly.

6. What Is a Log Forwarder?

A log forwarder is a Linux machine that receives Syslog or CEF messages from other devices and forwards those messages to Microsoft Sentinel.

For example:

             +----------------+
             |    Firewall    |
             +-------+--------+
                     |
                     | CEF
                     v
             +----------------+
             | Linux Forwarder|
             |                |
             | rsyslog        |
             | AMA            |
             +-------+--------+
                     |
                     | Azure Monitor Agent
                     v
             +----------------+
             | Log Analytics  |
             |    Workspace   |
             +-------+--------+
                     |
                     v
             +----------------+
             |    Sentinel    |
             +----------------+

The forwarder is particularly useful when the original device:

• Cannot run AMA
• Cannot communicate directly with Azure
• Is a network appliance
• Is a firewall
• Is an appliance managed by a third-party vendor

Microsoft supports both Azure-hosted and non-Azure Linux forwarding machines. For non-Azure machines, Azure Arc can provide an Azure resource identity for the server.

7. rsyslog and syslog-ng

The Linux forwarder typically uses a Syslog daemon such as:

• rsyslog
• syslog-ng

These services receive Syslog/CEF messages from devices and make them available to Azure Monitor Agent.

The common architecture is:

Security Device
      |
      | TCP/UDP
      | typically port 514
      v
rsyslog / syslog-ng
      |
      v
Azure Monitor Agent
      |
      v
Microsoft Sentinel

Port 514 is a common Syslog port, although another port can be configured if the source, daemon, network controls, and AMA configuration are aligned.

Important exam distinction

Port 514 is not inherently a requirement of Syslog itself.

It is a commonly used port.

The actual configuration must be consistent across:

• The source device
• Network firewall rules
• Linux Syslog daemon
• AMA configuration

8. What Is a Data Collection Rule?

A Data Collection Rule (DCR) controls what data Azure Monitor Agent collects and where that data is sent.

For Syslog and CEF, the DCR can specify:

• Which machines are monitored
• Which facilities are collected
• Minimum severity levels
• Whether Syslog or CEF streams are collected
• Destination Log Analytics workspace

The DCR is therefore an important control point for both security and cost management.

Instead of collecting every possible event, you can filter the events before they are ingested into the workspace. Microsoft specifically describes DCR filtering as a way to improve performance and make querying and analysis more efficient.

9. Syslog Facilities

Syslog categorizes messages using facilities.

Examples include:

• auth
• authpriv
• cron
• daemon
• kern
• mail
• syslog
• user
• local0
• local1
• local2
• local3
• local4
• local5
• local6
• local7

Applications and devices can use these facilities to identify the type or source of an event.

The DCR allows you to select which facilities should be collected.

For example:

Facilities:
    authpriv
    daemon
    local0
    local3

This can be combined with severity filtering.

10. Syslog Severity Levels

Syslog defines severity levels from least severe to most severe:

Microsoft’s DCR configuration uses these severity levels to determine what events are collected.

Minimum severity behavior

An important exam concept is that selecting a minimum severity level also collects more severe events.

For example, if you configure:

Minimum level = Error

you collect:

• Error
• Critical
• Alert
• Emergency

You do not collect:

• Warning
• Notice
• Informational
• Debug

Microsoft’s documentation explicitly describes this behavior when configuring Syslog collection.

11. Example: Filtering Syslog Events

Suppose an organization wants:

All authentication-related events, but only Warning and higher severity events from general infrastructure services.

A DCR might conceptually be configured as:

authpriv:
    Info and higher
daemon:
    Warning and higher
local0:
    Error and higher

This reduces unnecessary ingestion while retaining important security events.

Best practice

Do not automatically select every facility and every severity level in production.

Collect the telemetry required for:

• Security detection
• Incident investigation
• Compliance
• Operational monitoring
• Threat hunting

Avoid collecting large amounts of low-value data simply because it is available.

12. Configuring the Syslog via AMA Connector

The high-level configuration process is:

Step 1 — Prepare the Log Analytics workspace

Create or identify the Log Analytics workspace associated with Microsoft Sentinel.

Step 2 — Identify the Linux collector

Select the Linux machine that will receive and/or generate the Syslog events.

The machine must support Azure Monitor Agent.

For an on-premises or other-cloud machine, Azure Arc can be used to onboard the server to Azure.

Step 3 — Install the Syslog via AMA connector

In Microsoft Sentinel, configure the Syslog via AMA data connector.

Step 4 — Create or configure the DCR

Configure:

• Target machines
• Syslog facilities
• Minimum severity
• Destination workspace

Step 5 — Configure the Linux Syslog daemon

Configure rsyslog or syslog-ng to receive the messages.

Step 6 — Configure the source device

Configure the firewall, router, appliance, or other source to send Syslog messages to the Linux forwarder’s IP address and configured port.

Step 7 — Verify ingestion

Query the Syslog table.

For example:

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

13. Configuring the CEF via AMA Connector

The CEF process is similar:

CEF Security Appliance
        |
        | CEF/Syslog
        v
Linux Log Forwarder
        |
        | rsyslog/syslog-ng
        v
Azure Monitor Agent
        |
        | DCR
        v
Log Analytics
        |
        v
CommonSecurityLog

The configuration process generally involves:

1. Identify the Linux forwarder.
2. Install/configure the CEF via AMA connector.
3. Create/configure the DCR.
4. Configure the Linux Syslog daemon.
5. Configure the security appliance to send CEF.
6. Verify that the events arrive.
7. Query the CommonSecurityLog table.

Microsoft maintains device-specific configuration guidance for many security appliances, including firewalls and other security products.

14. CEF Message Structure

A CEF message consists of:

CEF:Version|
Device Vendor|
Device Product|
Device Version|
Device Event Class ID|
Name|
Severity|
Extension

For example:

CEF:0|
Contoso|
Firewall|
5.0|
1001|
Blocked Connection|
8|
src=10.10.1.20 dst=10.10.2.30 spt=443

The header provides standardized information about the event.

The extension section provides additional event attributes.

15. CEF Escaping Rules

CEF formatting errors can prevent proper parsing.

Important characters must be escaped when they appear in appropriate CEF fields.

For example:

|

may need to be escaped as:

\|

A backslash can be escaped as:

\\

And an equals sign in extension values can require escaping as:

\=

Microsoft specifically identifies malformed CEF headers and improper character escaping as common ingestion problems.

Exam tip

If a question describes:

• Missing CEF:0
• Incorrect number of header fields
• Unescaped pipe characters
• Malformed extension fields

think CEF formatting/parsing problem, not Sentinel RBAC or DCR permissions.

16. The CommonSecurityLog Table

CEF events are stored in:

CommonSecurityLog

This table provides standardized fields for analyzing events from different security products.

Examples include fields representing:

• Device vendor
• Device product
• Device version
• Event category
• Device action
• Source IP
• Destination IP
• Source port
• Destination port
• Protocol
• Username
• Request URL
• Severity

CEF key/value extensions are mapped into standardized CommonSecurityLog columns when possible. Values that cannot be mapped to standard fields can be retained in additional extension data.

17. Example CEF Query

A basic query is:

CommonSecurityLog
| where TimeGenerated > ago(1h)
| take 100

To investigate events from a particular vendor:

CommonSecurityLog
| where TimeGenerated > ago(24h)
| where DeviceVendor == "Contoso"
| project TimeGenerated,
          DeviceVendor,
          DeviceProduct,
          DeviceAction,
          SourceIP,
          DestinationIP,
          DestinationPort
| order by TimeGenerated desc

A specific firewall product could similarly be investigated using:

CommonSecurityLog
| where TimeGenerated > ago(24h)
| where DeviceProduct == "Firewall"

18. Example Syslog Query

Syslog events are stored in the Syslog table.

For example:

Syslog
| where TimeGenerated > ago(1h)
| take 100

You can filter by facility:

Syslog
| where TimeGenerated > ago(24h)
| where Facility == "authpriv"
| order by TimeGenerated desc

Or search for authentication-related messages:

Syslog
| where TimeGenerated > ago(24h)
| where Facility == "authpriv"
| where SyslogMessage contains "authentication"

19. Syslog and CEF in the Same DCR

A single DCR can be configured to collect both Syslog and CEF.

The streams are different:

Microsoft-Syslog

for Syslog and:

Microsoft-CommonSecurityLog

for CEF.

Microsoft’s current DCR examples demonstrate that both streams can be configured within the same DCR.

Conceptually:

DCR
 |
 +-- Microsoft-Syslog
 |       |
 |       +--> Syslog table
 |
 +-- Microsoft-CommonSecurityLog
         |
         +--> CommonSecurityLog table

20. An Important Duplication Problem

One subtle issue is duplicate ingestion.

Because CEF is transported through Syslog, it is possible to configure the same facility in a way that causes the same message to be collected as both:

• Syslog
• CEF

For example, suppose a firewall sends CEF using the local0 facility.

If the DCR collects:

local0 → Microsoft-Syslog

and also:

local0 → Microsoft-CommonSecurityLog

the same event can potentially be ingested twice.

Microsoft specifically warns that using the same facility for both Syslog and CEF can result in data ingestion duplication.

Best practice

Design your facility assignments and DCR filters deliberately.

For example:

Firewall CEF
    local4
       |
       +--> CommonSecurityLog
Linux authentication
    authpriv
       |
       +--> Syslog

This creates clearer separation between the two ingestion paths.

21. Avoiding Duplicate Data

Duplicate ingestion can:

• Increase costs
• Create duplicate alerts
• Complicate investigations
• Distort event counts
• Increase storage requirements
• Make analytics less reliable

When troubleshooting unexpected duplicate events, investigate:

1. Whether the source sends both Syslog and CEF.
2. Which facility the source uses.
3. Which facilities are configured in the DCR.
4. Whether multiple DCRs are associated with the same machine.
5. Whether multiple collectors are forwarding the same events.
6. Whether another connector is collecting the same source.

22. The Role of the Linux Syslog Daemon

The Linux Syslog daemon is a key part of the architecture.

For example:

Network Device
      |
      | UDP/TCP 514
      v
+-------------------+
| Linux VM          |
|                   |
| rsyslog           |
|       |           |
|       v           |
|      AMA          |
+-------+-----------+
        |
        v
Log Analytics

The daemon receives the messages and forwards them to AMA.

Current AMA versions use a TCP connection on port 28330 between the Syslog daemon and AMA; earlier AMA versions used a Unix domain socket. This is an implementation detail that can appear in advanced troubleshooting questions.

For the SC-500 exam, however, the more important architectural distinction is:

Source device → Syslog daemon → AMA → DCR → Sentinel

23. Securing the Log Forwarder

The log forwarder is a security-sensitive system because it receives potentially sensitive security telemetry.

Recommended controls include:

• Restrict inbound network access.
• Allow only expected source IP addresses.
• Limit the exposed listening ports.
• Keep Linux and AMA updated.
• Use Azure Arc where appropriate for non-Azure servers.
• Apply Defender for Servers where appropriate.
• Monitor the forwarder.
• Restrict administrative access.
• Use least-privilege RBAC.
• Avoid unnecessary services on the collector.
• Protect the machine from unauthorized modification.

A compromised log forwarder could potentially affect the organization’s security visibility.

24. High Availability and Scaling

Large environments may require multiple forwarders.

For example:

             +-------------+
             | Firewall A  |
             +------+------+
                    |
             +------+------+
             |             |
             v             v
       +---------+   +---------+
       |Forwarder|   |Forwarder|
       |    A    |   |    B    |
       +----+----+   +----+----+
            |             |
            +------+------+
                   |
                   v
            Log Analytics

Multiple forwarders can provide:

• Increased capacity
• Fault tolerance
• Geographic separation
• Network segmentation
• Administrative separation

Microsoft also notes that Azure Arc can be used to give on-premises or other-cloud forwarding servers an Azure resource identity, and VM scale sets can be considered for scaling log-forwarder environments.

25. Resource Context and Log Forwarders

An important security consideration arises when multiple teams share a log forwarder.

Events forwarded by a particular CEF/Syslog forwarding VM can be associated with the resource ID of that forwarding VM.

Therefore, if different teams require strict resource-level access separation, using separate forwarding infrastructure may be appropriate.

Microsoft specifically recommends considering separate forwarding VMs when multiple teams need resource-context separation.

This is a more advanced concept but is useful for SC-500 scenario questions.

26. Troubleshooting Syslog and CEF Collection

A systematic troubleshooting process is important.

Step 1 — Verify the source

Confirm:

• The device is generating events.
• The device is configured to send events.
• The destination IP address is correct.
• The destination port is correct.
• The facility is correct.
• The device is using the expected Syslog/CEF format.

Step 2 — Verify network connectivity

Check:

• Network Security Groups
• Azure Firewall
• Network firewalls
• Routing
• Load balancers
• Linux host firewall
• Port configuration

If the Linux collector never receives the message, Sentinel and AMA are not yet the problem.

Step 3 — Verify the Syslog daemon

Check whether:

• rsyslog or syslog-ng is running.
• The daemon is listening on the expected port.
• The configuration permits the source.
• The messages are being received.

A useful diagnostic technique is to inspect network traffic on the collector.

For example:

sudo tcpdump -i any port 514 -A -vv

Microsoft recommends this type of check when verifying whether messages are reaching the forwarder.

Step 4 — Verify Azure Monitor Agent

Check the Azure Monitor Agent extension on the Linux machine.

Confirm:

Provisioning succeeded

Also verify that the installed AMA version is current enough for the environment.

Step 5 — Verify the DCR

Check:

• Correct target machine
• Correct workspace
• Correct stream
• Correct facilities
• Correct severity
• Correct associations

A common problem is having a correctly installed AMA but an incorrectly configured DCR.

Step 6 — Verify CEF Formatting

For CEF, check:

• CEF:0 is present.
• All required header fields exist.
• Fields are separated correctly by |.
• Special characters are escaped.
• Extensions use the appropriate key=value format.

Microsoft identifies malformed CEF headers and escaping issues as common causes of parsing problems.

Step 7 — Verify the Sentinel table

For Syslog:

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

For CEF:

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

Microsoft notes that events can take up to approximately 20 minutes to appear after configuration in some troubleshooting scenarios.

27. Troubleshooting by Symptom

28. Monitoring Collection Health

Successful configuration is not the end of the process.

A security team should continuously monitor whether critical data sources are still sending events.

A useful operational approach is:

Source
  ↓
Network
  ↓
Forwarder
  ↓
AMA
  ↓
DCR
  ↓
Workspace
  ↓
Sentinel
  ↓
Analytics

A failure anywhere in this chain can reduce security visibility.

Microsoft provides Sentinel data connector health capabilities for supported connectors, and Syslog/CEF troubleshooting should consider the entire collection pipeline rather than only the Sentinel workspace.

29. Cost Management

Security logging can generate enormous volumes of data.

Consider a firewall generating:

100,000 events/hour

If the organization collects every informational and debug event, the resulting volume can become substantial.

DCR filtering allows organizations to reduce unnecessary ingestion.

For example:

Debug        → Don't collect
Informational → Don't collect
Notice       → Don't collect
Warning      → Collect
Error        → Collect
Critical     → Collect
Alert        → Collect
Emergency    → Collect

However, do not blindly filter events merely to reduce cost.

Security teams should determine which events are needed for:

• Detection rules
• Incident response
• Threat hunting
• Compliance
• Forensics
• Operational troubleshooting

30. Syslog and CEF Data Collection Best Practices

1. Use AMA

Use the current Azure Monitor Agent-based architecture rather than designing new deployments around the retired legacy agent architecture.

2. Use DCRs deliberately

Use DCRs to control:

• Sources
• Facilities
• Severity
• Destinations

3. Minimize unnecessary ingestion

Avoid collecting large amounts of low-value data.

4. Separate Syslog and CEF facilities when possible

This helps avoid duplicate ingestion.

5. Protect the log forwarder

Treat the collector as a security-critical system.

6. Use Azure Arc for non-Azure collectors when appropriate

This provides Azure resource management capabilities for supported on-premises and other-cloud servers.

7. Validate CEF formatting

Incorrect CEF syntax can prevent proper parsing.

8. Monitor ingestion continuously

A connector that worked yesterday may not be receiving events today.

9. Use KQL to validate data

Do not assume that “connector configured” means “events are arriving.”

10. Design for scale

Large environments may require multiple collectors or scalable forwarding architectures.

31. Common SC-500 Exam Traps

Trap 1: Confusing Syslog and CEF

Remember:

Syslog → Syslog
CEF    → CommonSecurityLog

Trap 2: Assuming CEF is completely separate from Syslog

CEF is commonly transported using Syslog.

Therefore, CEF collection still involves the Syslog infrastructure on the Linux collector.

Trap 3: Thinking AMA directly connects to every firewall

Many appliances cannot run AMA.

Instead:

Firewall
   ↓
Linux forwarder
   ↓
AMA
   ↓
Sentinel

Trap 4: Assuming port 514 is mandatory

514 is a common port, not an absolute requirement.

The source, Syslog daemon, and network configuration must agree on the configured port.

Trap 5: Forgetting the DCR

AMA does not by itself determine the complete collection policy.

The DCR defines what the agent collects and where it sends the data.

Trap 6: Misunderstanding minimum severity

If you select Error, you also collect:

• Error
• Critical
• Alert
• Emergency

You do not collect less severe events.

Trap 7: Ignoring duplicate ingestion

Collecting the same facility as both Syslog and CEF can cause duplication.

Trap 8: Troubleshooting Sentinel first

If the device’s packets never reach the Linux collector, changing Sentinel settings will not solve the problem.

Follow the pipeline:

Source
→ Network
→ Syslog daemon
→ AMA
→ DCR
→ Workspace
→ Sentinel

32. SC-500 Decision Matrix

33. End-to-End Example

Imagine a company has:

• 20 Linux servers
• 5 firewalls
• 10 network switches
• 2 IDS appliances

The firewalls and IDS appliances generate CEF.

The Linux servers generate Syslog.

The company deploys two Linux log forwarders.

Architecture

 Linux Servers
     |
     | Syslog
     v
+-------------+
| Forwarder 1 |
| rsyslog     |
| AMA         |
+------+------+
       |
       |
       v
+----------------------+
| Log Analytics        |
| Workspace             |
|                      |
| Syslog               |
| CommonSecurityLog    |
+----------+-----------+
           |
           v
     Microsoft Sentinel


 Firewalls / IDS
       |
       | CEF
       v
+-------------+
| Forwarder 2 |
| rsyslog     |
| AMA         |
+------+------+
       |
       v
 Log Analytics
       |
       v
 Microsoft Sentinel

The organization configures DCRs to:

• Collect authentication Syslog events.
• Collect important infrastructure events.
• Collect firewall CEF events.
• Collect IDS CEF events.
• Exclude unnecessary debug events.

Security analysts then query:

Syslog
| where TimeGenerated > ago(24h)
| where Facility == "authpriv"

and:

CommonSecurityLog
| where TimeGenerated > ago(24h)
| where DeviceProduct in ("Firewall", "IDS")

This provides centralized security visibility across otherwise heterogeneous systems.

34. Key Takeaways for the SC-500 Exam

Remember these concepts:

1. Syslog is a common logging protocol and format used by Linux systems, network devices, and appliances.
2. CEF is a standardized security event format commonly transported through Syslog.
3. Azure Monitor Agent is the current agent used for Syslog and CEF collection.
4. A Linux machine can function as a log forwarder.
5. rsyslog and syslog-ng are common Linux Syslog daemons.
6. Port 514 is commonly used for Syslog/CEF but isn’t mandatory.
7. Data Collection Rules determine what AMA collects and where it sends it.
8. DCRs can filter by Syslog facility and severity.
9. Selecting a minimum severity collects that level and more severe levels.
10. Syslog data is stored in the Syslog table.
11. CEF data is stored in the CommonSecurityLog table.
12. CEF formatting and escaping must be correct for proper parsing.
13. Using the same facility for Syslog and CEF can result in duplicate ingestion.
14. Azure Arc can be used to onboard non-Azure Linux forwarding servers.
15. Troubleshooting should follow the complete path from source → network → Syslog daemon → AMA → DCR → workspace → Sentinel.
16. Filtering unnecessary data can improve efficiency and control ingestion costs.
17. Log forwarders are security-sensitive infrastructure and should be protected accordingly.

Practice Exam Questions

Question 1

A security team needs to collect CEF events from a firewall that cannot have software agents installed on it. The team wants to use the current Microsoft Sentinel architecture.

What should the team deploy?

A. Azure Monitor Agent directly on the firewall
B. Microsoft Monitoring Agent directly on the firewall
C. A Linux log forwarder running a Syslog daemon and Azure Monitor Agent
D. An Azure Storage account configured as a CEF collector

Answer: C

Explanation

A network firewall typically cannot have AMA installed directly. A Linux machine can act as a log forwarder. The firewall sends CEF messages to the Linux machine, where rsyslog or syslog-ng receives the messages and AMA forwards them to Microsoft Sentinel.

The legacy Microsoft Monitoring Agent should not be the basis of a new deployment.

Question 2

A company configures a DCR for Syslog collection and selects Error as the minimum severity level for a facility.

Which events will be collected?

A. Error, Critical, Alert, and Emergency
B. Debug, Informational, Notice, and Warning
C. Error and Warning only
D. Error events only

Answer: A

Explanation

Syslog severity becomes more severe as the severity value moves toward Emergency.

Selecting Error means the collector receives:

• Error
• Critical
• Alert
• Emergency

It does not collect less severe events such as Warning, Notice, Informational, or Debug.

Question 3

A security analyst wants to query CEF events collected from a Palo Alto firewall.

Which Microsoft Sentinel table should the analyst query?

A. CommonSecurityLog
B. AzureActivity
C. SecurityEvent
D. SyslogEvent

Answer: A

Explanation

CEF events are stored in the CommonSecurityLog table.

For example:

CommonSecurityLog
| where TimeGenerated > ago(24h)

The Syslog table is used for Syslog events that are collected as Syslog.

Question 4

A firewall sends CEF messages using the local0 Syslog facility. An administrator configures the same local0 facility for both the Syslog and CEF streams in the DCR.

What is the primary concern?

A. AMA will stop processing all Syslog events
B. The firewall will automatically change to TCP
C. CEF messages will be converted into Windows events
D. The same events may be ingested more than once

Answer: D

Explanation

Because CEF is commonly transported through Syslog, configuring the same facility for both the Syslog and CEF streams can result in duplicate ingestion.

This can increase ingestion cost and complicate analysis. Microsoft specifically warns about this configuration.

Question 5

A CEF device sends events to a Linux log forwarder, but no events appear in the CommonSecurityLog table. Network monitoring confirms that packets are reaching the Linux server.

What should the administrator investigate next?

A. The CEF formatting, Syslog daemon, AMA, and DCR configuration
B. Azure SQL auditing
C. Microsoft Entra Conditional Access
D. Azure Key Vault certificates

Answer: A

Explanation

Since the packets reach the Linux server, the next part of the pipeline to investigate is:

Network
→ rsyslog/syslog-ng
→ AMA
→ DCR
→ Log Analytics

CEF formatting should also be validated because malformed CEF messages can prevent proper parsing.

Question 6

Which component determines which Syslog facilities and severity levels Azure Monitor Agent should collect?

A. Microsoft Sentinel analytics rules
B. The Data Collection Rule
C. Azure Firewall
D. The CommonSecurityLog table

Answer: B

Explanation

The DCR defines the data collection configuration for AMA. For Syslog/CEF, this includes the facilities, severity levels, streams, and destination configuration.

Analytics rules operate on data after it has been collected; they do not define the basic Syslog collection policy.

Question 7

A company has an on-premises Linux server that will be used as a Microsoft Sentinel Syslog forwarder.

Which Azure capability can be used to represent and manage that server as an Azure resource?

A. Azure Backup
B. Azure Bastion
C. Azure Arc
D. Azure Application Gateway

Answer: C

Explanation

Azure Arc can onboard supported non-Azure servers so they can be represented and managed as Azure resources.

This is particularly useful for on-premises and other-cloud Linux servers used as Sentinel log forwarders.

Question 8

A security appliance sends the following CEF event:

CEF:0|Contoso|Firewall|1.0|100|Blocked Connection|8|src=10.1.1.10 dst=10.2.2.20

What is the purpose of the section after the final | in the CEF header?

A. It specifies the Log Analytics workspace
B. It contains additional event attributes and extensions
C. It specifies the Azure subscription
D. It defines the DCR association

Answer: B

Explanation

The CEF header contains standardized information such as vendor, product, version, event class ID, name, and severity.

The extension portion contains additional event attributes such as:

src=10.1.1.10
dst=10.2.2.20

These values are mapped into CommonSecurityLog fields where appropriate.

Question 9

An administrator wants to determine whether Syslog events are reaching the Sentinel workspace.

Which query is most appropriate?

A.

CommonSecurityLog
| summarize count()

B.

AzureActivity
| summarize count()

C.

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

D.

SecurityEvent
| where TimeGenerated > ago(1h)

Answer: C

Explanation

Syslog events are stored in the Syslog table.

A simple validation query is:

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

The CommonSecurityLog table is used for CEF events.

Question 10

A security team reports that a firewall’s CEF events are arriving at the Linux forwarder but are not being parsed correctly in Sentinel. The raw messages contain malformed CEF headers and unescaped pipe characters.

What is the most likely cause?

A. Incorrect Microsoft Entra role assignment
B. An incorrect Azure Firewall rule
C. An invalid Log Analytics pricing tier
D. Invalid CEF formatting

Answer: D

Explanation

CEF requires a correctly structured header and appropriate escaping of special characters. Missing header fields, an invalid CEF:0 prefix, incorrect pipe delimiters, or improper escaping can prevent proper parsing.

Microsoft specifically identifies malformed CEF headers and character escaping as common CEF ingestion problems.

Final Exam Perspective

For SC-500, think of Syslog and CEF collection as an end-to-end pipeline, rather than simply a Sentinel connector:

                    SECURITY EVENTS
                          |
             +------------+------------+
             |                         |
          Syslog                       CEF
             |                         |
             +------------+------------+
                          |
                          v
                 Linux Log Forwarder
                          |
                  rsyslog / syslog-ng
                          |
                          v
                Azure Monitor Agent
                          |
                          v
              Data Collection Rule
                /               \
               /                 \
        Microsoft-Syslog   Microsoft-CommonSecurityLog
               |                 |
               v                 v
           Syslog          CommonSecurityLog
               \                 /
                \               /
                 +-------------+
                       |
                       v
                Microsoft Sentinel

If you can confidently explain what each component does, where filtering occurs, how facilities and severity work, why a Linux forwarder is used, how CEF differs from Syslog, which table receives each type of event, and how to troubleshoot the pipeline, you will have covered the core concepts that SC-500 is likely to test for this topic.

Go to the SC-500 Exam Prep Hub main page