Implement activity and event collection in Microsoft Sentinel

Maplewood Financial runs 200 Windows Server virtual machines in Azure in a subscription named Sub-Win and has Microsoft Sentinel on a workspace named law-mw-soc. The SOC needs the security events that the built-in Sentinel analytics rules depend on, such as logon events, process creation, and account management, but the budget cannot support ingesting every security event from 200 servers. The engineer is configuring the Windows Security Events via AMA data connector.

Which event set should you select in the data collection rule?

1. ACommonThe Common set is a curated subset of security event IDs that covers most detection use cases, including logon, process, and account management events, at a fraction of the volume of All events.
2. BAll security eventsAll events collects the entire Security log from every server, which the scenario's budget rules out.
3. CMinimalMinimal collects only a very small set of high-value events and omits many IDs that the built-in analytics rules expect, so detections would miss activity.
4. DCustom with the XPath query Security!*An unfiltered Security!* XPath is equivalent to All events and provides no cost saving.

Halvorsen Mining has 600 on-premises Windows workstations that already forward their Security logs through Windows Event Forwarding to a Windows Event Collector server named wec-hm-01, where the events land in the ForwardedEvents channel. Microsoft Sentinel runs on a workspace named law-hm-soc. Corporate policy forbids installing any agent on the workstations, and wec-hm-01 is already connected to Azure Arc. The engineer must get the forwarded workstation security events into the SecurityEvent table.

What should you do?

1. AUse the Windows Security Events via AMA connector to create a data collection rule that targets wec-hm-01 and uses a Custom event set with an XPath query against the ForwardedEvents channelAzure Monitor Agent on the collector reads the ForwardedEvents channel when the data collection rule's custom XPath targets it, which brings all the WEF-collected workstation events into Sentinel with a single agent.
2. BCreate a data collection rule that targets wec-hm-01 with the Common event setThe predefined event sets read the collector's own Security log, not the ForwardedEvents channel where the workstation events are stored.
3. CConnect each of the 600 workstations to Azure Arc and target them with a Windows Security Events via AMA data collection ruleThis installs the Connected Machine agent and Azure Monitor Agent on every workstation, which the policy forbids, and it discards the existing WEF investment.
4. DInstall the Log Analytics agent on wec-hm-01 and enable the Security Events via Legacy Agent connectorThe Log Analytics agent and the legacy connector are retired; the supported method is Azure Monitor Agent with a data collection rule.

Oakhurst Payments runs an in-house fraud engine that writes JSON events. The security team wants the events in a custom table named FraudEvents_CL in the Microsoft Sentinel workspace law-oh-soc so that analytics rules can query them. The engineer has created the table with a DCR-based schema, created a data collection rule named dcr-fraud with a transformation, and registered a Microsoft Entra application named app-fraud-ingest that will call the Logs Ingestion API. Test calls return HTTP 403 Forbidden. You must fix the problem with the least privilege.

What should you do?

1. AAssign the Monitoring Metrics Publisher role to app-fraud-ingest on dcr-fraudThe Logs Ingestion API authorizes the caller against the data collection rule; Monitoring Metrics Publisher on the DCR is the documented least-privilege role that permits sending data.
2. BAssign the Log Analytics Contributor role to app-fraud-ingest on law-oh-socLog Analytics Contributor manages the workspace and is far broader than needed; it also does not grant the data-plane permission on the DCR that the API checks.
3. CAssign the Microsoft Sentinel Contributor role to app-fraud-ingest on law-oh-socSentinel Contributor is a management role for analytics rules and workbooks; it plays no part in Logs Ingestion API authorization.
4. DRecreate FraudEvents_CL as a classic custom log table that uses the legacy HTTP Data Collector API with the workspace keyThe HTTP Data Collector API and classic custom logs are deprecated; DCR-based custom tables with the Logs Ingestion API are the supported approach.

Cedarline Shipping runs Microsoft Sentinel on a workspace named law-cl-sec. A new tier-1 analyst group named SG-SOC-T1 must be able to view incidents and data, assign incidents to themselves, change incident status and severity, and add comments. The group must not be able to create or edit analytics rules, workbooks, or automation rules. You must follow the principle of least privilege.

Which role should you assign to SG-SOC-T1 on law-cl-sec?

1. AMicrosoft Sentinel ResponderResponder includes everything in Reader plus the ability to manage incidents: assign, change status and severity, and comment, without permission to create or edit analytics rules, workbooks, or automation.
2. BMicrosoft Sentinel ReaderReader can view incidents and data but cannot assign incidents or change their status or severity.
3. CMicrosoft Sentinel ContributorContributor adds the ability to create and edit analytics rules, workbooks, and other Sentinel resources, which exceeds what tier-1 analysts need.
4. DLog Analytics ContributorLog Analytics Contributor manages the workspace itself and its data collection; it is not a Sentinel role and does not grant incident management in Sentinel.