Microsoft Sentinel Data Connectors, Azure Monitor Agent, Syslog, and CEF – SC-200 Study Guide

Purpose of This Lesson

This lesson explains how Microsoft Sentinel collects data from Microsoft services, Azure resources, Windows and Linux systems, and third-party security appliances. For the SC-200 exam, this matters because Microsoft Sentinel is only useful when it has the right data sources connected. A Security Operations Analyst must understand how logs are ingested, which connector to use, how Azure Monitor Agent fits into collection, and how data collection rules control what gets sent to the Log Analytics workspace.

In a real SOC, connectors are the foundation for detection, investigation, threat hunting, analytics rules, workbooks, automation, and incident response. If the right logs are not connected, Sentinel cannot generate meaningful incidents, run useful analytics, or support reliable investigations.

Microsoft Sentinel is now generally available in the Microsoft Defender portal, but Microsoft documentation still references both the Azure portal and the Defender portal experience depending on the task, workspace state, and feature. Microsoft’s current guidance shows Content hub access from Microsoft Sentinel in the Defender portal under Content management > Content hub, and from the Azure portal under Content management > Content hub.

---

Key Concepts

Microsoft Sentinel Data Connectors

A data connector is the mechanism Microsoft Sentinel uses to bring data into a Log Analytics workspace. Sentinel does not magically see activity from Microsoft 365, Microsoft Entra ID, Azure, endpoints, firewalls, Linux systems, or third-party tools. Each data source must be connected, configured, and sending the right logs.

Microsoft describes Sentinel data connectors as the method for connecting data sources so Sentinel can ingest and analyze data for threat detection. Connectors may come from Microsoft services, Azure services, or third-party security products.

Common connector examples include:

• Microsoft Entra ID
• Microsoft Defender XDR
• Microsoft Defender for Endpoint
• Microsoft Defender for Office 365
• Microsoft Defender for Cloud
• Microsoft 365 activity logs
• Azure Activity
• Windows Event Logs
• Linux Syslog
• Common Event Format, or CEF
• Third-party firewall and network appliance logs
• SaaS and cloud security platforms

The main idea is simple: Sentinel needs connected data before it can detect, correlate, investigate, or respond.

---

Sentinel in the Azure Portal vs Microsoft Defender Portal

Microsoft Sentinel is in a transition period where some experiences may appear in the Azure portal and others in the Microsoft Defender portal. The important SC-200 point is not memorizing one exact screen location forever. The important point is understanding the functional areas:

• Content hub is used to find and install Sentinel solutions, connectors, analytics rules, workbooks, parsers, hunting queries, and related content.
• Data connectors are used to connect specific data sources.
• Log Analytics workspace stores the ingested data.
• Microsoft Defender portal is becoming the unified security operations experience.
• Azure portal still remains relevant for some configuration, workspace, Azure Monitor, and infrastructure-related tasks.

For the exam, expect Microsoft to care more about the feature than the exact portal path. However, if a question asks where to configure Sentinel content or connectors, look for answers involving Microsoft Sentinel, Content hub, Data connectors, and the relevant workspace.

---

Content Hub

The Content hub is where you discover, install, and manage Microsoft Sentinel content. This includes more than just data connectors. A solution in Content hub may include:

• Data connectors
• Analytics rules
• Hunting queries
• Workbooks
• Parsers
• Watchlists
• Playbooks
• Entity mapping templates
• Other packaged SOC content

Microsoft recommends Content hub as the primary place to discover and manage Microsoft Sentinel out-of-the-box content.

For example, installing the Azure Activity solution can enable Sentinel to ingest Azure control-plane activity, such as administrative operations, service health events, alerts, recommendations, policy events, autoscale events, and resource health data.

A key exam point: installing a solution is not always the same as fully configuring ingestion. Some connectors require additional steps, permissions, diagnostic settings, agents, data collection rules, or forwarding configuration.

---

Azure Activity Connector

The Azure Activity connector brings Azure subscription-level activity into Sentinel. This is useful for monitoring administrative and control-plane events, such as:

• Resource creation
• Resource deletion
• Role assignment changes
• Policy events
• Service health events
• Security-related Azure activity
• Resource health changes
• Autoscale events

In a SOC workflow, Azure Activity logs help answer questions like:

• Who created or deleted a resource?
• Was a privileged Azure operation performed?
• Did someone modify networking, identity, or security settings?
• Did a suspicious user make changes after compromise?
• Did a cloud resource generate a service health or security event?

For SC-200, remember that Azure Activity is about Azure platform activity, not endpoint telemetry, mailbox threats, or identity sign-in logs.

---

Microsoft Entra ID Connectors

Microsoft Entra ID connectors are important because identity is central to modern security operations. Sentinel can use Entra-related data to support investigations involving:

• User sign-ins
• Risky users
• Risky sign-ins
• Conditional Access results
• Audit logs
• Application activity
• Privileged identity activity

In a SOC, Entra ID logs help determine whether an alert is isolated to one system or part of a larger identity compromise. For example, if a suspicious endpoint alert involves a user account, the analyst may pivot into Entra sign-in logs to check impossible travel, unfamiliar locations, failed MFA, unusual application access, or administrative changes.

Exam mindset: identity telemetry often provides scope and intent. Endpoint data may show execution, but Entra logs may show how access was obtained.

---

Data Collection from Windows and Linux Systems

Not all data comes from cloud-native Microsoft services. Many environments still require collection from:

• Azure virtual machines
• On-premises Windows servers
• On-premises Linux servers
• Hybrid systems connected through Azure Arc
• Network appliances
• Security appliances
• Firewalls
• Routers
• Legacy systems

This is where the Azure Monitor Agent, or AMA, becomes important.

---

Azure Monitor Agent, or AMA

The Azure Monitor Agent is Microsoft’s current agent used to collect monitoring and log data from supported Windows and Linux systems. AMA sends collected data to destinations such as Log Analytics workspaces, where Microsoft Sentinel can use the data.

Microsoft’s documentation explains that AMA collects data according to Data Collection Rules, or DCRs. DCRs define what data is collected, how it is processed, and where it is sent.

In simple terms:

1. Install or enable AMA on a supported machine.
2. Create a Data Collection Rule.
3. Associate the DCR with the target resource.
4. Select the data sources to collect.
5. Choose the destination, such as the Sentinel-connected Log Analytics workspace.
6. Sentinel can then query, analyze, and correlate the ingested data.

---

Data Collection Rules, or DCRs

A Data Collection Rule controls what AMA collects and where it sends that data. DCRs are important because they prevent log collection from becoming uncontrolled, noisy, expensive, or irrelevant.

Microsoft describes DCRs as Azure resources that provide a centralized and consistent way to define data collection scenarios. They are visible from the Data Collection Rules area of Azure Monitor.

A DCR can define:

• Target resources
• Data source type
• Windows Event Logs
• Linux Syslog facilities and severities
• Performance counters
• Destination workspace
• Transformations in some scenarios
• Collection scope

For Sentinel, DCRs matter because they directly affect:

• What logs are available for analytics rules
• What data appears in hunting queries
• What workbooks can visualize
• How much ingestion cost is generated
• Whether investigations have enough evidence

---

Windows Event Log Collection with AMA

For Windows systems, AMA can collect Windows Event Logs and send them to a Log Analytics workspace. During DCR configuration, you choose the Windows Event Log data source and select the logs and severity levels you want to collect.

Microsoft notes that Windows Event Log collection with AMA is supported when the event log files are stored on a local disk. Microsoft also notes that Windows Analytic and Debug channels cannot be collected or exported to Log Analytics through this method because of Windows OS subscription limitations.

Common Windows logs that may matter in security operations include:

• Security
• System
• Application
• PowerShell-related logs
• Windows Defender-related logs
• Authentication and authorization events
• Service installation events
• Process or script activity, depending on configured logging

For the exam, the key idea is that AMA plus DCR controls Windows log collection. You do not just install Sentinel on a server. You configure the agent, the collection rule, the data source, and the destination workspace.

---

Azure Arc and Hybrid Servers

In hybrid environments, Azure Arc can help manage servers outside Azure. This matters because many organizations need Sentinel visibility across both cloud and on-premises systems.

A typical hybrid collection pattern is:

• Onboard on-premises servers to Azure Arc.
• Deploy Azure Monitor Agent.
• Associate the servers with a DCR.
• Send selected logs to the Sentinel workspace.

This is especially relevant for organizations with traditional server infrastructure, branch offices, legacy applications, or mixed Windows/Linux environments.

SC-200 angle: when a scenario mentions on-premises servers and Sentinel log collection, look for Azure Arc, Azure Monitor Agent, and Data Collection Rules.

---

Syslog

Syslog is a long-standing logging protocol and message format commonly used by Unix, Linux, network devices, firewalls, routers, VPN appliances, and security appliances.

Syslog is common in SOC environments because many infrastructure and security devices generate logs in this format. Microsoft Sentinel can ingest Syslog messages through AMA-based connectors.

Microsoft states that the Syslog via AMA connector helps ingest Syslog messages into a Log Analytics workspace using Azure Monitor Agent.

Syslog is commonly associated with:

• Linux servers
• Firewalls
• Routers
• Switches
• VPN appliances
• IDS/IPS systems
• Network security platforms
• Some third-party applications

In a Sentinel investigation, Syslog can help answer questions like:

• Did a firewall block or allow a suspicious connection?
• Did a VPN appliance show unusual authentication attempts?
• Did a Linux host log privilege escalation?
• Did a network device show configuration changes?
• Did a security appliance detect scanning or exploitation?

---

Common Event Format, or CEF

Common Event Format, or CEF, is a vendor-neutral log format used by many security products. CEF is especially common for security appliances that need to send normalized events to SIEM platforms.

Microsoft Sentinel supports CEF collection through the Common Event Format via AMA connector. Microsoft’s documentation explains that Syslog via AMA and CEF via AMA connectors filter and ingest Syslog messages, including CEF messages, from Linux machines and from network and security devices and appliances. These connectors install AMA on the Linux machine used for collection.

CEF is commonly used with:

• Firewalls
• Web application firewalls
• IDS/IPS platforms
• Endpoint security products
• Proxy appliances
• Email gateways
• Network detection tools
• Security appliances that forward normalized events

Exam point: CEF is not a Microsoft-only format. It is a common format used to bring third-party security events into Sentinel.

---

Syslog and CEF Forwarder Pattern

A common Sentinel design is to use a Linux log forwarder. This is especially useful when the original device cannot run AMA directly.

The pattern looks like this:

1. Network or security devices generate Syslog or CEF events.
2. Devices forward logs to a Linux VM or server.
3. The Linux system runs Syslog services and Azure Monitor Agent.
4. AMA collects selected Syslog or CEF messages based on DCR configuration.
5. AMA sends the data over HTTPS/TCP 443 to Azure Monitor and the Sentinel-connected Log Analytics workspace.
6. Sentinel uses the ingested data for analytics, hunting, dashboards, and investigation.

Microsoft’s tutorial for forwarding Syslog data explains this pattern for Linux-based devices where you cannot install an agent directly, such as firewalls and network devices.

This design is common in real SOCs because appliances often cannot run Microsoft agents. Instead, they forward logs to a collector.

---

Port and Traffic Considerations

The transcript mentions two important traffic patterns:

• Devices may send Syslog traffic to a collector, commonly using UDP 514.
• The Azure Monitor Agent sends data to Microsoft cloud services over TCP 443.

From an operations perspective, this means analysts and engineers must coordinate with firewall, networking, and infrastructure teams. If logs are not arriving, possible causes include:

• Device not configured to forward logs
• Wrong destination IP or hostname
• UDP 514 blocked between device and forwarder
• Syslog daemon not listening
• AMA not installed or unhealthy
• DCR not associated with the resource
• Wrong facility or severity selected
• Log Analytics workspace destination misconfigured
• Outbound TCP 443 blocked
• Connector installed but not fully configured

For SC-200, remember that connector installation alone does not prove data is flowing. You must validate ingestion.

---

Data Connectors vs Data Collection Rules

These two concepts work together but are not the same.

Concept	Purpose	Example
Data connector	Enables Sentinel to connect to a type of data source	Azure Activity connector, Syslog via AMA, CEF via AMA
Data Collection Rule	Defines what AMA collects and where it sends it	Collect Windows Event Logs from selected VMs and send to Sentinel workspace
Log Analytics workspace	Stores the ingested data Sentinel uses	Workspace connected to Microsoft Sentinel
Content hub	Place to find and install Sentinel solutions and connector packages	Install Azure Activity, Syslog, or CEF solution
AMA	Agent that collects logs from Windows/Linux systems	Collect Windows Event Logs or Syslog from a machine

Exam shortcut: connector = source integration; DCR = collection configuration; workspace = storage and query location.

---

Microsoft Security Operations Context

How Data Connectors Fit into SOC Workflow

Data connectors are not just setup tasks. They directly determine what analysts can see and investigate.

A SOC analyst uses connected data to:

• Triage alerts
• Investigate incidents
• Pivot between entities
• Review user, device, IP, file, mailbox, or cloud resource activity
• Confirm whether a detection is true positive or false positive
• Determine scope and impact
• Identify affected assets
• Support containment decisions
• Escalate to infrastructure, identity, cloud, or endpoint teams
• Document evidence
• Improve future detections

Without the right connectors, Sentinel may show only part of the story.

For example:

• If Azure Activity is not connected, cloud administrative changes may be invisible.
• If Entra ID sign-in logs are missing, identity investigations are weak.
• If Syslog is not ingested, firewall and appliance context may be missing.
• If CEF is not connected, third-party security tool alerts may not appear.
• If Windows Event Logs are not collected, server-side evidence may be incomplete.

---

Triage Example: Suspicious Azure Resource Change

Scenario: Sentinel generates an incident involving suspicious activity against an Azure resource.

An analyst may use:

1. Azure Activity logs to identify who made the change.
2. Microsoft Entra ID logs to review sign-in activity for the account.
3. Defender for Cloud alerts to check cloud workload risk.
4. Sentinel incident evidence to review related entities.
5. KQL hunting queries to search for similar activity across subscriptions.
6. Automation rules or playbooks to assign, tag, notify, or enrich the incident.

The connector decision matters because Azure Activity provides cloud control-plane visibility, while Entra ID provides identity context.

---

Triage Example: Firewall Logs Through CEF

Scenario: A firewall detects outbound traffic from an internal server to a suspicious IP.

A Sentinel investigation may involve:

1. Reviewing CEF logs from the firewall.
2. Pivoting on source IP, destination IP, action, port, and device vendor.
3. Checking whether traffic was allowed or blocked.
4. Correlating with endpoint data from Defender for Endpoint.
5. Checking identity activity for the user or service account.
6. Determining whether the event is isolated or part of a larger compromise.

The CEF connector is critical because the firewall may be a non-Microsoft device. Sentinel needs that third-party telemetry to correlate the network event with Microsoft security data.

---

Triage Example: Linux Syslog Collection

Scenario: A Linux server shows repeated failed authentication attempts.

An analyst may use:

1. Syslog data ingested by AMA.
2. KQL to filter failed authentication events.
3. Entity mapping to identify the host and source IP.
4. Watchlists to compare against known admin IP ranges.
5. Analytics rules to detect repeated failures or brute-force patterns.
6. Incident investigation to determine whether successful login followed the failures.

Syslog becomes the source of truth for Linux operating system-level activity.

---

Operational Decision Points

A SOC or security engineering team must decide:

• Which connectors are required?
• Which logs provide security value?
• Which logs are too noisy?
• Which data sources justify ingestion cost?
• Which systems require agents?
• Which appliances need a forwarder?
• Which workspace receives the logs?
• Which teams own configuration and troubleshooting?
• Which detections depend on the data?
• Which retention settings are required?

For SC-200, these are often scenario-based decisions. Microsoft may describe a requirement and expect you to choose the Sentinel feature that solves it.

---

Exam-Relevant Takeaways

What to Remember for SC-200

• Microsoft Sentinel depends on data connectors to ingest data.
• Content hub is used to discover and install Sentinel solutions and connector content.
• Data connectors may require additional configuration after installation.
• Microsoft services such as Microsoft Entra ID and Microsoft 365 may have built-in or easily enabled connectors.
• Azure Activity connector is used for Azure subscription and control-plane activity.
• Azure Monitor Agent is used to collect data from Windows and Linux machines.
• Data Collection Rules define what AMA collects and where the data goes.
• Windows Event Logs can be collected through AMA and DCRs.
• Syslog is common for Linux and infrastructure devices.
• CEF is a vendor-neutral security event format often used by appliances.
• Syslog and CEF via AMA commonly use a Linux forwarder pattern.
• The Sentinel-connected Log Analytics workspace is where ingested logs are stored and queried.
• If logs are missing, check connector configuration, agent health, DCR association, data source selection, and network connectivity.
• Microsoft Defender portal and Azure portal experiences may both appear in real environments and exam scenarios.
• The concept matters more than memorizing one exact portal layout.

---

Tool / Feature Decision Guide

Scenario	Best Microsoft Security Tool or Feature	Why
You need to ingest Azure subscription activity such as resource changes, service health, policy events, and administrative operations	Azure Activity connector	Provides Azure control-plane visibility in Sentinel
You need to collect Windows Event Logs from Azure VMs	Azure Monitor Agent with Data Collection Rule	AMA collects the logs; DCR defines what to collect and where to send it
You need to collect logs from on-premises Windows servers	Azure Arc + AMA + DCR	Azure Arc helps manage hybrid servers, while AMA and DCR handle collection
You need to ingest Linux authentication and system logs	Syslog via AMA	Syslog is the common Linux logging format
You need to ingest logs from firewalls, routers, or security appliances	Syslog via AMA or CEF via AMA	Many appliances forward Syslog or CEF to a Linux collector
You need normalized security events from a third-party appliance	CEF via AMA	CEF is vendor-neutral and commonly used for SIEM integrations
You need to discover packaged Sentinel content	Content hub	Content hub contains connectors, analytics rules, workbooks, hunting queries, and other content
You installed a connector but no logs are showing up	Connector page, DCR, AMA health, workspace, and network troubleshooting	Installation does not guarantee ingestion
You need dashboards for connector data	Sentinel workbooks	Workbooks visualize ingested data
You need to search raw ingested data manually	Logs / KQL	KQL lets analysts query tables directly
You need to detect future matching activity	Analytics rule	Hunting finds activity manually; analytics rules generate alerts/incidents
You need to automate assignment, tagging, or response after an incident is created	Automation rule or playbook	Automation rules handle Sentinel incident workflow; playbooks run Logic Apps actions
You need Microsoft 365 Defender incidents and alerts in Sentinel	Microsoft Defender XDR connector/integration	Brings Defender incidents and alerts into Sentinel for broader correlation
You need endpoint process, file, and device telemetry	Microsoft Defender for Endpoint	Endpoint-specific detection and response
You need identity sign-in and audit visibility	Microsoft Entra ID connectors	Identity logs help investigate account compromise and risky activity

---

KQL Notes

The transcript does not demonstrate a full KQL query, but connectors are directly tied to KQL because each connector sends data into tables that analysts query.

The important exam idea is:

No connector = no data. No data = no useful KQL, analytics, workbook, or hunting result.

Example: Query Azure Activity

This example shows how an analyst might review recent Azure administrative activity.

AzureActivity
| where TimeGenerated > ago(24h)
| project TimeGenerated, Caller, OperationNameValue, ActivityStatusValue, ResourceGroup, _ResourceId
| order by TimeGenerated desc

What this query does

• AzureActivity queries Azure control-plane activity.
• where TimeGenerated > ago(24h) limits results to the last 24 hours.
• project selects the most useful columns for review.
• order by TimeGenerated desc shows the newest events first.

SOC use case

Use this when investigating suspicious Azure resource changes, privilege changes, resource deletion, or administrative actions.

---

Example: Query Syslog Errors

Syslog
| where TimeGenerated > ago(24h)
| where SeverityLevel in ("err", "crit", "alert", "emerg")
| summarize EventCount = count() by Computer, Facility, SeverityLevel
| order by EventCount desc

What this query does

• Syslog queries Syslog data.
• where filters to recent events and high-severity messages.
• summarize count() groups events by host, facility, and severity.
• order by prioritizes systems with the most severe activity.

SOC use case

Use this to identify Linux systems or appliances generating high-severity log events.

---

Example: Query CEF Security Device Activity

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

What this query does

• CommonSecurityLog is commonly used for CEF-style security events.
• project selects fields useful for firewall or appliance investigations.
• The query helps analysts review source/destination traffic and device actions.

SOC use case

Use this to investigate firewall, IDS/IPS, proxy, or security appliance events sent to Sentinel through CEF.

---

KQL Exam Takeaways

• Know that KQL queries are run against tables populated by connectors.
• Use where to reduce noise.
• Use project to show relevant fields.
• Use summarize to aggregate patterns.
• Use order by to prioritize results.
• Choose the table based on the connector and data source.
• KQL is useful for investigation and hunting, while analytics rules use KQL logic to generate alerts.

---

Common Exam Traps

Trap 1: Thinking Installing a Connector Always Completes Ingestion

Installing a connector or solution from Content hub may only be the first step. Some connectors require configuration, permissions, diagnostic settings, agents, DCRs, or forwarding rules.

Correct mindset: Install, configure, validate ingestion.

---

Trap 2: Confusing Content Hub with Data Connectors

Content hub is the catalog for Sentinel content. Data connectors are specific integrations that ingest data.

Correct mindset:

• Content hub = find and install content.
• Data connector = connect a data source.
• DCR = define what AMA collects.
• Workspace = store and query data.

---

Trap 3: Confusing Azure Monitor Agent with Microsoft Defender for Endpoint

AMA collects monitoring and log data based on DCRs. Defender for Endpoint provides endpoint detection and response telemetry, alerts, and response actions.

Correct mindset:

• Use AMA for log collection into Azure Monitor / Log Analytics / Sentinel.
• Use Defender for Endpoint for endpoint security detection, investigation, and response.

---

Trap 4: Forgetting Sentinel Depends on the Workspace

Sentinel is built on a Log Analytics workspace. If the destination workspace is wrong, the data may not appear where the analyst expects.

Correct mindset: Always confirm the destination workspace.

---

Trap 5: Choosing the Wrong Connector for the Workload

Examples:

• Azure administrative events → Azure Activity
• Identity sign-ins and audit logs → Microsoft Entra ID
• Linux logs → Syslog via AMA
• Third-party appliance security logs → CEF via AMA
• Windows server event logs → AMA with Windows Event Log DCR
• Endpoint detection and response → Defender for Endpoint

---

Trap 6: Ignoring Cost and Noise

Collecting every possible log may sound safe, but in Sentinel it can create high ingestion cost and alert noise.

Correct mindset: Collect what supports detection, investigation, compliance, and operational requirements.

---

Trap 7: Confusing Hunting Queries with Analytics Rules

A hunting query is usually analyst-driven and manual. An analytics rule uses query logic to generate alerts or incidents automatically.

Correct mindset:

• Hunting query = search manually or proactively.
• Analytics rule = detect and alert continuously.

---

Trap 8: Forgetting Network Path Requirements

Syslog and CEF forwarding require network connectivity between devices, forwarders, and Microsoft cloud endpoints.

Correct mindset: If data is missing, check forwarding configuration, ports, firewall rules, agent health, and DCR association.

---

Real-World SOC Analyst Notes

Alert Fatigue and Log Selection

More logs do not automatically mean better security. Poorly planned ingestion can create:

• Excessive noise
• Higher Sentinel costs
• Slow investigations
• False positives
• Duplicated events
• Low-value alerts

A mature SOC chooses data sources based on detection value. For example, collecting firewall denies from every subnet may be noisy, but collecting high-confidence threat detections, VPN authentication events, administrative changes, and allowed outbound traffic from critical servers may be highly valuable.

---

Evidence Preservation

Connectors affect evidence quality. If a breach investigation starts after the fact and the logs were never ingested, the SOC may not be able to reconstruct the incident.

Important evidence sources include:

• Identity sign-ins
• Endpoint events
• Azure Activity
• Firewall logs
• VPN logs
• Server event logs
• Security appliance alerts
• Email security events
• Cloud workload alerts

For real incidents, analysts should document which data sources were available and which were missing.

---

Escalation Paths

Connector issues often require escalation outside the SOC.

Examples:

• Network team: firewall forwarding, UDP 514, routing, appliance configuration
• Server team: AMA installation, Windows/Linux logging, Azure Arc onboarding
• Cloud team: Azure diagnostic settings, workspace configuration
• Identity team: Entra ID log access and risky user investigation
• Security engineering: DCR design, analytics rules, parser issues
• Compliance team: retention requirements

A SOC analyst does not always fix ingestion problems directly, but they should recognize when missing telemetry affects investigation quality.

---

Automation Safety

Once data is ingested, Sentinel can use analytics rules and automation to respond. Be careful with automation that triggers from noisy or untrusted sources.

Safe automation examples:

• Assign incident owner
• Add severity-based tags
• Notify Teams or email channel
• Enrich IP addresses
• Create tickets
• Add comments to incidents

Higher-risk automation examples:

• Disable user accounts
• Isolate devices
• Block IP addresses globally
• Delete emails
• Modify firewall rules
• Trigger tenant-wide containment

Real-world best practice: start with enrichment and notification before moving into disruptive response actions.

---

Change Control and Governance

Connector changes should be treated as operational changes. Adding or modifying ingestion can affect:

• Cost
• Detection coverage
• Compliance evidence
• Incident volume
• Retention
• Dashboards
• Analytics rules
• SOC workflows

In production, connector changes should be documented. If a new firewall connector is added, the SOC should know:

• What device is forwarding logs
• What format is used
• What workspace receives the logs
• What tables are populated
• What analytics rules depend on the data
• Who owns troubleshooting
• What “normal” volume looks like

---

Cost Considerations

Microsoft Sentinel cost is strongly tied to ingestion and retention. A DCR that collects too much data can increase cost quickly.

Cost-aware questions to ask:

• Do we need all event levels or only security-relevant severities?
• Do we need all servers or only critical servers?
• Do we need verbose firewall logs or filtered security events?
• Are we collecting duplicate data from multiple sources?
• Are there transformation or filtering options available?
• What retention period is required?
• Which logs support actual detections?

SC-200 questions may not ask for pricing calculations, but they often test whether you understand that data collection should be intentional.

---

Quick Reference Summary

• Microsoft Sentinel uses data connectors to ingest logs and alerts.
• Content hub is used to find and install Sentinel solutions and connector content.
• Some Microsoft 365 and Entra connectors may already be available or easy to enable.
• Azure Activity connector brings Azure control-plane activity into Sentinel.
• AMA collects logs from Windows and Linux systems.
• DCRs define what AMA collects and where the data is sent.
• Windows Event Logs can be collected with AMA and DCRs.
• Syslog is common for Linux and network/security devices.
• CEF is a vendor-neutral security event format used by many appliances.
• Syslog and CEF often use a Linux forwarder.
• Sentinel stores ingested data in a Log Analytics workspace.
• KQL queries depend on the tables populated by connectors.
• Connector installation does not always mean data is flowing.
• Validate ingestion after configuration.
• Plan log collection carefully to manage noise and cost.

---

Flashcards

Q: What is a Microsoft Sentinel data connector?
A: A data connector is the integration that allows Sentinel to ingest data from Microsoft services, Azure resources, endpoints, servers, or third-party tools.

Q: What is Content hub used for in Microsoft Sentinel?
A: Content hub is used to discover, install, and manage Sentinel solutions such as data connectors, analytics rules, workbooks, hunting queries, and playbooks.

Q: What is the Azure Activity connector used for?
A: It ingests Azure control-plane activity such as resource changes, administrative operations, service health events, policy events, and resource health information.

Q: What does Azure Monitor Agent do?
A: AMA collects log and monitoring data from supported Windows and Linux systems and sends it to destinations such as a Log Analytics workspace.

Q: What does a Data Collection Rule define?
A: A DCR defines what data AMA collects, how it is processed, and where it is sent.

Q: What is the relationship between AMA and DCRs?
A: AMA is the agent that performs collection; DCRs tell the agent what to collect and where to deliver it.

Q: What is Syslog commonly used for?
A: Syslog is commonly used for Linux systems, network devices, firewalls, routers, VPN appliances, and other infrastructure logs.

Q: What is CEF?
A: Common Event Format is a vendor-neutral security event format often used by third-party security appliances to send normalized events to SIEM platforms.

Q: Why might you use a Linux log forwarder for Sentinel?
A: A Linux forwarder can receive Syslog or CEF logs from devices that cannot run AMA directly, then forward them to Sentinel through Azure Monitor Agent.

Q: What is the destination for Sentinel-ingested logs?
A: A Log Analytics workspace connected to Microsoft Sentinel.

Q: Why is connector validation important?
A: Installing a connector does not guarantee logs are flowing. Analysts must confirm that data is actually arriving in the expected tables.

Q: When should you use Defender for Endpoint instead of AMA?
A: Use Defender for Endpoint for endpoint detection, investigation, and response. Use AMA for log collection into Azure Monitor and Sentinel.

Q: What is a common cost risk with Sentinel connectors?
A: Collecting too many unnecessary logs can increase ingestion cost and create alert noise.

Q: What is the difference between a hunting query and an analytics rule?
A: A hunting query is typically used manually or proactively by analysts; an analytics rule runs detection logic automatically and can generate alerts or incidents.

Q: What should you check if Syslog data is not appearing in Sentinel?
A: Check device forwarding settings, network connectivity, Syslog listener, AMA health, DCR association, selected facilities/severities, and workspace destination.

---

Practice Questions

Question 1:

You are configuring Microsoft Sentinel to collect Windows Event Logs from an Azure virtual machine. You need to define which logs are collected and send them to the Sentinel workspace. What should you configure?

A. Microsoft Defender for Office 365 policy
B. Azure Monitor Agent with a Data Collection Rule
C. Microsoft Entra Conditional Access policy
D. Microsoft Defender for Cloud Apps connector

Correct Answer:
B. Azure Monitor Agent with a Data Collection Rule

Explanation:
AMA collects log data from supported Windows and Linux systems. A Data Collection Rule defines what data is collected and where it is sent, such as a Sentinel-connected Log Analytics workspace.

---

Question 2:

A firewall cannot run the Azure Monitor Agent directly but can forward logs in CEF format. You need to ingest those events into Microsoft Sentinel. What design should you use?

A. Configure a Linux log forwarder with CEF via AMA
B. Install Defender for Endpoint on the firewall
C. Use Microsoft Entra ID sign-in logs
D. Create a Sentinel workbook only

Correct Answer:
A. Configure a Linux log forwarder with CEF via AMA

Explanation:
Many network and security appliances cannot run AMA directly. They can forward CEF or Syslog events to a Linux collector running AMA, which sends the data to Sentinel.

---

Question 3:

You installed a Microsoft Sentinel connector from Content hub, but no logs are visible in the workspace. What is the best next step?

A. Assume Sentinel is broken and recreate the workspace
B. Confirm connector configuration, agent/DCR settings, workspace destination, and data flow
C. Create a workbook because workbooks ingest logs automatically
D. Disable Microsoft Defender XDR integration

Correct Answer:
B. Confirm connector configuration, agent/DCR settings, workspace destination, and data flow

Explanation:
Installing a connector does not always complete ingestion. Some connectors require additional configuration, diagnostic settings, agents, DCRs, forwarding rules, or permissions.

---

Question 4:

You need visibility into Azure resource creation, deletion, policy events, and administrative operations. Which Sentinel connector is most appropriate?

A. Azure Activity
B. Syslog via AMA
C. Common Event Format via AMA
D. Defender for Office 365

Correct Answer:
A. Azure Activity

Explanation:
The Azure Activity connector provides Azure control-plane activity, including administrative operations and resource-level changes.

---

Question 5:

A security analyst wants to proactively search recently ingested Syslog data for high-severity Linux events. Which tool or method should the analyst use?

A. KQL query in Sentinel Logs
B. Microsoft Teams external access settings
C. Microsoft Purview retention label
D. Microsoft Entra password reset policy

Correct Answer:
A. KQL query in Sentinel Logs

Explanation:
KQL is used to query ingested Sentinel data. Syslog data can be searched using KQL to investigate or hunt for suspicious Linux or appliance activity.