Design solutions for security operations

Tallgrass Insurance runs Microsoft Sentinel with 180 analytics rules. The SOC lead wants that whenever any incident of High severity is created that contains an Account entity, the account is automatically disabled in Microsoft Entra ID, the incident is tagged Contained, and it is assigned to the Tier 2 group. The design must apply to incidents from all current and future analytics rules and must minimize administrative effort.

What should you recommend?

1. AAdd an alert-trigger playbook to the automated response tab of each of the 180 analytics rulesPer-rule alert playbooks must be attached to every rule, including future ones, which is the opposite of minimal effort, and alert triggers run before the incident exists so they cannot tag or assign the incident.
2. BCreate one automation rule triggered when an incident is created with a severity condition of High, which tags the incident, assigns the owner, and runs an incident-trigger Logic Apps playbook that disables the userAutomation rules evaluate every incident regardless of which rule created it, can tag and assign directly without a playbook, and can call an incident-trigger playbook that reads the Account entity and disables the user through Microsoft Graph.
3. CCreate an Azure Monitor action group that runs an Azure Function when a Sentinel incident alert firesAction groups respond to Azure Monitor alerts, not to Sentinel incidents, and have no access to incident entities, tags, or ownership.
4. DConfigure a Microsoft Defender XDR custom detection rule with the Disable user response actionCustom detections act only on signals in the Defender XDR advanced hunting tables, so they would not cover incidents raised by Sentinel rules over third-party or Azure data.

Pinecrest Utilities runs a hybrid environment with Microsoft Entra ID, 12 Azure subscriptions, and 200 Windows servers in its own data center. The security team wants Microsoft Entra sign-in and audit logs, Azure Activity logs, and Windows Security events from the on-premises servers in a single store that supports Kusto queries and two years of retention. You must minimize administrative effort.

What should you recommend?

1. AConfigure Microsoft Entra diagnostic settings and Activity log diagnostic settings to send to one Log Analytics workspace, onboard the servers with Azure Arc, and collect Security events with Azure Monitor Agent through a data collection ruleDiagnostic settings are the native path for Entra and Activity logs into Log Analytics, and Azure Arc makes on-premises servers first-class targets for Azure Monitor Agent and data collection rules, giving one Kusto-queryable store with configurable retention.
2. BExport all logs to an Azure Storage account with immutable blob storageStorage is a cheap archive, but it does not support Kusto queries across the data and would not collect Windows Security events from the on-premises servers by itself.
3. CInstall the Microsoft Defender for Endpoint sensor on the servers and review events in advanced huntingAdvanced hunting retains 30 days of device telemetry and does not contain Entra sign-in logs or Azure Activity logs, so it fails the single-store and retention requirements.
4. DEnable Microsoft Purview Audit (Premium) and search the unified audit logPurview Audit covers Microsoft 365 workload activity and Entra audit events, but it does not collect Azure Activity logs or on-premises Windows Security events.

Bellweather Health runs a 24x7 SOC in Microsoft Sentinel. Audits found that Tier 1 analysts handle phishing incidents inconsistently: some forget to check whether the URL was clicked, others skip resetting the user's sessions. The SOC manager wants every incident created by the phishing analytics rules to carry a standardized, trackable checklist that analysts must complete before closing, visible on the incident itself. You must minimize administrative effort.

What should you recommend?

1. ACreate an automation rule scoped to the phishing analytics rules that adds incident tasks to each new incidentIncident tasks are a native Sentinel feature; an automation rule can add a fixed task list to incidents created by selected analytics rules, and analysts tick the tasks off on the incident page so completion is tracked.
2. BCreate a playbook that emails the phishing checklist to the assigned analyst when an incident is createdAn emailed checklist is not visible on the incident and provides no record of which steps were completed; it recreates the inconsistency the manager is trying to remove.
3. CPublish the checklist in a Sentinel workbook that analysts open during triageWorkbooks are for visualization and reporting; they cannot attach a trackable task list to a specific incident or enforce completion.
4. DStore the checklist steps in a watchlist and reference it from the phishing analytics rule queryWatchlists enrich detection queries with reference data; they are not an incident workflow mechanism and do not surface tasks to analysts.

Ravenshoe Mining is designing its SOAR architecture. Microsoft Defender for Endpoint protects 9,000 devices, and Microsoft Sentinel is the SIEM. Requirements: Defender XDR must fully remediate malware on devices without analyst approval; Sentinel incident status and closure must stay synchronized with Defender XDR in both directions; and Sentinel playbooks must run with the least privilege needed. Playbooks live in a resource group named rg-playbooks.

Which three actions should you recommend? Each correct answer presents part of the solution.

1. AConnect the Microsoft Defender XDR data connector to Sentinel with incident integration enabled so incidents and their status sync bi-directionallyThe Defender XDR connector synchronizes incidents, including status, owner, and closure, in both directions between Defender XDR and Sentinel.
2. BSet the device groups in Defender for Endpoint to the automation level Full - remediate threats automaticallyAutomated investigation and response in Defender XDR remediates without approval only when the device group's automation level is Full; lower levels queue remediation for analyst approval.
3. CGrant the Microsoft Sentinel Automation Contributor role to the Sentinel service identity on rg-playbooksSentinel runs playbooks from automation rules using its own service identity, which needs the Microsoft Sentinel Automation Contributor role scoped to the resource group that contains the playbooks; this is the least-privilege grant Microsoft documents.
4. DAssign the Owner role on the subscription to the Sentinel service identity so it can run any playbookOwner at subscription scope is far more than playbook execution requires and violates the least-privilege requirement.
5. EAttach a separate alert-trigger playbook to each Defender XDR incident type to close the matching Sentinel incidentClosure synchronization is handled by the connector's bi-directional sync; building playbooks to mimic it duplicates functionality and adds maintenance.