Microsoft Sentinel Fundamentals: AZ-500 SIEM Guide

What Is Microsoft Sentinel?

Microsoft Sentinel is a cloud-native Security Information and Event Management (SIEM) and Security Orchestration, Automation, and Response (SOAR) solution built on Azure. It collects data at cloud scale, detects threats using built-in and custom analytics rules, and automates response via playbooks.

Workspace Architecture

Sentinel is built on a Log Analytics workspace. All data flows into the workspace; KQL queries run against it. Key design considerations:

• One workspace per environment is the most common pattern
• Multiple workspaces are used for data sovereignty (keep EU data in EU)
• You can query across workspaces with the workspace() KQL function

Data Connectors

Data connectors ingest logs from sources into the workspace. Types:

• Native connectors: Microsoft 365 Defender, Entra ID, Azure Activity: one-click
• CEF/Syslog connectors: For Linux and network devices: requires a log forwarder VM
• API connectors: Third-party services sending logs via REST API

Exam tip: Connector enabled does not mean data is flowing. After enabling a connector, verify ingestion via the connector health dashboard.

Analytics Rules

Analytics rules run KQL queries on a schedule and create incidents when results exceed a threshold.

Rule types:

• Scheduled: KQL runs every N minutes/hours on a lookback window
• NRT (Near-Real-Time): Runs every minute with 5-minute latency: for high-priority detections
• Anomaly: ML-based baselines; generates incidents on statistical deviations
• Fusion: Correlates low-fidelity signals into high-confidence incidents

Incidents and Alerts

An Alert is a single rule firing. An Incident groups related alerts together. The exam tests: alerts alone do not create tickets. Incidents do. SOAR playbooks (Logic Apps) attach to incidents via automation rules.