Free Practice Questions for Microsoft SC-200 Exam

 Internal threat: Modify the access policy settings for the key vault.

 External threat: Modify the Key Vault firewall s ettings.

For internal threats involving a potential compromise of Fabrikam’s own Azure AD applications, the most direct and least disruptive remediation is to modify the Key Vault access policies (or RBAC assignments, if RBAC for Key Vault data-plane is in use) to immediately remove or reduce the compromised service principal’s permissions (Get/List/Decrypt/Sign/Wrap). Microsoft guidance for Key Vault access emphasizes least privilege and promptly revoking credentials or app permissions when compromise i s suspected. Access policies (or data-plane RBAC) govern which identities can access secrets, keys, and certificates; adjusting these stops further data-plane actions by the compromised app. “Resource locks” protect against deletion or configuration change s at the management plane, but they do not remove a compromised identity’s ability to read or use vault objects, so they are not an appropriate first response for this scenario.

For external threats , Microsoft recommends hardening Key Vault firewall and networking : restrict public network access, allow only required IPs, use virtual network rules, and prefer private endpoints. Key Vault includes a built-in firewall for IP and VNet ACLs; tuning these controls reduces exposure to the public internet and blo cks unauthorized traffic. NSGs apply to IaaS subnets/nics and don’t directly secure the public Key Vault endpoint. Azure Firewall can add perimeter control, but it is not necessary for remediating a specific Key Vault Defender alert; the most effective and immediate remediation is tightening the Key Vault firewall settings to limit external access pathways.

 Table: DeviceFileEvents

 Aggregation function: count()

In Microsoft Defender XDR advanced hunting, data tables such as DeviceFileEvents , DeviceProcessEvents , and CloudAppEvents are used to investigate various types of activities. Since this query aims to investigate an issue related to file activity—specifically identifying when files have been accessed, modified, or created repeatedly—the correct data source table is DeviceFileEvents . This table contains information about file-level activities recorded by Defender for Endpoint sensors, including file path, file name, action type, and user account involved.

The KQL structure shown in the image follows standard hunting query syntax:

DeviceFileEvents

| where Timestamp > ago(2d)

| summarize activityCount = count() by FolderPath, FileName, ActionType, AccountDisplayName

| where activityCount > 5

Here’s why:

The where Timestamp > ago(2d) clause filters results from the last 2 days, a typi cal timeframe for immediate investigations.

The summarize operator groups events by FolderPath, FileName, ActionType, and AccountDisplayName, then uses count() to determine how many times each file was acted upon.

Finally, where activityCount > 5 filters t o show only unusually high-frequency activity, which might indicate suspicious or automated file manipulation.

Microsoft Defender XDR documentation highlights that DeviceFileEvents is the correct schema for file activity investigations, while DeviceProcess Events focuses on process creation and execution, and CloudAppEvents targets cloud application usage.

Thus, the verified and documented correct completions are:

Table: DeviceFileEvents

Aggregation function: count()

To remediate active attacks automatically once alerts or incidents are detected, Microsoft Sentinel uses playbooks , which are workflows built on Azure Logic Apps . These playbooks can execute remediation actions—such as isolating a machine, blocking an account, or triggering other security control chang es—without manual intervention. Microsoft’s documentation clearly states that “playbooks in Microsoft Sentinel are based on workflows built in Azure Logic Apps” and that they can “automate and orchestrate your threat response by using playbooks … run a pla ybook on-demand or automatically in response to specific alerts or incidents.”

When an analytics rule in Sentinel triggers an alert or incident, you can attach an automation rule which in turn invokes a playbook (i.e. a Logic Apps workflow) to perform the remediation steps. The automation rule defines the trigger conditions and calls the playbook action as part of its response actions.

Let us evaluate other options:

Azure Automation runbooks (Option A) are powerful for scripting in Azure (e.g., PowerShell o r Python) and can perform remediation tasks, but they are not the native mechanism within Sentinel for orchestrated, alert-driven response workflows.

Azure Functions (Option C) are serverless compute for custom code, but you would have to build and integra te orchestration logic manually; they are not the out-of-box SOAR component in Sentinel.

Azure Sentinel livestreams (Option D) is not a recognized remediation automation component—it is irrelevant in this context.

Therefore, the correct solution to remedia te active attacks (triggering automated actions in response to alerts/incidents with minimal manual effort) is to use Azure Logic Apps (via Sentinel playbooks) as the orchestration engine. Logic Apps are the documented foundation of Sentinel’s automation r esponse capabilities.

As outlined in Microsoft’s official Defender for Of fice 365 documentation, this service provides comprehensive protection against threats targeting Microsoft 365 collaboration tools—such as SharePoint Online , OneDrive for Business , and Microsoft Teams . The marketing team uses SharePoint Online for vendor c ollabora tion and has experienced incidents in which vendors uploaded malicious files. Microsoft Defender for Office 365 specifically addresses this scenario through features like Safe Attachments and Safe Links , which automatically scan uploaded or shared files for malware and block access to harmful content.

When a vendor uploads a file to SharePoint Online, Defender for Office 365 inspects the file in real time within a virtual sandbox environment before allowing users to open or share it. If malware is d etected, the system quarantines or removes the file and notifies administrators. These detection and remediation capabilities prevent infection propagation, protect sensitive marketing data, and maintain compliance with Contoso’s security posture.

By leveraging Defender for Office 365, Contoso’s marketing team can continue external collaboration safely, ensuring that all uploaded files are scanned and validated before internal access—thereby resolving their specific malware-related issue.

Threat intelligence indicator lists in Microsoft Defender support entities such as IP addresses, URLs/domains, and file hashes. Hosts (device names) and users are not valid TI indicator types to add from the Incident page. Therefore, from the entities given, only the IP address 175.45.176.99 can be added to the threat intelligence list.

To hunt for resource changes in an Azure subscription via Microsoft Sentinel, the correct telemetry sourc e is the AzureActivity table. Microsoft documents state that Azure Activity logs record control-plane operations against Azure resources (e.g., create/update/delete) and include fields such as OperationNameValue , ActivityStatusValue , Caller , ResourceId , an d EventSubmissionTimestamp . Filtering with OperationNameValue endswith " write " captures change operations (create/update), while ActivityStatusValue == " Succeeded " ensures only successful changes are counted. For time-series analysis over fixed intervals a nd to substitute missing data points with 0 , use the KQL make-series operator with the default=0 parameter. This operator builds per-principal daily series using on EventSubmissionTimestamp in range(ago(7d), now(), 1d) by Caller , and dcount(ResourceId) (or count() ) returns the number of resource changes each day per Microsoft Entra security principal. This aligns with Sentinel hunting best practices: use AzureActivity for subscription-level changes, filter to succeeded writes, and leverage make-series to pr oduce a 7-day daily series with zero-fill for gaps—minimizing false impressions caused by missing events.

Final KQL:

AzureActivity

| where OperationNameValue endswith " write "

| where ActivityStatusValue == " Succeeded "

| make-series dcount(ResourceId) default=0

on EventSubmissionTimestamp in range(ago(7d), now(), 1d)

by Caller

 First blank (create a stub table): datatable

 Second blank (union option): isfuzzy=true

In KQL for Microsoft Sentinel, a safe way to test whether a table exists across multiple workspaces (without throwing an error when it doesn’t) is to union a guaranteed single-row “stub” table with a query against the target table, and use union isfuzzy=true . The stu b is created with datatable , e.g., let mtable = datatable(isMissing:int) [1]; which always yields one row ( isMissing=1 ). The second branch queries the real table and, if it exists, emits a row with isMissing=0 . When the table is missing, that branch return s no rows, but because isfuzzy=true is used, the reference to a potentially missing table is treated as an empty input rather than an error. Finally, selecting a single row (e.g., | top 1 by isMissing asc ) ensures you return 0 if the table exists (preferre d), otherwise 1 from the stub.

A complete pattern for the answer area is:

let mtable = datatable(isMissing:int) [1];

union isfuzzy=true

mtable,

(AzureActivity | getschema | project isMissing=0)

| top 1 by isMissing asc

This meets the requirements: it checks existence per workspace, returns one row with isMissing=0 if the table exists, or one row with isMissing=1 if it does not, with minimal overhead and no failures when the table is absent.

In Microsoft Sentinel, data from applications, security solutions, and s ervices is ingested through data connectors . To integrate App1 with Sentinel and meet its monitoring or data ingestion requirements, you must configure a connector .

Microsoft Sentinel documentation specifies:

“Data connectors provide the integration point between Microsoft Sentinel and other data sources, including Microsoft services, third-party solutions, and custom applications.”

Connectors manage authentication, data formats, and continuous ingestion of logs or alerts into Sentinel’s Log Analytics works pace.

Other options:

API connection – supports Logic Apps but not direct Sentinel ingestion.

Trigger – used for playbooks or automation, not data ingestion.

Authorization – a setting used within connectors or playbooks, not configured separately.

✅ Correct configuration for App1: a connector

Explanation (concise ): In Azure Security Center / Microsoft Defender for Cloud , the correct workflow to see recommendations for resolving a specific alert is: open Security alerts , select the alert, choose Take action , and expand Mitigate the threat to view remediation guidance. This meets the stated goal.