Free SC-200 Practice Test Questions and Answers (2026)

The "Activity from infrequent country" anomaly detection policy is designed to identify when a user performs an activity from a country/region that has not been recently, or ever, visited by any user in the organization. The system establishes a baseline of normal activity based on the locations of all users. A sign-in from a location that is new to the entire organization triggers this specific alert, directly matching the requirement to be notified when a user signs in from a location never used by others in the organization.

A. Impossible travel: This policy detects when a single user signs in from two geographically distant locations in a time frame that is too short to physically travel between them.

B. Activity from anonymous IP addresses: This policy triggers an alert when a sign-in originates from an IP address associated with an anonymizing service like a VPN or the Tor network, regardless of the location's history.

D. Malware detection: This is not a standard anomaly detection policy name. The related policy, "Activity from suspicious IP addresses," detects sign-ins from IPs known to be malicious (e.g., botnets), not new locations.

1. Microsoft Learn. (2023). Anomaly detection policies in Microsoft Defender for Cloud Apps. "Activity from infrequent country" section. This document states

"This detection identifies when an activity is performed from a country/region that was not recently or never visited by any user in the organization."

2. Microsoft Learn. (2023). Anomaly detection policies in Microsoft Defender for Cloud Apps. "Impossible travel" section. This document states

"This detection identifies two user activities... originating from geographically distant locations in a time period shorter than the time it would have taken the user to travel..."

3. Microsoft Learn. (2023). Anomaly detection policies in Microsoft Defender for Cloud Apps. "Activity from anonymous IP addresses" section. This document states

"This detection identifies that users were active from an IP address that has been identified as an anonymous proxy IP address."

To identify Azure resources queried or modified by risky users, a KQL query must correlate user risk data with resource activity logs. The SigninLogs table from Microsoft Entra ID contains user sign-in details, including risk levels detected by Identity Protection (e.g., RiskLevelAggregated). The AzureActivity table contains the Azure Activity Log, which records management-plane operations on Azure resources. To link a risky user to an action, the query must join the UserPrincipalName from the SigninLogs table with the Caller field from the AzureActivity table, as the Caller field identifies the user who performed the operation.

1. Microsoft. (2023). Microsoft Sentinel data connectors. Microsoft Learn. Retrieved from https://learn.microsoft.com/en-us/azure/sentinel/data-connectors-reference.

Details: This document lists SigninLogs as the table for "Microsoft Entra sign-in logs" and AzureActivity as the table for "Azure Activity" logs

confirming the correct tables for the required data sources.

2. Microsoft. (2023). Azure Monitor Logs table reference / SigninLogs. Microsoft Learn. Retrieved from https://learn.microsoft.com/en-us/azure/azure-monitor/reference/tables/signinlogs.

Details: The schema documentation confirms that SigninLogs contains the UserPrincipalName and RiskLevelAggregated columns

which are essential for identifying risky users.

3. Microsoft. (2023). Azure Monitor Logs table reference / AzureActivity. Microsoft Learn. Retrieved from https://learn.microsoft.com/en-us/azure/azure-monitor/reference/tables/azureactivity.

Details: The schema documentation confirms that the AzureActivity table contains the Caller column

which "identifies the user or client that initiated the event." This is the correct field for joining with the user identity from SigninLogs.

4. Microsoft. (2024). join operator. Microsoft Learn. Retrieved from https://learn.microsoft.com/en-us/azure/data-explorer/kusto/query/join-operator.

Details: This official documentation explains how to use the join operator to merge rows of two tables to form a new table by matching values of the specified columns

which is the core operation required by the query.

Microsoft Sentinel workbooks are the designated feature for creating interactive visual reports and dashboards. They provide a flexible canvas to query data from various sources, including sign-in logs, and visualize that information using charts, graphs, and tables. This allows security analysts to monitor trends and create custom reports, directly addressing the requirement to visualize sign-in information over time.

B. a hunting query: This is used for proactively searching for security threats and anomalies, not for creating persistent, visual reports or dashboards.

C. a notebook: Notebooks are for advanced threat hunting, machine learning, and complex data analysis, which is more powerful than required for a standard visual report.

D. a playbook: This is an automated workflow (built on Azure Logic Apps) used to respond to security alerts and incidents, not for data visualization.

1. Microsoft Learn

"Visualize and monitor your data with workbooks in Microsoft Sentinel": In the "Introduction" section

it states

"Workbooks provide a flexible canvas for data analysis and the creation of rich visual reports within the Azure portal... They allow you to tap into the full power of other Azure services as well

such as Azure Monitor." This directly supports the use of workbooks for visualization.

2. Microsoft Learn

"Threat hunting in Microsoft Sentinel": The "Introduction" section clarifies the purpose of hunting: "Threat hunting is a proactive search for cyber threats that are lurking undetected in a network... In Microsoft Sentinel

hunting queries are built on top of Kusto Query Language (KQL)." This distinguishes hunting from reporting.

3. Microsoft Learn

"Automate threat response with playbooks in Microsoft Sentinel": The "Introduction" section defines playbooks: "A playbook is a collection of procedures that can be run from Microsoft Sentinel in response to an alert or incident... Playbooks are based on workflows built in Azure Logic Apps." This confirms their role in automation

not visualization.

4. Microsoft Learn

"Jupyter notebooks with Microsoft Sentinel hunting capabilities": The "When to use notebooks" section states

"Notebooks are best suited for more advanced users who need more control and flexibility in their threat hunting and investigation." This positions notebooks as a tool for advanced analysis rather than standard reporting.

<img src="https://kxbjsyuhceggsyvxdkof.supabase.co/storage/v1/object/public/file-images/SC-200/page_85_img_1.jpg">Reference: https://docs.microsoft.com/en-us/microsoft-365/security/defender/advanced-hunting-queryemails-devices?view=o365-worldwide

https://docs.microsoft.com/en-us/azure/security-center/quickstart-onboard-gcp

Step 1: From the Investigation blade, select Insights The Investigation Insights Workbook is designed to assist in investigations of Azure Sentinel Incidents or individual IP/Account/Host/URL entities. Step 2: From the Investigation blade, select the entity that represents VM1. The Investigation Insights workbook is broken up into 2 main sections, Incident Insights and Entity Insights. Incident Insights The Incident Insights gives the analyst a view of ongoing Sentinel Incidents and allows for quick access to their associated metadata including alerts and entity information. Entity Insights The Entity Insights allows the analyst to take entity data either from an incident or through manual entry and explore related information about that entity. This workbook presently provides view of the following entity types: IP Address Account Host URL Step 3: From the details pane of the incident, select Investigate. Choose a single incident and click View full details or Investigate.

https://github.com/Azure/Azure-Sentinel/wiki/Investigation-Insights---Overview https://docs.microsoft.com/en-us/azure/sentinel/investigate-cases

Questio n Part 1: Which types of files can you use for the custom lure? Answer: EXE, XLSX, and PDF According to your screenshot (File types drop-down), you can use the following file types for a custom lure in Microsoft Defender XDR deception rules: EXE XLSX PDF You can select any combination of these, so EXE, XLSX, and PDF are all supported as custom lure file types. Questio n Part 2: In which home directory should the file be located on a device? Answer: The Active Directory user When you set the Planting path to HOME in a deception rule, the file should be planted in the home directory of a user. According to the available drop-down options and Microsoft documentation, the typical recommended choice for corporate environments (and specifically for most deception scenarios) is "The Active Directory user". This ensures the lure is placed where the intended target (a domain user) is likely to encounter it.

The security bulletin identifies a specific image file as the attack vector. In Microsoft Defender for Endpoint, the most direct and precise method to identify and block a specific file is by using its unique hash (e.g., SHA-256, SHA-1, or MD5). Creating a file hash indicator of compromise (IoC) and setting the action to "Alert and block" instructs Defender for Endpoint to prevent the file from being read, written, or executed on any managed device. This action directly fulfills the requirement to prevent the attack.

A. A URL/domain indicator targets network addresses, not files. Additionally, the "Alert only" action would not prevent the attack; it would only generate a notification.

B. A URL/domain indicator is inappropriate because the threat is a specific file, not a website or network location.

D. A certificate indicator blocks all files signed with a specific certificate. This is less precise than a file hash and could cause unintended consequences by blocking legitimate files signed with the same certificate.

1. Microsoft Learn. (2023). Create indicators. Microsoft Defender for Endpoint.

Section: "File indicators"

Content: "You can create an indicator for a file hash. ... When you create an indicator for a file

you can choose from the following actions: Allow

Audit

Warn

Block and remediate

and Alert and block." The "Alert and block" action is described as preventing the file from being read

written

and executed. This directly supports using a file hash to block a malicious file.

2. Microsoft Learn. (2023). Create indicators. Microsoft Defender for Endpoint.

Section: "URL and domain indicators"

Content: "URL/domain indicators prevent users from accessing the URL/domain through the web browser." This confirms that URL/domain indicators are for network locations

not local files.

3. Microsoft Learn. (2023). Create indicators. Microsoft Defender for Endpoint.

Section: "Certificate indicators"

Content: "You can create indicators for certificates that will block files that are signed with the blocked certificate from being run in your organization." This shows that certificate indicators are for blocking based on the signer

which is a broader and less specific method than blocking a single file by its hash.

The provided code is a YAML manifest for a custom Microsoft Copilot for Security plugin. The purpose of a plugin is to extend Copilot's capabilities by enabling it to interact with external services and data sources. This interaction is accomplished by calling an Application Programming Interface (API). The variable within the functions section of the manifest must specify the exact API operation that Copilot will invoke. This target corresponds to an operationId defined in the plugin's accompanying OpenAPI specification file. Therefore, the format for the target is fundamentally an API call.

B. GPT: GPT (Generative Pre-trained Transformer) is the large language model that powers Copilot; it is not an external endpoint that a plugin function would target.

C. KQL: Kusto Query Language (KQL) is used to query data in services like Microsoft Sentinel. While a plugin's API might execute a KQL query, the target format itself is an API endpoint, not the query language.

D. SQL: SQL is a database query language. A plugin would interact with a database via an API endpoint; the target in the manifest would not be formatted as SQL.

1. Microsoft Learn. "Build your own plugins for Microsoft Copilot for Security." This document details the plugin development process

including the structure of the YAML manifest file. It shows that functions are of type: api and their target is an API operation. See the "Plugin manifest" section for a structural example.

2. Microsoft Learn. "OpenAPI specification for Microsoft Copilot for Security plugins." This source explains that the OpenAPI specification is required to describe the API that the plugin uses. The target in the manifest file directly references the operationId within this API specification. See the "OpenAPI specification requirements" section.

The principle of least privilege requires assigning the minimum permissions necessary to perform a task. The Security Admin role (User2) has sufficient permissions to manage security policies, view security states, and apply security configurations in Microsoft Defender for Cloud. This includes enabling Defender plans like Defender for Servers (Microsoft.Security/pricings/write permission) and remediating security recommendations, such as enabling vulnerability scans. The Security Reader role (User1) has read-only access and cannot make any configuration changes. The Owner (User3) and Contributor (User4) roles are overly permissive for these specific security tasks. Therefore, the Security Admin role is the correct choice for both tasks as it adheres to the principle of least privilege.

1. Microsoft Learn

"Permissions in Microsoft Defender for Cloud": This document outlines the roles and permissions for managing Defender for Cloud.

Under the "Roles and allowed actions" table

it specifies that Security Admin can "Edit security policy

apply recommendations". This covers enabling vulnerability scans. It also states

"To enable Defender for Cloud plans on a subscription

you must be assigned the role of Subscription Owner

Subscription Contributor

or Security Admin." This confirms Security Admin is the least-privileged role for enabling Defender for Servers.

2. Microsoft Learn

"Azure built-in roles - Security Admin": This page details the specific permissions for the Security Admin role.

The role includes the Microsoft.Security/ permission

which grants full control over security configurations within the Microsoft.Security resource provider

including enabling plans and configuring vulnerability assessments

without granting excessive permissions to manage other Azure resources.

3. Microsoft Learn

"Azure built-in roles - Security Reader": This page details the permissions for the Security Reader role.

The permissions listed are all read-only (e.g.

Microsoft.Security/policies/read

Microsoft.Security/pricings/read)

confirming that this role can view settings but cannot enable any features.

Azure Event Hubs is a big data streaming platform and event ingestion service, specifically designed to integrate Azure services with external solutions like third-party SIEMs. Microsoft Entra ID (which includes Microsoft Graph activity logs) has a built-in diagnostic setting to stream logs directly to an Event Hubs namespace. This provides a real-time, scalable, and standardized endpoint for SIEM tools to consume the log data. Most major SIEM vendors have pre-built connectors for Azure Event Hubs, making this the most direct and administratively simple method for the required integration.

B. an Azure Event Grid namespace: Azure Event Grid is a service for routing discrete events for reactive programming models, not for high-throughput, continuous log streaming required by a SIEM.

C. an Azure Storage account: This option is for long-term archival of logs. While a SIEM could ingest from storage, it is not a real-time stream and requires a more complex pull mechanism.

D. a Log Analytics workspace: This is the native data store for Azure Monitor and Microsoft Sentinel. Sending logs here to forward them to a third-party SIEM adds an unnecessary step and complexity.

1. Microsoft Entra documentation

"Stream Microsoft Entra logs to an Azure event hub": "Streaming your Microsoft Entra logs to an event hub allows you to integrate with third-party Security Information and Event Management (SIEM) tools

such as Splunk and QRadar. This integration allows you to combine Microsoft Entra activity log data with other data managed by your SIEM

to provide richer insights into your environment." (See the "Introduction" section).

2. Azure Monitor documentation

"Stream Azure monitoring data to an event hub for consumption by an external tool": "Azure Monitor provides a complete full stack monitoring solution for your applications and services in Azure... At the same time

you may also need to send monitoring data to other monitoring tools in your environment... The most common method to stream monitoring data to an external tool is to use Azure Event Hubs." (See the "Overview" section).

3. Azure Event Hubs documentation

"What is Azure Event Hubs?": "Azure Event Hubs is a big data streaming platform and event ingestion service. It can receive and process millions of events per second. Data sent to an event hub can be transformed and stored by using any real-time analytics provider or batching/storage adapters." (See the "Overview" section).

To meet the principle of least privilege, the security analyst requires two distinct sets of permissions. First, the analyst needs read-only access to the Microsoft 365 security center to view alerts and security information. The Azure AD Security Reader role is the most appropriate for this, as it grants global read-only access to security features without allowing any changes.

Second, to "approve and reject pending actions" specifically within Microsoft Defender for Endpoint, the analyst needs the Active remediation actions role. This is a granular permission within the Defender for Endpoint role-based access control (RBAC) settings that specifically allows taking response actions on devices, without granting broader administrative rights. This combination provides the exact permissions needed for the specified tasks.

A. the Compliance Data Administrator in Azure Active Directory (Azure AD): This role is focused on managing compliance features like data loss prevention and eDiscovery, not security operations or remediation actions in Defender for Endpoint.

C. the Security Administrator role in Azure Active Directory (Azure AD): This is a highly privileged role with broad read and write permissions across all Microsoft 365 security services. Assigning it would violate the principle of least privilege.

1. Microsoft Docs - Microsoft Defender for Endpoint - Create and manage roles for role-based access control. This document details the granular permissions available within Defender for Endpoint. Under the "Permissions" table

the "Active remediation actions" permission is described as allowing users to "Approve or dismiss pending remediation actions."

Reference: Microsoft Learn

"Create and manage roles for role-based access control

" Permissions table.

2. Microsoft Docs - Microsoft 365 Defender - Manage access to Microsoft 365 Defender with Azure Active Directory roles. This document outlines the Azure AD roles for accessing the security portal. It states

"The Security reader role has read-only access" and is "ideal for security analysts."

Reference: Microsoft Learn

"Manage access to Microsoft 365 Defender with Azure Active Directory roles

" section "Required permissions."

3. Microsoft Docs - Azure AD built-in roles. This document provides descriptions for all Azure AD roles. It confirms that Security Administrator has excessive permissions for this task

while Security Reader is limited to viewing information.

Reference: Microsoft Learn

"Azure AD built-in roles

" sections "Security Reader" and "Security Administrator."

https://kxbjsyuhceggsyvxdkof.supabase.co/storage/v1/object/public/file-images/SC-200/page_316_img_3.jpg Thank you for your visit.

The most appropriate and formal method to escalate an incident in Azure Sentinel to another administrator is by assigning it. Assigning an incident officially transfers ownership and responsibility for the investigation and remediation. This action updates the incident's Owner property, which is crucial for tracking, workflow management, and ensuring clear accountability. While you can share a link, assigning is the built-in, procedural mechanism for escalation within the Sentinel platform. The new owner will then be responsible for investigating the entire incident, including the eight specific alerts you identified.

A. Create a Microsoft incident creation rule: This is an automation setting used to automatically create incidents from Microsoft security service alerts; it is not used to manage or escalate existing incidents.

B. Share the incident URL: This is an informal way to notify someone. It does not formally transfer ownership or responsibility, making it difficult to track the escalation process.

C. Create a scheduled query rule: This is a type of analytics rule used to generate new alerts and incidents based on a KQL query, not for managing or escalating existing ones.

1. Microsoft Learn. (2023). Investigate incidents with Microsoft Sentinel.

Section: "Assigning incidents and changing status and severity"

Quote/Content: "Assign an incident to an owner to take responsibility for its remediation. You can also assign incidents to a group... When you assign an incident to an owner

the owner's name appears in the incident details in the Owner field." This document explicitly describes assigning an incident as the method for transferring responsibility.

2. Microsoft Learn. (2023). Automatically create incidents from Microsoft security alerts.

Section: "Introduction"

Quote/Content: "Microsoft Sentinel allows you to automatically create incidents each time an alert is triggered in a connected Microsoft security service." This confirms that incident creation rules are for generating new incidents

not managing existing ones.

3. Microsoft Learn. (2023). Create custom analytics rules to detect threats.

Section: "Rule settings in the Analytics rule wizard - General tab"

Quote/Content: "Scheduled query rules run queries on a schedule

looking for events that might indicate a threat." This shows that scheduled query rules are for threat detection and alert creation

not incident management.

https://kxbjsyuhceggsyvxdkof.supabase.co/storage/v1/object/public/file-images/SC-200/page_315_img_2.jpg

The proposed solution does not meet the goal because it circumvents the intended process established by the scenario. While manually installing the Log Analytics agent is a technically viable way to connect a non-Azure machine, the scenario specifies that auto-provisioning has been enabled in Microsoft Defender for Cloud.

For auto-provisioning to function for AWS virtual machines, the correct procedure is to first connect the AWS account to Defender for Cloud using the multi-cloud connector. This process leverages Azure Arc to onboard the AWS VMs, making them visible and manageable within Azure. Once the machines are Arc-enabled, the auto-provisioning feature can then automatically deploy the necessary agents and extensions, providing a scalable and integrated monitoring solution. The manual installation is a separate, less integrated approach.

A. Yes: This is incorrect. The solution ignores the context that auto-provisioning was enabled, which implies using the AWS connector and Azure Arc as the intended, scalable method for agent deployment, not a manual one-off installation.

1. Microsoft Documentation

Connect your AWS account to Microsoft Defender for Cloud. This document outlines the recommended procedure. It states

"We recommend that you use the auto-provisioning process to install the Azure Arc agent... When you've onboarded your AWS connectors

Defender for Cloud can auto-provision the Azure Arc agent to your AWS instances." This confirms that the intended path after enabling auto-provisioning is to use the connector

not a manual agent installation.

2. Microsoft Documentation

Plan your Defender for Servers deployment. In the section "Onboarding non-Azure machines

" the document lists "Azure Arc-enabled servers (recommended)" as the primary method for connecting on-premises and other cloud machines. This establishes the best practice that the proposed manual solution deviates from.

3. Microsoft Documentation

Auto-provisioning agents and extensions from Microsoft Defender for Cloud. This page clarifies that auto-provisioning applies to "Azure VMs" and "Azure Arc-enabled machines." This directly supports the reasoning that for auto-provisioning to work on AWS VMs

they must first be onboarded via Azure Arc.