Microsoft AZ-801: Microsoft Sentinel and Security Monitoring — Study Guide

By Laurynas Brazys · 7 August 2026 · #microsoft #az-801 #certification #exam-prep #study-guide

Part of the Microsoft Windows Server Hybrid Administrator Associate AZ-801 — Study Guide. Practice with verified answers in the Microsoft exam hub, or take timed practice tests on ExamRoll.io.

Overview

Microsoft Sentinel is a cloud-native SIEM and SOAR that unifies log ingestion, analytics, threat detection, incident response, and proactive hunting across hybrid Windows Server estates. For AZ-801 scenarios, mastery involves connecting Windows Security Events, Linux Syslog and third-party CEF sources at scale, engineering analytics with minimal latency, mapping alerts to entities for accurate investigation, and automating containment through Logic Apps–based playbooks. Success also depends on disciplined Log Analytics workspace architecture, well-governed Data Collection Rules (DCRs) for the Azure Monitor Agent (AMA), sound retention strategy, and operational proficiency in UEBA, watchlists, hunting, and workbooks.

Connectors and Data Ingestion

Windows Security Events via AMA are the canonical source for Windows Server sign-in, process creation, policy change, and other audit events. Enable the “Windows Security Events via AMA” connector in Microsoft Sentinel and create a DCR that selects the event sets appropriate for your risk profile (Minimal, Common, or All, or a custom selection by Event ID). Data lands primarily in the SecurityEvent table; non-security Windows channels (if enabled) land in WindowsEvent. Pair with Group Policy to ensure the Security baseline and auditing subcategories (e.g., Logon/Logoff, Account Logon, Object Access, DS Access) are enabled on source servers to generate the necessary telemetry.

Syslog via AMA collects from Linux servers and network devices that speak Syslog. Install AMA on Linux hosts (or a dedicated Linux collector) and configure a DCR to specify facilities and severities to ingest. Events are written to the Syslog table. For high-volume but low-value facilities, consider selective collection or transformation at source to control cost and noise.

CEF via AMA enables ingestion of normalized security logs from third-party security products (firewalls, IDS/IPS, proxies, EDR). Deploy AMA on a Linux collector and configure your vendors to forward CEF to the local syslog daemon (rsyslog/syslog-ng) on ports typically 514/UDP or TCP. In Sentinel, enable the “CEF via AMA” data connector and link the host via a DCR that parses CEF. Parsed data enters the CommonSecurityLog table with a consistent schema (deviceVendor, deviceProduct, destination/source fields, and extension attributes), simplifying cross-vendor analytics and correlation.

For on-premises Windows Servers, use Azure Arc–enabled servers to bridge to Azure. Onboard machines with the Azure Connected Machine agent, then deploy the AMA extension via Azure Policy for scale. Author DCRs targeting Arc server scopes to route Windows Security Events, Windows Firewall logs, and, if using Sysmon, a custom DCR for the Microsoft-Windows-Sysmon/Operational channel. This pattern centralizes configuration, versioning, and scope-based targeting, ensuring consistent ingestion without per-host manual work.

Workspace Architecture and Data Lifecycle

Sentinel attaches to a single Log Analytics workspace per deployment. Workspace design should minimize cross-region latency and egress—co-locate workspaces with the majority of data producers, and avoid excessive fragmentation that complicates queries, incident triage, and RBAC. Common patterns are a single security workspace per tenant or one per major region where data residency and latency require separation. Use resource-context access where possible to ensure teams can query logs for resources they own without broad workspace permissions, while Sentinel roles (Reader, Responder, Contributor) govern SOC operations.

DCRs govern what telemetry types, channels, and event sets are collected and where they are sent. Treat DCRs as code: standardize naming, version controls, and scopes (subscriptions, resource groups, tags). Group related sources and destinations, and prefer multiple targeted DCRs over one monolithic rule to simplify blast radius and lifecycle management. When syslog and CEF volumes are high, consider separate DCRs to tune facility/severity independently and to support staged testing.

Retention and cost are controlled at the table level. Set default workspace retention to meet policy (e.g., 90–180 days for active search), then override per-table retention where necessary. High-value tables (SecurityEvent, CommonSecurityLog, SecurityAlert) typically retain longer; verbose tables (Syslog with DEBUG) may retain less. Use archive for long-term, low-cost storage with search jobs; promote to hot as needed for investigations. Where appropriate, move some verbose tables (such as Syslog) to Basic Logs for reduced cost, recognizing query limitations and that certain security tables (e.g., SecurityEvent) are not eligible for Basic. Regularly review data caps, commitment tiers, and ingestion trends to prevent throttling and optimize cost.

Analytics, Incidents, and Response Automation

Analytics rules are the engine of detection. Scheduled query rules run KQL on a schedule (e.g., every 5 minutes) over a lookback period (e.g., 30 minutes), supporting aggregations, joins, watchlist enrichments, and suppression windows. They are ideal for well-understood patterns like multiple failed logons followed by a success, lateral movement heuristics, or suspicious process lineage. Near-real-time (NRT) rules minimize detection latency by continuously processing new data with executions roughly every minute and alerting within about two minutes; design NRT rules to be concise and to rely on ingestion_time() or narrow windows to avoid heavy historical scans. Fusion rules use Microsoft’s multistage attack analytics to correlate low-signal alerts across products (e.g., Defender for Endpoint, Defender for Identity, Entra ID Protection, third-party CEF) into high-fidelity incidents for campaigns like credential theft or ransomware. Anomaly rules leverage built-in ML templates that learn baselines (e.g., unusual sign-in locations, rare process execution) and emit deviations; these commonly read from BehaviorAnalytics and other normalized sources.

Incidents unify multiple alerts, entities, and evidence under a single investigative case. Severity is assigned by the analytics rule (or dynamically by Fusion) and can be escalated or reduced via automation rules. Entity mapping is critical to investigation efficacy: in the rule wizard, map query columns to entity types (Account, Host, IP, URL, File, Process, CloudApplication, AzureResource). Proper mapping populates the investigation graph, which visualizes relationships across alerts, events, and entities, enabling pivoting on accounts, hosts, processes, and IPs. Use comments, tags, owner, and classification to capture analyst disposition and to train tuning workflows.

Automation blends Automation rules and Playbooks. Automation rules evaluate incident metadata on creation or update to assign owners, change severity, add tags, close false positives, or invoke playbooks. Playbooks are Azure Logic Apps built with the Microsoft Sentinel connectors. Incident-triggered playbooks react to incident lifecycle events (e.g., when an incident is created) and are suited for incident-scoped actions like notifying a team, enriching all entities, or creating a ServiceNow ticket. Alert-triggered playbooks fire on single alerts before they are grouped into an incident—useful for vendor-specific enrichments or pre-triage. Adopt managed identity for playbooks, grant least-privilege via Azure RBAC and API permissions, and parameterize workspace IDs, ticketing endpoints, and block-list paths to promote reuse. Where containment is warranted, include actions that quarantine endpoints (Defender for Endpoint), disable accounts (Entra ID), block IPs (firewalls), or revoke sessions (Conditional Access) only after confidence thresholds are met.

Proactive Security Operations (Hunting, UEBA, Watchlists, Workbooks)

Threat hunting in Sentinel relies on KQL proficiency and the hunting blade. Start with the built-in hunting queries organized by tactic; customize to your environment by referencing tables like SecurityEvent (Windows audit), Device* tables from Defender, CommonSecurityLog (CEF), and SigninLogs (Entra). Use bookmarks to snapshot interesting records, annotate them, and share context across the team; multiple bookmarks can be promoted to a new or existing incident. Livestream continuously runs a KQL pattern to detect new matching events in near real-time—ideal for time-bound investigations or rapid surge scenarios. Convert mature hunting queries into scheduled analytics rules to operationalize detections.

UEBA (User and Entity Behavior Analytics) enriches detection with behavioral baselines and anomaly scoring. Enable UEBA from the Sentinel configuration, and ensure identity and activity data sources (Microsoft Entra sign-ins, Defender for Endpoint, Defender for Identity, M365 activity) are connected. Entity pages for users and hosts show timelines, peer comparisons, anomalous activities (rare logon geo, unusual process), and aggregated risk scores. Analysts can pivot from incidents to entity pages to assess whether an action is typical for that identity or device; anomaly scores and sequences help prioritize triage and corroborate or refute hypotheses quickly.

Watchlists provide fast, analyst-maintained reference data. Create watchlists from CSV uploads or a storage account path, define an alias, and select a key column for efficient lookups. Use the watchlist() function in KQL for joins—common uses include allow/deny lists of administrative accounts, sensitive hosts, sanctioned domains, or VIP users. Incorporate watchlists into analytics rules to suppress known-good activity (reduce false positives) or to elevate severity when a match involves a critical asset. Integrate with threat intelligence by joining watchlists to the ThreatIntelligenceIndicator table for context (e.g., enrich detected IPs with internal severity or case notes), or by converting curated TI feeds into a watchlist for quick reference and overrides.

Workbooks power monitoring and executive visibility. Start with built-in templates such as Security Operations Efficiency, Active Directory Sign-ins, Fusion Detections, and UEBA insights. Build custom workbooks using KQL queries, parameters, and visualizations to create SOC dashboards for ingestion health, rule performance, incident SLAs, and emerging threats. Apply RBAC on the workbook resource and parameterize subscriptions, workspaces, and time ranges so the same workbook can serve different teams. Combine tiles from multiple tables to correlate posture (Defender for Cloud), detections (Sentinel), and response metrics in one view.

Practical Problem Scenario

Spotify must centralize security monitoring for 2,000 Windows Servers across Azure and on-premises data centers, plus third-party firewalls and proxies. They need low-latency detections for credential abuse, automated ticketing and containment, and clear dashboards and hunting workflows for the SOC.

1. Onboard hybrid servers with Azure Arc and AMA

• Deploy Azure Arc–enabled server onboarding at scale using Azure Policy, then assign the AMA extension policy to the Arc scope. Create DCRs for “Windows Security Events via AMA” (Common set), Windows Firewall, and a custom DCR for Sysmon where installed. This approach provides consistent, centrally managed collection without per-host scripting and ensures SecurityEvent is populated for identity and process analytics.

2. Ingest network and security appliance telemetry via Syslog and CEF

• Stand up a Linux collector VM with AMA. Configure “Syslog via AMA” for relevant facilities, and enable “CEF via AMA” to parse firewall and proxy CEF into CommonSecurityLog. Using CEF normalizes multi-vendor data, enabling rule portability and easy joins across sources.

3. Engineer analytics for speed and fidelity

• Enable Fusion to capture multistage attacks with minimal tuning. Create NRT rules for bursts of failed logons followed by success on privileged accounts using SecurityEvent and ingestion_time(), providing sub-two-minute detection. Build scheduled rules for lateral movement patterns (e.g., Process Create of net.exe on servers joined to unusual admin accounts) and for proxy egress anomalies joined to VIP and crown-jewel host watchlists. This blend minimizes MTTR while curbing false positives.

4. Map entities and shape incidents

• In each scheduled rule, map Account, Host, IP, and Process entities from query columns. Use automation rules to assign incidents by business unit (derived from host tags), standardize severity, add MITRE tags, and auto-close known test signals. Proper mapping enables the investigation graph to show relationships Spotify’s analysts can pivot through rapidly.

5. Automate enrichment, ticketing, and containment with playbooks

• Build an incident-triggered playbook that enriches all accounts and hosts (graph lookups, device risk), posts to Teams, and opens a Jira ticket. A separate alert-triggered playbook enriches specific CEF alerts with vendor APIs. Use managed identities with least-privilege RBAC and conditional branching that only isolates devices (via Defender for Endpoint) or disables users (via Entra ID) when confidence thresholds (e.g., multiple corroborating alerts and high UEBA score) are met. This preserves business continuity while enabling fast, governed response.

6. Enable UEBA and operationalize hunting

• Turn on UEBA and validate data sources (SigninLogs, M365 activity, Defender signals). Train analysts to pivot from incidents to entity pages for anomaly scores and peer comparisons. Convert two high-value hunting queries—“New remote admin tools on servers” and “Rare external IP exfil patterns”—into scheduled analytics once validated via bookmarks and livestream. UEBA plus disciplined hunting tightens detection of novel techniques.

7. Govern data lifecycle and visualize posture

• Set retention to 180 days for SecurityEvent and CommonSecurityLog, 30 days for verbose Syslog with archive to 1 year, and monitor cost with commitment tiers. Publish a custom SOC workbook that tracks ingestion health, top noisy rules, MTTA/MTTR, incident queues by severity, and UEBA anomalies over time. This provides leadership transparency and drives continuous tuning.

Each tool was chosen for its fit-for-purpose strength: Arc and AMA+DCR deliver scalable, policy-driven ingestion; CEF ensures normalized multi-vendor security logs; Fusion and NRT lower detection latency without excessive tuning; entity mapping and the investigation graph accelerate triage; playbooks provide governed, identity-backed automation; UEBA supplies behavioral context; hunting tools mature detections; and workbooks keep operations measurable and visible.

← Microsoft Defender for Cloud and Endpoint Security · All domains · Active Directory Domain Services Security →

Practice these questions → · Timed practice on ExamRoll.io →

Browse Microsoft →