This chapter covers Sentinel Health and Auditing, a critical area for the SC-200 exam that ensures your SIEM is functioning correctly. You will learn how to monitor the health of data connectors, analytics rules, and automation, and how to audit changes using Sentinel's built-in health tables and workbooks. Approximately 10-15% of exam questions touch on monitoring and health, making this a high-yield topic for the exam.
Jump to a section
Imagine a large office building with a fire safety system. The building has smoke detectors, sprinklers, and fire alarms throughout. The health of this system is monitored by a central control panel that checks each component: it sends a test signal to every smoke detector every 30 seconds, verifies that water pressure in sprinkler pipes is within range, and confirms that alarm bells and strobes are functional. If a detector fails to respond, the panel logs a fault and alerts the building engineer. Similarly, Microsoft Sentinel has a health monitoring system that periodically checks its data connectors, analytics rules, and automation. For example, Sentinel sends a heartbeat signal from the Azure Monitor Agent to confirm data ingestion. If a connector stops sending data, Sentinel's health monitoring detects the missing heartbeat and generates a health alert. Just as the fire panel's logs help engineers identify which floor has a faulty detector, Sentinel's health tables allow analysts to pinpoint which data source or rule is failing. This proactive monitoring ensures the security system is always ready to detect real threats, not just sitting idle with undetected failures.
What is Sentinel Health and Auditing?
Sentinel Health and Auditing refers to the built-in monitoring capabilities that track the operational status of your Sentinel workspace. This includes data ingestion health, rule execution success/failure, automation runbook completion, and configuration changes. The primary goal is to detect issues like data gaps, rule failures, or misconfigurations before they impact security coverage.
Health monitoring is implemented through two main mechanisms: the SentinelHealth table and the SentinelAudit table. These are Azure Monitor Log Analytics tables that store health and audit events. They are automatically enabled in every Sentinel workspace and do not require additional configuration to start collecting data. However, you must query them to view the data.
How SentinelHealth Works
The SentinelHealth table captures the operational status of Sentinel components. Each row represents a health event for a specific resource. The key columns include:
ResourceId: The Azure resource ID of the component (e.g., data connector, analytics rule).
ResourceKind: The type of component (e.g., DataConnector, AnalyticsRule, AutomationRule).
OperationName: The operation performed (e.g., Data fetch, Rule run).
Status: The result (Success, Failure, Partial failure).
Description: A human-readable message explaining the event.
TimeGenerated: Timestamp of the event.
Internally, Sentinel agents and services emit health telemetry to this table. For example, a data connector like the Azure Activity connector will periodically attempt to pull logs. If successful, it logs a row with Status=Success. If it fails due to permissions or network issues, it logs a Failure with a description like "Access denied to subscription."
SentinelHealth events are generated for:
Data connectors: Every ingestion attempt (typically every 5-15 minutes depending on connector type).
Analytics rules: Every time a rule runs (scheduled rules run every 5 minutes by default).
Automation rules: Every time a rule triggers a playbook.
Hunting queries: When a query runs.
How SentinelAudit Works
The SentinelAudit table logs configuration changes made to your Sentinel workspace. This includes:
Creating, modifying, or deleting analytics rules.
Adding or removing data connectors.
Changing automation rules.
Modifying workbooks or watchlists.
Changing Sentinel settings (e.g., UEBA, entity behavior).
Each audit event contains:
ResourceId: The resource that was changed.
OperationName: The operation (e.g., CreateAnalyticsRule, DeleteDataConnector).
Caller: The user or service principal that made the change.
Result: Success or Failure.
Properties: JSON blob with details about the change (e.g., old and new values for modified fields).
SentinelAudit uses Azure Resource Manager (ARM) activity logs under the hood. When a change is made via the Azure portal, API, or CLI, an ARM audit event is generated and ingested into the SentinelAudit table. This table has a retention of 90 days by default, but you can adjust retention on the Log Analytics workspace.
Key Defaults and Timers
Data connector health check interval: Varies by connector type. For Azure-based connectors (like Azure Activity, Azure AD), the interval is typically 5 minutes. For syslog or CEF, it's 1 minute.
Analytics rule run interval: Scheduled rules run every 5 minutes by default. You can configure this from 5 minutes to 14 days.
SentinelHealth data retention: Same as Log Analytics workspace retention (default 30 days, configurable up to 730 days).
SentinelAudit data retention: 90 days (not configurable per table, but workspace retention applies; however, audit events are also stored in the Azure Activity log with 90-day retention).
Heartbeat signal: The Azure Monitor Agent (AMA) sends a heartbeat to the Heartbeat table every 1 minute. This is used to verify agent health.
Configuration and Verification
To view health data, you query the SentinelHealth table in Log Analytics. For example:
SentinelHealth
| where TimeGenerated > ago(1h)
| where Status == "Failure"
| project TimeGenerated, ResourceKind, ResourceId, DescriptionTo audit changes:
SentinelAudit
| where TimeGenerated > ago(7d)
| where OperationName contains "AnalyticsRule"
| project TimeGenerated, Caller, OperationName, PropertiesMicrosoft also provides a built-in workbook called "Sentinel Health & Audit" under the Workbooks blade. This workbook visualizes health and audit data with pre-built charts and filters. You can also create custom alerts based on SentinelHealth. For example, to alert when a data connector fails for more than 15 minutes:
SentinelHealth
| where TimeGenerated > ago(15m)
| where ResourceKind == "DataConnector"
| where Status == "Failure"
| summarize FailureCount = count() by ResourceId
| where FailureCount > 0This query can be used as an alert rule to notify the SOC team.
Interaction with Related Technologies
Sentinel Health works closely with:
Azure Monitor Agent (AMA): The AMA sends health signals for log collection. If the AMA fails, the connector health will show failure.
Log Analytics Workspace: Health and audit tables are stored in the workspace. Retention settings affect how long health data is available.
Azure Policy: You can use Azure Policy to enforce that Sentinel workspaces have health monitoring enabled (it is always enabled, but you can enforce that health alerts are configured).
Microsoft 365 Defender: For Microsoft 365 connectors, health includes status of data export from M365 to Sentinel.
Automation (Logic Apps): If a playbook fails, the automation rule health event will show failure, and the playbook's run history can be checked in Logic Apps.
Enable Health Monitoring
Health monitoring is enabled by default in every Sentinel workspace. No additional configuration is needed to start collecting SentinelHealth and SentinelAudit data. However, to view the data, you must query the tables or use the built-in workbook. Ensure that the Log Analytics workspace has sufficient retention (default 30 days) for health data. If you need longer retention, increase the workspace retention in the Azure portal under your Log Analytics workspace > Usage and estimated costs > Data Retention.
Query SentinelHealth Table
Use KQL to query the SentinelHealth table. For example, to see recent failures: SentinelHealth | where TimeGenerated > ago(1h) | where Status == "Failure" | project TimeGenerated, ResourceKind, ResourceId, Description. The table is populated every few minutes by Sentinel components. You can filter by ResourceKind to focus on data connectors, analytics rules, or automation. The Description column often contains the exact error message, such as 'Failed to fetch events from Azure Activity API: Access denied.'
Query SentinelAudit Table
Use KQL to query the SentinelAudit table. For example, to see who created a new analytics rule in the last week: SentinelAudit | where TimeGenerated > ago(7d) | where OperationName == "CreateAnalyticsRule" | project TimeGenerated, Caller, Properties. The Properties column is a JSON string that includes details like the rule name and configuration. You can parse it using KQL functions like parse_json(). Note that SentinelAudit only captures changes made via ARM; direct changes to the Log Analytics workspace (e.g., table schema) are not captured.
Use Health Workbook
Navigate to Azure Sentinel > Workbooks > Templates. Search for 'Sentinel Health & Audit' and open it. This workbook provides a dashboard with tiles showing total failures, top failing connectors, and audit activity. You can filter by time range and resource type. The workbook uses KQL behind the scenes, so you can examine the queries to learn how to build your own. This is the quickest way to get a visual overview of workspace health without writing custom queries.
Create Health Alerts
To proactively detect health issues, create alert rules based on SentinelHealth. For example, create a scheduled query rule that runs every 15 minutes and alerts if any data connector has failed more than 3 times in the last hour. Use the query: SentinelHealth | where TimeGenerated > ago(1h) | where ResourceKind == "DataConnector" and Status == "Failure" | summarize FailureCount = count() by ResourceId | where FailureCount > 3. Set the alert to trigger an incident and assign it to a SOC analyst. This ensures that connector failures are addressed quickly.
In a large enterprise with hundreds of data connectors, health monitoring is essential. For example, a global financial institution uses Sentinel to ingest logs from 500 on-premises syslog servers, 100 Azure subscriptions, and 50 SaaS applications. Without health monitoring, a single misconfigured firewall could stop sending logs for days without anyone noticing. By querying SentinelHealth daily, the SOC team identifies connectors with failures and resolves issues proactively. They also use SentinelAudit to track changes—when a junior admin accidentally disables a critical analytics rule, the audit log shows who made the change and when, allowing quick rollback.
Another scenario: A healthcare provider uses Sentinel for HIPAA compliance. They must ensure that all data connectors are healthy and that no configuration changes go unnoticed. They set up a weekly report using SentinelHealth and SentinelAudit, exported to a dashboard. They also create alert rules that trigger incidents when a connector fails for more than 30 minutes. This ensures they meet compliance requirements for continuous monitoring.
Common misconfigurations include: not increasing retention for health tables (default 30 days may be too short for compliance), not creating alerts on failures (relying only on manual checks), and failing to parse the Properties column in SentinelAudit (which contains critical details). Performance considerations: SentinelHealth and SentinelAudit tables can grow large in busy workspaces. Use partitioning and summarization in queries to reduce query time. For example, use where TimeGenerated > ago(1d) instead of scanning all data. Also, consider setting a daily cap on data ingestion to control costs, but ensure health data is not capped—health data is low volume but critical.
The SC-200 exam tests Sentinel Health and Auditing under objective 2.1 'Monitor and maintain Azure Sentinel'. Specifically, you need to know:
How to query health data: The exam expects you to write KQL queries against SentinelHealth and SentinelAudit tables. You may be asked to identify which table to use for a given scenario (e.g., 'Which table shows data connector failures?' Answer: SentinelHealth).
Default retention periods: SentinelHealth follows workspace retention (default 30 days). SentinelAudit has 90-day retention. A common wrong answer is that both have 90 days—only SentinelAudit does.
Common failure reasons: The exam may present a scenario where a connector fails. Know that common causes are permissions (e.g., missing Reader role on subscription), network connectivity, or throttling. The Description column will indicate the cause.
Built-in workbook: The 'Sentinel Health & Audit' workbook is a template. The exam may ask where to find it (Workbooks > Templates).
Alert rule creation: You may be asked to create an alert based on health data. Remember to use SentinelHealth as the data source, not SentinelAudit (which is for configuration changes).
Trap: Using SentinelAudit for health: Candidates often confuse the two tables. SentinelAudit is for changes, SentinelHealth is for operational status. If a question asks about 'data connector failures', the answer is SentinelHealth.
Trap: Retention of SentinelHealth: Some think it's 90 days like SentinelAudit, but it's actually workspace retention (default 30 days).
Edge case: Custom tables: If a data connector writes to a custom table, health is still tracked in SentinelHealth, not in the custom table.
Exam tip: When answering, always look for keywords: 'failure', 'health', 'status' point to SentinelHealth; 'change', 'modification', 'audit' point to SentinelAudit.
To eliminate wrong answers: If the question asks about 'monitoring the health of data connectors', eliminate any answer that mentions SentinelAudit or Azure Activity log. If it asks about 'tracking who modified an analytics rule', eliminate SentinelHealth and look for SentinelAudit or Azure Activity log (but SentinelAudit is more specific).
SentinelHealth table captures operational status; use it for failure detection (default retention = workspace retention, usually 30 days).
SentinelAudit table captures configuration changes; use it for auditing (retention = 90 days).
Both tables are enabled by default; no configuration needed except to query them.
Built-in workbook 'Sentinel Health & Audit' is found under Workbooks > Templates.
Create alert rules based on SentinelHealth to proactively detect connector or rule failures.
Common failure causes: permissions, network issues, throttling – check Description column.
SentinelAudit logs only ARM changes; does not log KQL queries or data ingestion.
For compliance, increase workspace retention if you need SentinelHealth data longer than 30 days.
These come up on the exam all the time. Here's how to tell them apart.
SentinelHealth
Stores operational status (success/failure) of components.
Used for monitoring data connector health, rule runs, automation.
Retention follows Log Analytics workspace retention (default 30 days).
Columns include Status, Description, ResourceKind.
Primary use: detecting failures and performance issues.
SentinelAudit
Stores configuration change events (create, modify, delete).
Used for auditing who made changes to Sentinel resources.
Retention is 90 days (fixed, not workspace retention).
Columns include Caller, OperationName, Properties (JSON).
Primary use: compliance and change tracking.
Mistake
SentinelHealth and SentinelAudit are the same table.
Correct
They are separate tables. SentinelHealth stores operational status (success/failure) of components. SentinelAudit stores configuration change events (who created/modified/deleted resources).
Mistake
Health monitoring must be manually enabled.
Correct
SentinelHealth and SentinelAudit are automatically enabled in every Sentinel workspace. No setup is required; you just need to query them.
Mistake
Both tables have a default retention of 90 days.
Correct
SentinelHealth retention follows the Log Analytics workspace retention (default 30 days). SentinelAudit has a fixed 90-day retention.
Mistake
SentinelAudit logs all changes including direct Log Analytics queries.
Correct
SentinelAudit only logs changes made via ARM (Azure Resource Manager), such as portal, API, or CLI changes. It does not log KQL queries or data ingestion changes.
Mistake
The Sentinel Health & Audit workbook is automatically pinned to the dashboard.
Correct
The workbook is a template that you must open and save. It is not automatically pinned; you can pin individual tiles after saving.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Query the SentinelHealth table with `where ResourceKind == "DataConnector" and Status == "Failure"`. This will return all failed data fetch operations. Check the Description column for the specific error, such as 'Access denied' or 'Network timeout'. You can also use the Sentinel Health & Audit workbook for a visual overview.
SentinelHealth follows the Log Analytics workspace retention, which defaults to 30 days but can be configured up to 730 days. SentinelAudit has a fixed retention of 90 days and is not configurable separately. For longer retention of health data, adjust the workspace retention setting.
Yes. Create a scheduled query alert rule using SentinelHealth. For example: `SentinelHealth | where ResourceKind == "AnalyticsRule" and Status == "Failure"`. Set the rule to run every 5 minutes and trigger an incident. This will alert you when a rule fails to run.
Query the SentinelAudit table with `where OperationName contains "AnalyticsRule"`. The Caller column shows the user or service principal that made the change. The Properties column contains details like the old and new configuration. For example: `SentinelAudit | where OperationName == "UpdateAnalyticsRule" | project TimeGenerated, Caller, Properties`.
Yes, if the PowerShell cmdlet uses the Azure Resource Manager API (e.g., `New-AzSentinelAlertRule`). Changes made directly to the Log Analytics workspace (e.g., via `Invoke-AzOperationalInsightsQuery`) are not logged in SentinelAudit because they do not go through ARM.
The Heartbeat table (from Azure Monitor Agent) indicates that an agent is running and connected. SentinelHealth, on the other hand, tracks whether Sentinel-specific operations succeed (e.g., data ingestion, rule execution). A connector can have a healthy agent (heartbeat present) but still fail to fetch data due to permissions – that failure appears in SentinelHealth.
Go to your Log Analytics workspace in the Azure portal, select 'Usage and estimated costs', then 'Data Retention'. Increase the retention slider to the desired number of days (max 730). This will affect all tables in the workspace, including SentinelHealth. Note that SentinelAudit retention remains at 90 days regardless.
You've just covered Sentinel Health and Auditing — now see how well it sticks with free SC-200 practice questions. Full explanations included, no account needed.
Done with this chapter?