Question 1: You need to change the severity of all "Kerberoasting" incidents from Medium to High. What is the simplest mechanism?
Automation rule. Trigger: incident created. Condition: analytics rule name contains "Kerberoasting." Action: change severity to High. No Logic App needed — this is a simple property change.
Logic App playbook. A playbook works but is unnecessary overhead for a single property change. Automation rules handle severity changes without code, without Azure resources, and without connector costs.
Modify the analytics rule to output High severity. This works but couples the severity decision to the detection rule. Using an automation rule separates detection logic from triage logic, allowing you to change severity without modifying the detection.
KQL query that updates incident severity. KQL is read-only — it queries data but cannot modify incidents. Incident property changes require automation rules or the Sentinel API.
Question 2: Your enrichment playbook uses managed identity to call Microsoft Graph. The playbook needs to read user risk data. What is the minimum Graph permission required?
Directory.ReadWrite.All. This grants read AND write access to all directory objects — far more than needed. This violates least privilege and provides write access the playbook does not need.
IdentityRiskyUser.Read.All. This grants read-only access to risky user data — exactly what the enrichment playbook needs and nothing more.
User.ReadWrite.All. This grants write access to user profiles. The enrichment playbook only reads data — it does not need to modify user properties.
SecurityEvents.Read.All. This grants access to security events, not identity risk data. User risk data is accessed via the Identity Protection API, which requires IdentityRiskyUser.Read.All.
Question 3: Your playbook fails on some incidents with "No account entities found." The playbook works on AiTM incidents but fails on firewall alert incidents. What is the cause?
The firewall analytics rule does not map Account entities — it maps only IP entities. The playbook's "Get Accounts" action returns an empty array. Fix: add a Condition that checks entity count before proceeding, and handle the no-entity case gracefully (add a comment saying manual enrichment is needed).
The managed identity does not have permission for firewall incidents. Managed identity permissions apply to the workspace, not to specific incident types. If the playbook can read AiTM incidents, it can read firewall incidents.
Firewall incidents are processed by a different Sentinel connector. The playbook triggers on incidents from any connector — the Sentinel incident trigger does not filter by data source.
The playbook needs separate entity extraction for each analytics rule type. Entity extraction uses the same "Get Accounts" action for all incidents — the issue is that some incidents have no Account entity to extract, not that different incidents require different extraction methods.
Question 4: A playbook's enrichment query to VirusTotal fails with a 429 (rate limit) error. What is the correct error handling approach?
Configure the HTTP action with exponential backoff retry (3 retries). If all retries fail, add a Scope-level error handler that adds an incident comment: "VirusTotal enrichment failed (rate limited). Other enrichment sources completed successfully." The playbook continues with remaining enrichment sources.
Terminate the entire playbook on VirusTotal failure. This means the incident receives no enrichment at all — not even the enrichment from sources that succeeded. Partial enrichment is better than no enrichment.
Remove VirusTotal from the playbook to avoid rate limit issues. This removes valuable TI enrichment permanently. The correct approach is retry logic that handles temporary rate limits while preserving the enrichment capability.
Upgrade to VirusTotal Premium to increase the rate limit. This may be necessary long-term, but the immediate fix is proper error handling. Even Premium accounts can be rate-limited under extreme volume. Error handling is required regardless of plan tier.
Question 5: Your automation stack has 10 playbooks averaging 15 actions each, running on 500 incidents per day. What is the approximate monthly Logic App cost?
£500+/month. This overestimates by roughly 10x. Logic App Consumption pricing is £0.000025 per action, making the actual cost far lower.
Approximately £56/month. Calculation: 10 playbooks × 15 actions × 500 incidents × 30 days = 2,250,000 actions × £0.000025 = £56.25. This does not include external API subscription costs, which are budgeted separately.
£5/month. This underestimates — it would be correct for about 1 playbook with 11 actions, not 10 playbooks with 15 actions each.
Free — Logic Apps are included in the Sentinel license. Logic Apps are a separate Azure service with their own pricing. They are not included in the Sentinel license or the M365 E5 license. However, the cost is minimal compared to the analyst time saved.
Question 6: You need to test a containment playbook that auto-disables compromised accounts. How do you test safely?
Test against your own account in production. This disables your own account, locking you out of the tools you need to verify the test results. Never test containment against accounts you actively use.
Create a dedicated test account (test-containment@northgateeng.com) that can be safely disabled. Run the playbook against a test incident targeting this account. Verify the account is disabled. Run the rollback playbook to re-enable it. Verify rollback works. The test account exists solely for this purpose.
Test in dry-run mode only — never test the actual containment action. Dry-run validates the decision logic but does not confirm the containment action works. You need at least one test with actual containment (on a test account) to verify the Graph API call, the permission, and the result.
Wait for a real incident and test the playbook live. Testing on a real incident means the first execution of your containment automation is against a real compromised account during an active incident — if the playbook fails, you have delayed containment AND a debugging task during incident pressure.
Question 7: Your playbook monitoring analytics rule fires — a playbook failed 3 times in the last hour. What is the first thing you check?
Open the Logic App → Run history → click the failed run → expand each action to find which action failed and what error message was returned. The run history shows the exact input, output, and error for every action — the diagnosis is usually immediate (permission expired, API changed, entity extraction returned null).
Disable the playbook immediately to prevent further failures. Disabling stops all automation from the playbook, including successful runs. If the failure is intermittent (API timeout on 3 of 500 runs), disabling removes the value of the other 497 successful runs. Diagnose first, disable only if the failure is persistent and harmful.
Check if the Sentinel workspace is experiencing issues. While workspace issues can cause playbook failures, the Logic App run history provides the specific error — start there rather than investigating general platform health.
Rebuild the playbook from scratch. This destroys working configuration to fix what may be a simple permission expiration or API endpoint change. Always diagnose the specific failure before considering a rebuild.
Question 8: Your enrichment playbook adds a comment to every incident. An analyst complains that the enrichment comment contains "no data found" for 60% of incidents. What should you investigate?
The playbook is broken — 60% failure rate is unacceptable. "No data found" is not a failure — it means the KQL query returned no results. The playbook ran successfully; the data simply does not exist for those incidents.
Check whether the 60% of "no data found" incidents have different entity types than the enriched 40%. The enrichment queries SigninLogs by UPN — incidents without Account entities, or incidents where the account is a service principal (not in SigninLogs), will return no results. The fix: add enrichment queries for non-account entities (IP lookup for network alerts, device lookup for endpoint alerts) or handle the "no data" case with alternative enrichment.
Increase the KQL query lookback from 24 hours to 7 days. This may help for some incidents, but if the entity type is wrong (IP-only incidents queried by UPN), a longer lookback will not find data that does not exist for that entity type. The issue is entity-type mismatch, not time range.
Remove the "no data found" message to reduce noise. The "no data found" message is valuable — it tells the analyst that enrichment was attempted and no results were found, which is different from "enrichment was not attempted." Removing the message creates ambiguity.
