5.2.3. Custom Log Tables, Automation Rules, and Data Retention
💡 First Principle: Not every data source fits Sentinel's built-in schemas, and not every incident needs a human to manually trigger the response — custom log tables and automation rules exist to handle exactly these two gaps, extending Sentinel beyond its out-of-box coverage.
Custom log tables let you ingest and store data that doesn't match any built-in table schema — a proprietary application's audit log, for example — making it available for the same KQL querying and analytics rules as native tables. Automation rules define what happens when an incident is created or updated (assign an owner, change severity, or — critically — invoke one or more playbooks, the actual Logic Apps-based automated actions, in a defined sequence). Data retention in Sentinel data stores is configured per table. Data in the analytics tier is indexed for fast, full-featured queries, with query cost included in its price; Sentinel tables keep it for 90 days by default, extendable to two years. Total retention continues beyond that in the lower-cost data lake (long-term retention) for up to 12 years, where analytics rules and normal interactive queries don't reach it; you use search jobs or KQL jobs instead. Tables can also be sent straight to the data lake tier. It's a cost and compliance decision independent of which connectors are feeding data in.
⚠️ Exam Trap: Assuming ingested data stays queryable the same way indefinitely is incorrect. Once data ages past analytics retention into long-term (data lake) retention, analytics rules and normal interactive queries no longer reach it, so you run a search job or KQL job first. Also note who pays for queries: they're included in the analytics tier and billed separately in the data lake.
Reflection Question: An automation rule is configured to trigger three playbooks in sequence for high-severity incidents. What's the practical difference between what the automation rule does and what each playbook does?
