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

A file policy in Microsoft Defender for Cloud Apps can scan files stored in connected SaaS applications such as SharePoint Online and OneDrive for Business. File policies support deep content inspection, can identify files that match a sensitive information type or keyword, and can automatically apply a Microsoft Purview Information Protection sensitivity label that encrypts the file. They also allow configuring governance actions, including sending alerts. Session policies control real-time actions such as downloads or uploads but cannot apply sensitivity labels. Activity policies monitor user actions and can generate alerts but cannot label or encrypt files. Anomaly detection policies are used for behavior analytics and do not perform content inspection or apply labels. Therefore, creating a file policy is the correct solution.

Only a file policy can inspect files at rest across connected cloud storage services and take governance actions on the affected files. By selecting the built-in U.S. Social Security Number data classification as the content inspection criterion and choosing the Apply sensitivity label governance action, Defender for Cloud Apps will automatically apply the Confidential label to matching files in SharePoint Online or OneDrive for Business. Activity policies and session policies work in near real time but cannot assign Microsoft Purview Information Protection labels, and anomaly detection policies are limited to behavioral anomalies rather than deterministic DLP actions.

The Azure Monitor Logs Ingestion API requires two main components before data can be sent: a data collection endpoint (DCE) that exposes an ingestion endpoint URI and a data collection rule (DCR) that defines the target Log Analytics workspace, the custom table name, and (optionally) any transformations. The DCE is mandatory because the API call that sends the JSON payload targets the DCE's endpoint. Diagnostic settings and workbooks play no role in the Logs Ingestion API flow, and the Log Analytics (MMA) agent is not used for this method of data collection.

Microsoft Sentinel does not infer entities from a query automatically. For each analytics rule you must explicitly tell Sentinel which columns represent which entity types. The Analytics rule wizard provides an Entities mapping (sometimes labeled Entity mapping) section where you choose an entity type-such as Host, Account, IP, URL-and then select the corresponding column from your query results. Mapping Computer to the Host entity type and TargetUserName to the Account entity type causes those values to appear as entities in alerts and incidents, enabling investigation graph visualization and UEBA enrichment. Alert grouping, custom details, or simply enabling UEBA do not create the required entity records unless the entity mapping step is completed.

Selecting the Request remediation action opens a remediation activity for the selected recommendation. When your Defender for Endpoint tenant is connected to Microsoft Intune, this action creates a security task in Intune that targets the devices listed in the recommendation. The Endpoint Protection team can then view the task in the Intune admin center, deploy the suggested update or configuration change, and mark the task as completed. Opening a service ticket or adding an exception does not generate an Intune task, and exporting data to CSV is only for reporting purposes.

When the automation level is set to "Semi - require approval for any remediation," Microsoft Defender for Endpoint pauses every remediation action and places it in a Pending state. However, activities that only collect evidence are not classed as remediation; they are executed automatically so the investigation can finish gathering the data it needs. Collecting an investigation package is therefore performed right away, whereas actions such as quarantining a file, removing a registry value, or isolating a device are remediation steps that stay Pending until an analyst approves or rejects them.

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 Frequency setting controls how often Defender XDR sends an email that summarizes all new vulnerabilities matching the rule criteria during the selected interval. Choosing Daily groups all matches into a single email every 24 hours, preventing multiple messages when several CVEs are published on the same day. Settings such as Severity, Device groups, or Exploitation status filter which vulnerabilities are included but do not affect how often emails are sent. The Send one email per alert option exists only in alert notification rules, not in vulnerability notification rules.

Security Copilot obtains data from products such as Microsoft Sentinel by using product-specific plugins (connectors). Granting the analysts the Microsoft Sentinel Reader role lets Security Copilot retrieve incident information from the Sentinel workspace on their behalf. Without at least Reader rights in Sentinel, requests sent from Security Copilot are denied, even if the users have the Security Copilot User role. Assigning the Azure OpenAI User role, adding data connectors in Sentinel, or granting Microsoft Graph permissions does not give Copilot the required workspace access to read incidents.

Each Threat analytics article contains an Exposure section that lists the devices in your environment affected by the threat or vulnerability. Selecting the View impacted devices link opens a filtered Devices list, which you can then export for further action. The other options either provide high-level insights (Summary), general security guidance (Mitigation), or external resources (References) and do not show a pivotable list of vulnerable endpoints.

Alert notification rules are designed to send email messages whenever an alert that meets the rule's criteria is generated. When creating the rule you can scope it to one or more device groups and set a minimum alert severity. Selecting the CriticalServers device group and setting the minimum severity to High guarantees that only High- and Critical-severity alerts originating from those devices trigger an email. Vulnerability notification rules focus on CVEs and exposure rather than alert events, incident notification rules have no device-group filter and could notify on unrelated resources, and a Sentinel hunting query is unnecessary overhead when Defender XDR already provides purpose-built alert notifications.

In the device timeline, the fastest way to isolate only registry change events is to use the built-in Advanced filters feature. Selecting Action type equals Registry value set (or Registry value deleted/created) and narrowing the Date range to the last 14 days immediately hides all other event categories such as file, network, or process events. Manually scrolling, exporting raw data, or running a Live Response session are unnecessary and more time-consuming for the stated goal.

Choosing Open file page from the Evidence tab opens the dedicated file entity page. This page automatically aggregates telemetry across your tenant, displaying organization prevalence, global prevalence, first-seen and last-seen timestamps, and a list of devices where the file was observed in the selected time range (by default, 30 days). The timeline or graph views, while useful, show relationships only within the current incident and do not summarize prevalence across the tenant. Running an advanced hunting query or switching to Microsoft Sentinel would also require additional manual work and may miss devices if the query scope or data source is incomplete. Therefore, opening the file page directly from the Evidence tab is the quickest built-in method to obtain the required prevalence details.

Microsoft Sentinel includes a native "Amazon Web Services S3" data connector that uses an AWS CloudFormation template to stream multiple security log types- including GuardDuty findings, VPC Flow Logs, CloudTrail, and AWS Security Hub findings- from the customer's AWS accounts to an Amazon S3 bucket and then to an Azure Event Hub or Log Analytics workspace. Enabling this single connector therefore ingests both GuardDuty and VPC Flow Logs without requiring a separate CEF agent or custom API integration. The other listed options either collect only Azure activity, require custom log creation, or rely on legacy agent-based CEF ingestion, which demands more configuration effort.

Only members of the Insider Risk Management Investigators role group can open and read the full content of files and emails referenced in insider risk alerts. Insider Risk Management Analysts can review alert metadata and user activity timelines but cannot see content. Compliance Data Administrators and eDiscovery Managers have capabilities in other Microsoft Purview areas but do not grant the specific permission required to preview insider risk evidence.

When you want a query in an Azure Monitor or Microsoft Sentinel workbook to run against the workspace the workbook is opened from, you do not hard-code the workspace name. Instead, you use the workspace() function without arguments. At run time the workbook engine replaces the empty workspace() call with the ID of the currently selected Log Analytics workspace, so the query always scopes itself correctly after the workbook is copied to or opened from another workspace.

Hard-coding a workspace name inside workspace('Contoso-Sentinel') would force the query to run against that specific workspace only. The workspaceGuid() and workspaces() functions require you to supply one or more explicit workspace identifiers, so they cannot adjust automatically.

The Microsoft Sentinel Automation Contributor role is designed for users who manage automation in Microsoft Sentinel. It lets them create, modify, enable, or disable automation rules and manage playbooks (because it includes the actions of the Logic App Operator role). The role purposely excludes permissions to read raw data in the Log Analytics workspace, change analytics rules, or assign Azure RBAC roles, satisfying the stated restrictions.

Microsoft Sentinel Contributor would allow management of analytics rules, which is disallowed.
Microsoft Sentinel Responder can update incidents but cannot modify automation rules or playbooks.
Logic App Contributor applies to Logic Apps but grants broader permissions than required and does not cover Sentinel automation rules.

Selecting "Group all alerts triggered by this rule into a single incident" causes Microsoft Sentinel to funnel every alert fired by the rule during the chosen grouping period into the same incident, regardless of which entities the individual alerts reference. The "group when selected entities match" option would still split incidents whenever the entities differ, and disabling alert grouping would create one incident per alert. Relying on the template's settings offers no assurance because the template may not use the required grouping configuration.

Only a Vulnerability notification rule is designed to trigger when software vulnerabilities (CVEs) are first discovered on devices that Microsoft Defender Vulnerability Management monitors. Alert notification rules are limited to detection alerts raised by Defender for Endpoint or other Defender workloads, not to vulnerability discoveries. Threat analytics notifications relate to published intelligence reports, and remediation progress rules track the status of remediation activities after a ticket is created. Therefore, the correct choice is the Vulnerability notification rule.

Automation levels control how Automated Investigation and Response (AIR) handles remediation.

• Full - remediate threats automatically allows Defender to take every recommended remediation action with no human intervention, satisfying the workstation requirement.
• Semi - require approval for all folders blocks every remediation action until an analyst approves it, which meets the server requirement for full approval.
  Other semi-automation levels (Require approval for non-temp folders or for core folders only) still permit some automatic actions, so they do not ensure that all server remediations are approved. Changing user roles, alert-severity thresholds, or attack-disruption settings does not directly control AIR behavior at the device-group level.