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

Azure Monitor Logs keeps data in the hot/cold (interactive) tier for the number of days defined as the workspace retention period. The first 31 days are free; after that, standard retention charges apply. Data that ages out of the interactive tier can be moved automatically to the archive tier, where storage costs are much lower and data can be retained for up to 12 years. Archived data is still searchable by running asynchronous Search Jobs, which typically complete in minutes to hours-acceptable for infrequent investigations.

Setting the workspace retention to 30 days keeps the most frequently queried data in the interactive tier at standard cost, while enabling table-level archive for an additional 13 months meets the 14-month compliance requirement at a substantially lower cost than keeping all data in the interactive tier. Using Basic Logs cannot satisfy the 14-month requirement, and creating a second workspace introduces extra ingestion costs without providing any savings over archive storage.

In an AMA-based data collection rule, you can filter and transform incoming data before it is sent to the Log Analytics workspace. By adding a Kusto Query Language (KQL) transformation to the DCR, you can specify that only records from the Security channel whose EventID is 4624 or 4625 are forwarded. This prevents all other Security events from being ingested, reducing data volume and therefore cost.

The other choices do not meet the requirement:

• Mapping data to the CommonSecurityLog table is relevant to CEF/Syslog connectors, not Windows event logs collected by AMA.
• There is no built-in stream type called Microsoft-Sentinel-WindowsSecurityFiltered; stream names are predefined (for example, Microsoft-WindowsEvent).
• Sending the Security log to a Basic Log destination would still ingest every record from the channel and would not filter by Event ID.

Configure a table-level data retention policy that keeps Syslog records in the analytics (hot) tier for 180 days, then automatically moves them to the archive tier for an additional 215 days. This fulfills the 180-day interactive-query requirement while storing the remaining data in the lower-cost archive tier, where it can still be accessed later through a restore operation or a search job as needed. Basic Logs cannot meet the 180-day interactive requirement because they provide only 30 days of interactive querying (with up to 7-year access via search jobs). Exporting or deleting the data after 180 days would remove the ability to query it natively in Microsoft Sentinel. Therefore, combining 180 days of analytics-tier retention with an extra 215 days of archive retention is the most cost-effective compliant solution.

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.

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.

In PowerShell, Attack Surface Reduction rule states are represented by integers: 0 disables the rule, 1 blocks the behavior, 2 enables Audit mode (events are logged but actions are not blocked), and 6 enables Warn mode (a user prompt appears). Because you want the rule to log activity without blocking it, you must set the rule state to 2. The other values would either disable the rule, actively block the behavior, or prompt users.

Microsoft Sentinel includes a built-in analytics rule template named Ingestion volume anomalies. When enabled, the rule automatically learns normal ingestion patterns for each table and generates an incident if the current volume sharply exceeds the historical baseline. A daily cap limits cost but produces no alert, the Usage and estimated costs workbook is only for interactive review, and the Entity behavior analytics template focuses on user and host behavior rather than ingestion metrics.

A Vulnerability notification rule is the only rule type that can monitor new CVEs reported by Microsoft Defender Vulnerability Management. When you create the rule, you can specify both the Severity filter (set to Critical) and the Device group filter (set to the built-in Default group). Alert notification rules cover security alerts, not CVE discoveries, while automated investigation exclusions and data-retention policies do not generate vulnerability emails. Therefore, selecting Vulnerability notification and configuring the two filters meets every requirement.

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.

Azure AD sign-in events are stored under the Microsoft Graph auditLogs namespace. Interactive sign-ins can be retrieved by calling /auditLogs/signIns and filtering with the user's object ID (userId) together with a createdDateTime range. The other listed endpoints surface security alerts, risk detections, or Microsoft 365 activity data-none of which return the raw sign-in log entries needed for authentication investigations.

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.

When device discovery is enabled and left in its default Basic mode, the SenseNDR component on each onboarded Windows device passively captures local network traffic such as ARP, DHCP, DNS, and NetBIOS broadcasts. From this broadcast traffic it infers the presence of other hosts on the same subnet. Any host that appears in the traffic but does not report itself to the MDE service is added to the device inventory as an unmanaged device. Basic mode never initiates active ICMP ping sweeps or TCP port scans. Those active probes are performed only when an administrator explicitly switches discovery to Standard mode. No additional agents such as Azure Arc are required for either mode because the existing Defender for Endpoint sensor performs the discovery work.

Microsoft Defender XDR only exposes device-level automated response actions, such as Isolate device, when the custom detection rule's query returns a unique device identifier. The required identifier is the DeviceId column. Without DeviceId in the query results, Defender XDR cannot determine which specific endpoint should be isolated, and the action remains unavailable. Other columns such as ReportId, AccountSid, or FileContent do not uniquely map to a managed device and therefore cannot enable the isolation action.

Microsoft Sentinel includes a built-in "Azure Policy" data connector that relies on Azure diagnostic settings rather than on the Log Analytics agent. Enabling this connector automatically creates or updates a diagnostic setting named "send-to-sentinel" in each selected subscription and starts streaming policy compliance records (PolicyInsights) to the workspace. Using the Azure Activity connector alone will not capture detailed compliance evaluation results, and creating custom data collection rules or assigning extra roles is unnecessary for this scenario.

Because the file is already stored and analyzed in Microsoft Defender for Endpoint, the quickest way to obtain a full security picture is to open the file page in the Microsoft Defender portal. That page aggregates static analysis, detonation results, prevalence, associated incidents, alert history, device exposure, and other telemetry. Reviewing this rich information first gives Security Copilot maximum context when you reference the file in a prompt. Uploading the file again, pasting a single command, or building a playbook are unnecessary extra steps and provide less immediate insight.

The Usage table records detailed information about data ingested into a Log Analytics workspace, including the Quantity (in MB) and whether each record is billable (IsBillable). By querying the Usage table and summarizing Quantity by the DataType column, you can see exactly how much billable data each table contributed during any period, such as the last 24 hours. Other tables like AzureDiagnostics, AzureActivity, and Heartbeat store specific operational or activity logs but do not track ingestion volume or billable size for every table, so they cannot be used to calculate per-table ingestion costs.

When a device matches more than one Microsoft Defender for Endpoint (MDE) device group, the group with the highest priority (that is, the lowest numeric rank value) takes precedence. Because SensitiveGroup has a rank of 10, it outranks FinanceGroup, which has a rank of 100. Therefore, MDE will apply the automation level configured for SensitiveGroup (Semi-automated) to the device. The platform does not choose the most or least restrictive setting, nor does creation time affect precedence-only the rank value determines which group wins.

Selecting Take action > Ban app on the OAuth Apps page both revokes all existing user and service principal grants and blocks any future consent to the application, immediately stopping the app from accessing Microsoft 365 data. Revoke app only removes current grants, allowing users to re-consent, while marking the app as unsanctioned or starting an access review does not revoke tokens or prevent future consent.

Hunting queries run on-demand unless you convert them to analytics rules. By choosing Create detection rule, Microsoft Sentinel copies the query into the analytics rule wizard, where you can set a schedule (for example, every hour) and an alert threshold (results greater than or equal to 1). When the rule runs it can automatically generate incidents. Live stream only shows near-real-time results and does not create incidents, workbooks do not run queries on a schedule, and a Logic App playbook would require additional custom logic and is not the recommended method for routine scheduled detections.

ASIM provides parser functions that return normalized data across multiple source tables. The imProcessEvents() function (also written as _Im_ProcessEvents()) surfaces process creation events that conform to the ASIM Process schema, regardless of whether the data originated from Windows Security events, Microsoft Defender for Endpoint, or other sources. Calling this parser at the beginning of the query abstracts away the underlying table names. The other functions either target different event types (DNS or network), return all events in ASIM, or represent a table rather than an ASIM parser, so they would not specifically return only process events while remaining source-agnostic.