Manage and monitor security posture
Microsoft Sentinel Data and Automation
CoreDesign Microsoft Sentinel workspaces, permissions, content, connectors, custom tables, retention, and automation as an auditable ingestion-to-response pipeline.
Aligned to the live SC-500 guide, which publishes no skills-measured date; guide and product behavior verified September 23, 2026.
Why this matters
A SIEM is useful only when the correct data reaches the correct workspace, analysts have appropriate permissions, schemas are understood, retention matches investigations, and automation runs with authorized identities.
Must Know
- Workspace design considers tenant, region, subscription, residency, access boundaries, existing Log Analytics architecture, and cross-workspace investigation needs.
- Microsoft Sentinel Reader views data, Responder manages incidents, and Contributor has broader Sentinel configuration capability; Azure scope controls where access applies.
- Content hub solutions package connectors, analytics, workbooks, parsers, hunting queries, and related content; install only what fits the data source and operational need.
- Microsoft service connectors differ in prerequisite roles, diagnostic settings, tenant configuration, destination tables, and supported data types.
- Syslog and CEF via Azure Monitor Agent use data collection rules and a supported collector or direct path; parsing and facility or severity filters determine usable records.
- Windows Security Events via AMA uses DCR scope and event selection. WEF centralizes source subscriptions, but the collector still needs the Sentinel ingestion path.
- Custom log tables need a schema and collection transformation aligned with the incoming stream; table plan and retention should match query patterns.
- Automation rules perform ordered incident actions and can invoke authorized Logic Apps playbooks; connector identities and Sentinel authorization must both work.
- Interactive and long-term Sentinel data stores serve different query and retention patterns; moving data is not an incident-severity setting.
- Purview Audit queried through Defender XDR supplies Microsoft 365 activity evidence; it does not replace enabling the source or understanding its retention and permissions.
Compare and Distinguish
- A connector establishes ingestion; an analytics rule detects; a workbook visualizes; an automation rule orchestrates; a playbook executes a workflow.
- Syslog is a general message format; CEF is a structured security-event format carried through syslog transport.
- Workspace retention preserves Sentinel data; source-system retention and Purview Audit availability remain separate.
Scenario examples
- Scenario: Analysts may assign incidents but must not edit connectors. Think: grant a responder-oriented Sentinel role at the workspace scope.
- Scenario: Domain controllers forward selected events to a collector. Think: configure WEF subscriptions, AMA, a DCR, and the Windows Security Events ingestion path.
- Scenario: A high-severity incident must create a ticket and tag the incident. Think: let an automation rule update the incident and invoke an authorized playbook for the external system.
Exam traps
- Installing a content hub solution does not satisfy connector prerequisites or prove data is flowing.
- A DCR association to the wrong machines can be syntactically valid and still collect no intended events.
- A playbook that runs manually for its owner can fail under automation because the trigger authorization or connector identity differs.
- Increasing retention cannot recover events that were never collected.
Key takeaways
- Trace data from source prerequisites through connector, DCR, transformation, table, and retention.
- Grant analysts and automation identities only the roles required at the correct scope.
- Separate incident orchestration from executable external workflow.
How it works
- Connectors and DCRs send supported records to workspace tables where Sentinel content queries and correlates them.
- Incidents trigger ordered automation; a playbook runs under its configured trigger and connector authorization.
Objects and administrative surfaces
- Log Analytics workspace and Sentinel enablement, Azure role assignments, content hub, data connectors, and health evidence.
- Data collection endpoints and rules, AMA, WEF collectors, Syslog or CEF collectors, transformations, tables, and retention.
- Incidents, automation rules, Logic Apps playbooks, managed identities, connector authorizations, and Defender XDR advanced hunting.
When to use it
- Use content hub to deploy supported solution content, then validate prerequisites and incoming records.
- Use custom tables for supported custom streams whose schema and retention are intentionally governed.
Security and governance implications
- Protect workspace role assignments, connector credentials, DCR changes, table transformations, retention, and playbook identities.
- Monitor connector health, ingestion volume, automation failures, and unexpected schema changes.
Troubleshooting signals
- For missing events, check source emission, collector, agent, DCR association and filter, transformation, destination table, and time range.
- For failed response, inspect automation conditions, rule order, Sentinel authorization, Logic App trigger, connector identity, and target API permission.
More detail
- Create and connect workspaces with appropriate role boundaries.
- Install content and configure Microsoft, Syslog, CEF, and Windows event ingestion.
- Create custom tables, transformations, and retention for the data pattern.
- Build automation rules and authorized playbooks and query Purview Audit evidence.
Ready for the quiz?
- Which Sentinel role allows incident management without broad configuration?
- What additional path is required after Windows events reach a WEF collector?
- Why can a manually successful playbook fail from an automation rule?
Related objectives
- D4.2.S1 — Create and connect workspaces in Microsoft Sentinel
- D4.2.S2 — Assign roles in Microsoft Sentinel
- D4.2.S3 — Implement and use content hub solutions
- D4.2.S4 — Configure and use Microsoft data connectors for Azure resources
- D4.2.S5 — Implement and configure syslog and Common Event Format (CEF) event collections
- D4.2.S6 — Implement and configure collection of Windows Security events by using data collection rules, including Windows Event Forwarding (WEF)
- D4.2.S7 — Create custom log tables in the workspace to store ingested data
- D4.2.S8 — Implement automation rules and playbooks in Microsoft Sentinel
- D4.2.S9 — Implement data retention in Microsoft Sentinel data stores
- D4.2.S10 — Query Microsoft Purview Audit in Defender XDR