Study guide
Technical reference and lesson notes
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:
- Install or enable AMA on a supported machine.
- Create a Data Collection Rule.
- Associate the DCR with the target resource.
- Select the data sources to collect.
- Choose the destination, such as the Sentinel-connected Log Analytics workspace.
- 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:
- Network or security devices generate Syslog or CEF events.
- Devices forward logs to a Linux VM or server.
- The Linux system runs Syslog services and Azure Monitor Agent.
- AMA collects selected Syslog or CEF messages based on DCR configuration.
- AMA sends the data over HTTPS/TCP 443 to Azure Monitor and the Sentinel-connected Log Analytics workspace.
- 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:
- Azure Activity logs to identify who made the change.
- Microsoft Entra ID logs to review sign-in activity for the account.
- Defender for Cloud alerts to check cloud workload risk.
- Sentinel incident evidence to review related entities.
- KQL hunting queries to search for similar activity across subscriptions.
- 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:
- Reviewing CEF logs from the firewall.
- Pivoting on source IP, destination IP, action, port, and device vendor.
- Checking whether traffic was allowed or blocked.
- Correlating with endpoint data from Defender for Endpoint.
- Checking identity activity for the user or service account.
- 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:
- Syslog data ingested by AMA.
- KQL to filter failed authentication events.
- Entity mapping to identify the host and source IP.
- Watchlists to compare against known admin IP ranges.
- Analytics rules to detect repeated failures or brute-force patterns.
- 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
AzureActivityqueries Azure control-plane activity.where TimeGenerated > ago(24h)limits results to the last 24 hours.projectselects the most useful columns for review.order by TimeGenerated descshows 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
Syslogqueries Syslog data.wherefilters to recent events and high-severity messages.summarize count()groups events by host, facility, and severity.order byprioritizes 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
CommonSecurityLogis commonly used for CEF-style security events.projectselects 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
whereto reduce noise. - Use
projectto show relevant fields. - Use
summarizeto aggregate patterns. - Use
order byto 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.