Microsoft Security Operations Analyst Associate Practice Test (SC-200)

Microsoft Sentinel can only recognize data in a query result as entities when you explicitly map the relevant columns to one of the supported entity types during rule creation. In the Set rule logic step, you can add an entity mapping and choose the entity type (such as IP) and then specify which column in the query output contains the corresponding value. For the IP entity type, the required field is Address. Mapping the src_ip column to the IP entity's Address field ensures each matching value is treated as an IP entity, unlocking entity pages, graphs, and UEBA insights for incidents generated by the rule. The other options do not achieve this: a playbook would run only after an alert is created, data transformations in Log Analytics do not automatically apply entity semantics, and there is no workspace-level "Automatically extract host information" setting for entity detection.

For a scheduled query analytics rule, the most direct way to stop unwanted incidents for a particular source is to refine the rule's Kusto Query Language (KQL) statement. Adding a filter such as | where SubscriptionId != "SubDev" removes events from the development subscription before the rule evaluates its alert logic, so no alerts-or incidents-are produced for that subscription while the rule continues to run normally for the other subscriptions.

Creating an automation rule or playbook that closes incidents after they are raised does not prevent the alerts or incidents from being generated in the first place, so it does not meet the requirement to avoid creation. Microsoft Sentinel does not have an "incident suppression rule" or an alert-grouping setting that can selectively suppress incidents by subscription within a single rule; grouping only affects how incidents are consolidated, not whether they are created. Therefore, modifying the KQL query is the correct and most efficient approach.

The Data Collector API automatically creates a custom log table the first time it receives data that uses a previously unseen Log-Type value. Therefore, you do not need to pre-create SecurityAppliance_CL, deploy an agent, or configure analytics rules. Once the first POST succeeds, the table is created and populated, and its columns are inferred from the JSON properties.

In the unified audit log, Exchange Online records the creation of a new inbox (mailbox) rule with the Operation value "New-InboxRule". Filtering the search on this operation returns only events where a rule was added. Similar-sounding values such as "Set-InboxRule" (rule changes), "Add-MailboxPermission" (permission changes), and "UpdateInboxRules" are different operations and will not match the activity of creating a new rule.

When an insider risk alert is opened in the Microsoft 365 Defender portal, selecting Create an eDiscovery (Premium) hold from the alert allows the analyst to immediately preserve the exact files, their versions, and related audit information in a dedicated eDiscovery case. This protects the evidence from alteration or deletion and keeps the user unaware of the investigation. Creating a retention policy, disabling the user account, or running a content search would not automatically place the items on legal hold and therefore would not guarantee evidence preservation at the required forensic standard.

When an analyst asks Security Copilot to investigate a Defender XDR incident, Copilot analyzes all related alerts and evidence, then provides a natural-language summary that includes the incident timeline, impacted assets, observed attacker techniques, and recommended mitigation steps. Copilot does not automatically close the incident, quarantine devices, or create new detection rules; those actions still require explicit analyst decisions or playbook automation.

Microsoft Sentinel displays entities such as accounts, hosts, and IP addresses in the incident investigation graph only when the analytics rule explicitly maps the query's result columns to Sentinel's built-in entity types. This is done in the Entities (entity mapping) section of the rule wizard, where you specify which query column represents each entity-for example, map Account to Account, Computer to Host, and SrcIpAddr to IP. Simply enabling Entity Behavior Analytics, adding playbooks, or configuring field mappings in a data connector does not cause incidents from this specific rule to include entities because those settings do not create the required per-rule entity bindings.

The Azure Policy data connector relies on Azure Monitor diagnostic settings to stream PolicyInsights logs. Until a diagnostic setting is created on each subscription (or managed centrally at the tenant root) that sends the PolicyInsights log categories to the Log Analytics workspace connected to Microsoft Sentinel, no compliance or evaluation data reaches the workspace. Assigning Azure Policy initiatives, adding Sentinel solutions, or enabling data collection rules do not by themselves transmit the logs; they act on data only after it has been forwarded.

A playbook that should run when Microsoft Sentinel creates a new incident must start with the dedicated incident trigger provided by the Microsoft Sentinel connector. The trigger named "When a response to an Azure Sentinel incident is triggered" (sometimes shown as "Microsoft Sentinel incident") is specifically designed to be called from an automation rule on incident creation. The older alert-level trigger ("When a response to an Azure Sentinel alert is triggered") only works for alert automation, and generic Logic App triggers such as "Recurrence" or "When an HTTP request is received" do not integrate with Sentinel automation rules without additional configuration.

Selecting Purge with the Soft delete option starts a purge action (New-ComplianceSearchAction -Purge -PurgeType SoftDelete) that moves each message to the Deletions sub-folder of the Recoverable Items folder. Users cannot access the item, but administrators can restore it by using eDiscovery or mailbox-restore tools if further investigation is required. Exporting results or reports only produces copies of the data and leaves the originals in the mailboxes. Creating a retention policy does not retroactively delete already-sent messages and therefore will not remove the malicious email identified by the Content search.

Applying the ban governance action to an OAuth application in Microsoft Defender for Cloud Apps performs two tasks required in this scenario. First, it revokes the existing OAuth refresh tokens that users have previously granted, so the app can no longer access Microsoft 365 data with those tokens. Second, it prevents any additional users in the tenant from granting the application consent in the future. Marking the app as unsanctioned only helps with Shadow IT discovery traffic and does not touch OAuth tokens or consent. Quarantining users is not an available governance action for OAuth apps, and Conditional Access cannot retroactively revoke existing tokens or by itself stop other users from consenting. Therefore, banning the app is the correct remediation step.

Security Copilot provides four built-in application roles that can be assigned in Microsoft Entra ID:

• Security Copilot Administrator - full control, including managing settings, plugins, and access assignments.
• Security Copilot Contributor - can interact with Copilot, upload data, and create or run promptbooks, but cannot manage plugins, workspace settings, or role assignments.
• Security Copilot Responder - can run prompts and view responses but cannot create promptbooks.
• Security Copilot Reader - can only view existing content.

Because the SOC analysts need to create and run promptbooks and upload investigation data, they require more than Reader or Responder rights. However, they must be prevented from tenant-level administration, so the Administrator role is too permissive. The Contributor role meets all requirements without granting unnecessary administrative privileges, making it the correct choice.

The Investigation graph (also called the investigation map) is opened directly from an incident in Microsoft Sentinel. It automatically lays out all alerts, entities, and supporting evidence, and lets you expand or pivot on nodes to follow the attack path without running any queries. Livestream, Threat intelligence, and the Query timechart view do not create an entity-centric visual map of the incident.

Automatic attack disruption can isolate a device only when that device is fully onboarded and actively reporting to Microsoft Defender for Endpoint. Features such as EDR in block mode or Microsoft Edge Defender SmartScreen can provide additional protections, but they are not required for the immediate containment action. Devices that are merely identified as unmonitored resources in Defender for Cloud cannot be isolated because they are not managed by Microsoft Defender for Endpoint.

To compare each user's current activity to that same user's historical baseline, you must use the Anomaly rule type in Microsoft Sentinel. An Anomaly rule applies Sentinel's built-in time-series behavioral analytics models to the query's result set, learning normal patterns per entity (such as an individual account) and raising alerts only when the current value significantly deviates from the learned baseline. Scheduled query rules use static or dynamic thresholds that you configure manually, and Fusion or Machine learning rules do not support custom Kusto queries.

To make a customized workbook available to everyone with appropriate Azure RBAC permissions, you must save it as an Azure-hosted workbook within the Sentinel resource group. Selecting Save as, choosing Save to Azure, and specifying the Sentinel resource group stores the workbook as an ARM resource that is accessible and editable by other users in that group. Simply selecting Save keeps the workbook in your personal workspace; exporting an ARM template or publishing to My Workbooks does not automatically share it with the team.

Workbooks in Microsoft Sentinel support parameters that can be bound to all queries in the workbook. Adding a Time range parameter (often inserted by selecting Add parameter and choosing Time range) exposes a picker for analysts to set start and end times. When each query references the parameter by using the {{TimeRange}} or similar binding syntax, Sentinel automatically appends the chosen time filter to every query, ensuring that results are limited to the selected period. Other options-such as creating a workspace selector, enabling cross-visual filtering, or relying on Azure Monitor dashboard settings-do not propagate a time filter to every workbook query by default.

The Microsoft Sentinel Responder role allows analysts to view incidents and make basic changes such as updating status, owner, severity, and adding comments or tags. It does not permit modification of analytics rules or connector configurations. To manually run an existing playbook that is linked to an incident, the analyst also needs permission to execute the Logic App. The Logic App Contributor role on the resource group that hosts the playbook grants that permission without allowing the user to create or delete other Azure resources. The other options either do not provide the ability to update incidents or run playbooks (Reader), grant greater-than-necessary privileges to Sentinel configuration (Sentinel Contributor or Azure Contributor), or fail to provide playbook execution rights.

Using a per-table data lifecycle configuration that keeps data in the default (Analytics) tier for 30 days and then automatically moves it to the archive tier for the remaining 720 days satisfies both requirements. The first 30 days remain in hot storage for fast, interactive querying, while the two-year archive tier keeps the data at a much lower cost that still allows on-demand search or restore when needed.

Keeping 730 days in the Analytics tier meets retention goals but is the most expensive option. Basic Logs cannot retain data longer than eight days, so it cannot meet the 24-month mandate. Exporting logs to an external storage account removes them from Sentinel's query experience and requires additional tooling to access the data, failing the requirement for occasional in-product access.

Real-time inspection of traffic to and from a cloud app is achieved in MDCA through session policies, which rely on Conditional Access App Control. A session policy can examine each download request as it happens and, based on file attributes such as Microsoft Purview sensitivity labels, enforce controls like Block download (with custom message). File or activity policies act after the operation is complete, and anomaly detection policies are intended for behavioral analytics, so none of them can stop the download in real time or present an immediate block message.