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, with distinct interactive retention (fast, expensive queries) and long-term/archive retention (slower, cheaper) tiers — a cost and compliance decision independent of which connectors are feeding data in.
⚠️ Exam Trap: Assuming ingested data stays queryable indefinitely at the same cost and speed is incorrect — retention tiers are configured explicitly, and data that ages past interactive retention into archive tier requires a separate search or restore operation before it can be queried normally again.
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?
