SC-200 Questions and Answers

In Microsoft Defender for Identity (MDI), data collected from Active Directory Domain Services (AD DS) is stored in Microsoft 365 Defender advanced hunting tables under the Identity schema.

When investigating LDAP or authentication activities related to domain controllers, the correct table is IdentityLogonEvents.

The IdentityLogonEvents table contains information about all logons detected by Defender for Identity sensors on domain controllers — including LDAP binds, Kerberos, NTLM, and other authentication types.

You can identify LDAP simple binds using a query such as:

IdentityLogonEvents

| where Protocol == "LDAP"

| where AuthenticationPackage == "SimpleBind"

Other options explained:

AADServicePrincipalRiskEvents – Contains Entra (Azure AD) service principal risk detections, not AD DS activity.

AADDomainServicesAccountLogon – Used for Azure AD Domain Services (AAD DS), not traditional on-prem AD DS.

SigninLogs – Contains Entra (Azure AD) sign-in data, not LDAP or on-prem authentication.

✅ Correct table: IdentityLogonEvents

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.

In Microsoft Defender for Cloud (formerly Azure Security Center), workflow automation allows you to automatically respond to security alerts and recommendations by triggering remediation actions.

When you create an Azure Policy to enforce automatic remediation based on Defender alerts or recommendations, the effect determines what the policy does when a resource is found noncompliant:

DeployIfNotExists is the correct effect to use for automatic remediation. This effect automatically deploys a remediation task (such as a Logic App or other automation) when a matching noncompliant resource is detected. It’s commonly used in Defender for Cloud to deploy missing security configurations or initiate an automated remediation workflow.

Append only adds metadata or parameters to resources—it does not enforce or deploy remediation actions.

EnforceRegoPolicy is used for container compliance with Gatekeeper policies (Kubernetes), not for Defender workflows.

For the automation mechanism:

An Azure Logic Apps app with the trigger “When an Azure Security Center alert is created or triggered” is the correct choice. This Logic App acts as the workflow automation engine that runs whenever a new alert is raised. It can perform actions such as isolating VMs, disabling users, or notifying SOC teams.

Using a trigger for “When a response to an Azure Security Center alert is triggered” would only activate after a manual response, not automatically.

Automation runbooks with webhooks can be used for custom automation, but Defender workflow automation integrates natively with Logic Apps and not directly with runbooks.

✅ Final Answer:

Set available effects to: DeployIfNotExists

To perform remediation use: An Azure Logic Apps app that has the trigger set to When an Azure Security Center Alert is created or triggered

Automated Investigation and Response (AIR) automates investigation and remediation actions for alerts that Defender already detects: it triages alerts, runs investigation playbooks, and can execute remediation (quarantine files, terminate processes, remove persistence) based on the investigation outcome. AIR is powerful for reducing analyst load and quickly remediating detected threats. However, AIR only runs in response to detections/alerts it receives—if the third-party AV completely misses an artifact and no EDR/behavioral detection generates an alert, AIR will not be triggered. In contrast, EDR in block mode is specifically built to catch post-breach detections that the primary AV missed and to remediate them. Therefore, enabling AIR alone does not guarantee protection from artifacts missed by the third-party antivirus; AIR helps remediate once a detection exists but does not itself create the missed detection coverage that EDR in block mode provides.

To find all security principals (users or service principals/apps) that changed or deleted groups, you should query MicrosoftGraphActivityLogs and filter for requests targeting the groups endpoint, then exclude read-only operations. The RequestUri field contains the full Graph URL that the principal called (e.g., /v1.0/groups/{id}), so filtering where RequestUri contains "/group" (or "/groups") isolates group-related operations. Changes and deletions are non-read HTTP verbs such as POST, PATCH, PUT, and DELETE. The simplest way to capture all of them is to exclude reads: where RequestMethod != "GET". Finally, projecting AppId, UserId, and ServicePrincipalId returns the identities (user or app) behind each request, which are the “security principals” you need to report.

So the completed KQL is:

MicrosoftGraphActivityLogs

| where RequestUri contains "/group"

| where RequestMethod != "GET"

| project AppId, UserId, ServicePrincipalId

1️⃣ Connect-IPPSSession

2️⃣ New-ComplianceSearch

3️⃣ Start-ComplianceSearch

In Microsoft 365 E5 (which includes Microsoft Purview and Exchange Online), to identify phishing email messages using PowerShell, administrators can perform a compliance content search. The process requires connecting to the Microsoft Purview (Security & Compliance Center) PowerShell and then creating and running a compliance search.

Here’s the correct order and purpose of each cmdlet:

1️⃣ Connect-IPPSSession

This cmdlet establishes a remote PowerShell session to the Microsoft Purview Compliance Center (formerly Security & Compliance Center).

It’s required before executing any compliance-related PowerShell commands such as creating or starting a search.

Example:

Connect-IPPSSession

2️⃣ New-ComplianceSearch

After connecting, use this cmdlet to create a new compliance content search.

You can define parameters such as the search name, target locations (e.g., all mailboxes or specific users), and search query (for example, filtering by suspected phishing keywords or sender domains).

Example:

New-ComplianceSearch -Name "PhishingSearch" -ExchangeLocation All -ContentMatchQuery 'Subject:"phish" OR Subject:"urgent action required"'

3️⃣ Start-ComplianceSearch

Once the search is defined, this cmdlet initiates the compliance search to scan the selected mailboxes for phishing-related messages.

Example:

Start-ComplianceSearch -Identity "PhishingSearch"

Other cmdlets explained:

Connect-ExchangeOnline is used for managing Exchange Online configuration, not compliance or content searches.

Search-UnifiedAuditLog searches the unified audit log, which is used for activity auditing, not email content searches.

✅ Final Correct Sequence:

Connect-IPPSSession

New-ComplianceSearch

Start-ComplianceSearch

In Microsoft Defender for Endpoint, an Investigation (also known as an Automated Investigation and Response – AIR) collects evidence related to alerts, analyzes device behavior, and enables response actions such as device isolation, file quarantine, or remediation.

While Incidents aggregate multiple alerts for a single attack chain, and Advanced hunting is used for custom KQL queries, Investigations are specifically designed to automate evidence collection and analysis for triggered malware alerts.

From the investigation results, analysts can then initiate isolation of affected endpoints directly in the portal.

✅ Answer: B. Investigations

A hunting bookmark is a manual tagging mechanism used during threat hunting to mark interesting results from ad hoc queries. Bookmarks do not automatically create incidents or run on a schedule. They are used for investigation documentation, not alerting. Therefore, using a hunting bookmark does not meet the requirement to automatically generate incidents when a malicious sign-in is detected.

Yes No Yes

According to Microsoft Copilot for Security and Defender for Cloud (Azure Firewall) integration guidance, Copilot can retrieve information from connected security data sources such as Log Analytics, Microsoft Sentinel, and Defender XDR. To access data via Copilot prompts, two conditions must be satisfied:

The user must have the appropriate Copilot role (Owner or Contributor).

The user must have the necessary Azure permissions (RBAC) to access the underlying data source or workspace (e.g., Log Analytics, Sentinel, or Azure Firewall logs).

User1 – Has the Contributor role at the subscription level, meaning full access to all resource groups and Log Analytics workspaces. As a Copilot Owner, User1 can query Copilot and retrieve data from AFW1 logs (which are in Log Analytics). Hence, Yes.

User2 – Also has Contributor rights at the subscription level but is only a Copilot Contributor. A Copilot Contributor can collaborate in sessions but cannot initiate or run data retrieval prompts independently. Therefore, No for AFW2.

User3 – Has the Security Reader role at the resource group level, providing read access to security data for that group, and is a Copilot Owner, enabling prompt access to connected security sources. Since AFW3 logs are in Log Analytics within the same resource group, User3 can retrieve data using Copilot. Thus, Yes.

Therefore, the correct answers are:

User1 → Yes

User2 → No

User3 → Yes

 File1.exe will be blocked on Device3. — No

 User2 will be marked with a risk level of medium. — No

 An investigation package will be collected from Device1. — Yes

Custom detection rules in Microsoft Defender XDR are scoped to devices or device groups and only take device-related actions for devices that are in that scope. As the documentation states, “Only data from devices in the scope will be queried. Also, actions are taken only on those devices.” Therefore a rule scoped to DevGroup1 will apply actions only to devices in DevGroup1 (Device1 and Device2); it will not apply to Device3 because Device3 is in DevGroup2. Microsoft Learn

File blocking is a file-level action triggered by the rule, but blocking is applied only where the rule is in scope. Consequently File1.exe will not be blocked on Device3 (out of scope). For the user action, the rule’s Mark user as compromised action explicitly “sets the users risk level to 'high' in Microsoft Entra ID” — it does not set a medium risk. So the statement that User2 will be marked with risk level medium is incorrect; the documented outcome is a high risk marking. Microsoft Learn

Finally, device actions include Collect investigation package and these are applied to the DeviceId results when the rule matches. Because Device1 is in DevGroup1 (in scope) and the rule specifies collecting an investigation package for matching devices, an investigation package will be collected from Device1 when the rule fires. Microsoft Learn

Sources: Official Microsoft Defender XDR documentation for custom detection rules (actions, scope, and user actions). Microsoft Learn

To ingest custom logs from on-premises servers into Microsoft Sentinel, the logs must first be collected through the Log Analytics workspace that Sentinel is built on. According to Microsoft Sentinel and Azure Monitor documentation, the required steps are:

Install the Log Analytics agent (MMA/OMS agent) on each on-premises Windows Server that will send logs.

This agent securely forwards Windows event logs, performance data, and custom log files to the Log Analytics workspace in Azure Monitor.

Although Azure Monitor Agent (AMA) is the newer option, custom log collection is still supported primarily via the Log Analytics agent until full parity is achieved.

The Microsoft Dependency agent is used only for service map and dependency data, not for log ingestion.

The Azure Connected Machine agent (for Azure Arc) can onboard machines for management but does not directly handle custom log configuration for Sentinel.

Configure custom log ingestion by defining custom log collection rules in the Log Analytics workspace settings.

In Sentinel, navigate to the underlying workspace → Advanced settings → Data → Custom Logs to define the log format, file path, and collection parameters.

The custom log configuration is always managed at the workspace level, since Sentinel queries data from the connected workspace’s tables.

Other options, like the Data connectors page or Logs blade of Sentinel, are used for connecting integrated services or for querying data, not for defining custom ingestion sources.

Therefore, based on official Microsoft Defender XDR and Sentinel integration guidance, the correct configuration steps are:

✅ On the servers, install the: Log Analytics agent

✅ Configure custom log settings by using the: Log Analytics workspace settings of Microsoft Sentinel

To use the Fusion rule to detect multi-staged attacks that include suspicious sign-ins to contoso.com followed by anomalous Microsoft Office 365 activity, you should perform the following two actions:

Create an Azure AD Identity Protection connector. This will allow you to monitor suspicious activities in your Azure AD tenant and detect malicious sign-ins.

Create a custom rule based on the Office 365 connector templates. This will allow you to monitor and detect anomalous activities in the Microsoft 365 subscription. Reference: https://docs.microsoft.com/en-us/azure/sentinel/fusion-rules

In Microsoft Sentinel, Microsoft incident creation rules are used to automatically create incidents from alerts generated by connected Microsoft security products (like Microsoft Defender XDR, Defender for Endpoint, or Defender for Cloud Apps). However, these rules do not detect malicious IP activity on their own. They simply define how and when alerts from Microsoft security connectors should be grouped or converted into incidents.

To meet the goal — “create an incident when a sign-in to an Azure virtual machine from a malicious IP address is detected” — you must use an analytics rule (scheduled query) or a Fusion rule that actively correlates sign-in logs with threat intelligence data (malicious IPs). Analytics rules in Sentinel run KQL queries that can match sign-in activity (from Azure Activity or SigninLogs) with known malicious IP lists, and they can automatically generate incidents when matches occur.

Therefore, creating a Microsoft incident creation rule for a data connector does not meet the requirement, since it cannot detect or correlate malicious sign-in activity itself.

Hence, the correct answer is B. No.

Microsoft 365 Copilot for Security uses Security Compute Units (SCUs) to determine available processing capacity for AI-driven operations. Each SCU represents a fixed amount of compute resources for handling Copilot for Security prompts and plugin interactions (like Sentinel).

When a notification appears stating that “SCU usage is nearing the provisioned capacity limit,” it means that the organization’s current SCU allocation is insufficient for ongoing demand. To restore full response functionality, the tenant admin (or authorized role) must increase the number of provisioned SCUs.

Microsoft documentation states:

“If Copilot for Security indicates that requests cannot be processed due to SCU capacity, increase your provisioned SCUs in the Microsoft 365 admin center or Azure portal to meet demand.”

The other options do not resolve the issue:

Opening a second session does not add capacity.

Waiting does not guarantee SCU availability.

The Optimization Workbook relates to Sentinel performance, not Copilot SCU allocation.

✅ Answer: D. Update the provisioned SCUs

When dealing with frequent false positives in Microsoft Defender for Endpoint alerts, such as those triggered by legitimate Office macros, the best practice is to hide false alerts while maintaining overall protection.

Microsoft Defender documentation prescribes the following approach:

Generate the alert (E): The alert must first appear in the queue so it can be reviewed and correctly classified.

Hide the alert (B): Analysts can hide individual alerts to clean up the queue without disabling detections or reducing coverage.

Create a suppression rule scoped to a device group (D): To prevent recurrence, suppression rules should be scoped narrowly (such as to a device group like the accounting team’s devices), maintaining the principle of least privilege and minimal impact.

Options A (Resolve automatically) and C (Suppress any device) would reduce visibility or broaden suppression excessively, potentially missing real threats.

This combination of actions aligns with Defender XDR’s alert management best practices, ensuring a balance between reducing noise and preserving security posture.

Just-In-Time (JIT) VM access in Microsoft Defender for Cloud controls inbound traffic to virtual machines, reducing exposure to attacks. Microsoft’s guidance allows JIT policies to be centrally configured and applied automatically across a resource group using Azure Policy, which provides the lowest administrative overhead.

To meet the requirements:

Limit request time to two hours: Defender for Cloud JIT policy allows defining a maximum allowed access duration per request.

Limit protocol to RDP only: The JIT configuration can restrict the protocol and port (TCP/3389 for RDP).

Minimize administrative effort: Azure Policy can automatically enforce this configuration for all VMs in RG1 without manually setting up each VM.

Other options are less suitable:

A. PIM controls user privileges, not network access.

C. Azure Front Door handles web application traffic.

D. Azure Bastion provides secure RDP/SSH via portal but doesn’t manage just-in-time network policies.

✅ Correct Answer: B. Azure Policy

To create a playbook in Microsoft Sentinel, you must first create an Azure Logic App.

Playbooks in Sentinel are built on top of Logic Apps—they define automated workflows that can be triggered by alerts or incidents. Once the Logic App exists, you can connect it to Sentinel via an automation rule or directly from an analytic rule.

A (Azure Function trigger): Used for custom code execution, not for Sentinel automation.

C (Hunting query): Used for threat hunting, not automation.

D (Automation rule): Connects an alert to a playbook but can’t exist before a playbook (Logic App) is created.

✅ Answer: B. an Azure Logic App

 To the AD DS domain controllers, deploy: Microsoft Defender for Identity sensors

 For Sentinel1, configure: The Security Events data source

To enable User and Entity Behavior Analytics (UEBA) in Microsoft Sentinel using data from on-premises Active Directory Domain Services (AD DS), you must collect detailed identity and authentication events. This requires integration with Microsoft Defender for Identity (MDI) — the native tool designed to monitor domain controller traffic and send identity telemetry to Microsoft Sentinel.

According to Microsoft documentation:

“To collect signals from your on-premises Active Directory domain controllers, install Microsoft Defender for Identity sensors directly on each domain controller or on a dedicated server.”

These sensors capture Windows event logs and network authentication data (Kerberos, NTLM, LDAP) and send the information securely to Defender for Identity cloud service.

The Azure Connected Machine agent and Azure Monitor agent do not provide the specialized identity telemetry required by UEBA. Therefore, the correct deployment is the Microsoft Defender for Identity sensors.

After integrating Defender for Identity, you must connect the right data source in Microsoft Sentinel.

The Security Events data source ingests domain controller event logs (such as sign-ins, account management, and group membership changes) that UEBA relies on for behavioral baselines and anomaly detection.

Microsoft Sentinel UEBA documentation confirms:

“UEBA uses data from identity-related data sources, such as SecurityEvents and Azure Active Directory sign-ins, to build user and entity profiles and detect anomalies.”

The Audit Logs and Signin Logs tables are specific to Azure AD and cloud identity events — not on-premises AD DS domain controllers.

✅ Final Configuration:

Deploy Microsoft Defender for Identity sensors to the domain controllers.

Configure The Security Events data source for Sentinel1.

Box 1: Owner

Only the Owner can assign initiatives.

Box 2: Contributor

Only the Contributor or the Owner can apply security recommendations.

In Microsoft 365 Defender, Advanced Hunting is the dedicated feature for creating and managing custom Kusto Query Language (KQL) queries used to proactively detect threats, investigate suspicious activity, and track ongoing risks across Microsoft 365 services (including Defender for Endpoint, Defender for Identity, Defender for Cloud Apps, and Defender for Office 365).

A custom tracked query is a saved hunting query that continuously assesses your environment’s threat status over time. According to Microsoft documentation, you create, edit, and manage these queries under the “Advanced Hunting” page in the Microsoft 365 Defender portal. The tracked queries appear under the “Custom detection rules” or “Tracked queries” tabs within this section, depending on their purpose.

Here’s how it works:

Navigate to Microsoft 365 Defender portal → Hunting → Advanced Hunting.

Use KQL to define your custom query that identifies specific threat patterns or anomalies.

Save it as a tracked query, allowing Microsoft 365 Defender to run it regularly and surface ongoing results in the hunting dashboard.

Other options are not correct:

Policies & rules – used for configuration of alerting and security policies, not ad-hoc or proactive hunting.

Explorer – provides real-time investigation of emails and threats but doesn’t support custom KQL queries.

Threat analytics – offers intelligence-driven insights and reports but doesn’t allow creating custom queries.

✅ Correct Answer: D. Advanced Hunting

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

 External threat: Modify the Key Vault firewall settings.

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 is 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 changes 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 blocks 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.

In Microsoft Sentinel (built on Azure Monitor Logs), analytics and hunting queries are executed within a Log Analytics workspace. To run Sentinel queries for Fabrikam, the tenant must have at least one workspace (with Sentinel enabled) in its subscription to host rules, incidents, hunting queries, and workbooks. Sentinel’s cross-workspace/tenant capability is provided by cross-resource queries in Kusto Query Language (KQL). The key construct for reaching outside the current workspace is the workspace() function, which lets you reference another Log Analytics workspace by name or resource ID—even across subscriptions or tenants when proper permissions (often via Azure Lighthouse or guest access) are in place.

Typical correlation looks like:

union workspace('Fabrikam-WS').SecurityEvent, workspace('Contoso-WS').SecurityEvent | …

Here, workspace() is the required element to bring together data sets from multiple tenants; operators like extend and project only shape columns and do not establish cross-tenant scope. Therefore, to meet the requirements with minimal overhead: Fabrikam needs one workspace to host its Sentinel content, and you use workspace() in your KQL to correlate Contoso and Fabrikam data.

The Defender for Cloud requirement states:

“The members of Group1 must be able to enable Defender for Cloud plans and apply regulatory compliance initiatives.”

According to Microsoft Defender for Cloud’s RBAC documentation, the Security Assessment Contributor role provides permissions to:

Enable and configure Defender plans,

Manage security policies and initiatives,

View and edit recommendations and compliance results.

This role gives enough permissions to perform Defender configuration tasks but follows the principle of least privilege, unlike broader roles like Owner or Contributor, which grant excessive rights.

✅ Answer for Question 9: C. Security Assessment Contributor

Microsoft Sentinel playbooks can be triggered by different types of events—alerts, incidents, or entities. Since the requirement specifies “incidents generated by rulequery1” and asks for automatic processing of those incidents, the correct approach is to use a playbook with an incident trigger.

According to Microsoft Sentinel automation documentation:

“When you want automation to start after an incident is created or updated, use the incident trigger. This allows you to automate workflows such as closing incidents, adding comments, or sending notifications.”

This trigger type works with automation rules that specify when and how to execute playbooks based on incident state or severity. Using a playbook with an incident trigger meets the need for post-incident automation (e.g., auto-closing incidents if they match certain conditions).

✅ Answer for Question 8: A. a playbook with an incident trigger

The requirement is to enable Microsoft Defender for Servers Plan 2 on all Azure VMs while excluding Server2 from agentless scanning. Defender for Cloud provides a built-in mechanism to exclude specific machines from agentless scanning based on resource tags. The process is: assign a distinct tag name:value to the VM you want to exclude (Server2), and then, in Defender for Cloud’s Agentless scanning for machines settings, specify that tag pair under exclusions. Defender’s continuous discovery honors these exclusions and skips any VM that matches the configured tag. This approach aligns with the business requirement of least privilege and minimal administrative effort: it avoids broad configuration changes, requires no extensions on the VM, and is reversible by simply removing or changing the tag. The Microsoft Antimalware extension and Automanage configuration are unrelated to agentless scanning behavior, and a resource lock would only prevent modifications/deletions, not scanning. Therefore, to meet the Defender for Cloud requirement precisely, configure an Azure resource tag on Server2 and reference that tag in the agentless scanning exclusion settings.

The Sentinel requirement states:

“Ensure that multiple alerts generated by rulequery1 in response to a single user launching Azure Cloud Shell multiple times are consolidated as a single incident.”

This behavior is controlled by the event grouping setting in the analytics rule configuration.

Microsoft Sentinel documentation explains:

“Event grouping determines how alerts generated from the same rule are grouped into incidents. Selecting ‘Group all alerts triggered by this rule into a single incident’ allows all related alerts to be combined.”

Hence, configuring event grouping ensures that all alerts from rulequery1 related to the same user are consolidated into one incident, satisfying the requirement.

✅ Answer for Question 10: C. event grouping

To have a Microsoft Sentinel workbook pull live data from an external web service, you use the workbook’s built-in JSON data source. Workbooks can query REST endpoints that return JSON and render results dynamically in visuals. Because the Azure portal (where the workbook runs) is a different origin than your on-prem/public Webapp1, browsers will block these cross-origin requests unless the endpoint explicitly allows them. Therefore, the external service must enable CORS to permit the portal’s origin to fetch the JSON. This aligns with Microsoft guidance that Workbooks can query HTTP/HTTPS JSON endpoints and that external endpoints must allow cross-origin requests for client-side calls from the Azure portal. Enforcing CORS on Webapp1 satisfies the security model while enabling the workbook to retrieve data at view time—meeting the requirement to “dynamically retrieve data from Webapp1.” Options like “custom endpoint” or “custom resource provider” aren’t needed here, and enabling SOP or only enforcing TLS 1.2 wouldn’t address the browser’s cross-origin policy blocking the call.

To monitor Windows Security events from Server1 using the Windows Security Events via AMA connector, the first object you must create is a Data Collection Rule (DCR). With the Azure Monitor Agent (AMA) model used by Microsoft Sentinel, data flow is controlled by DCRs, not by the legacy MMA/OMS workspace settings. A DCR defines what to collect (e.g., the Security event log, specific event IDs or XPath queries), from where (the target machines or machine groups), and where to send it (the Sentinel/Log Analytics workspace). After creating the DCR, you associate it with Server1 (Arc-enabled), and the connector will begin streaming Security events to your Sentinel workspace. Creating a Sentinel scheduled rule or an automation rule does not enable collection; those features act after data is already ingested. Event Grid topics are unrelated to Windows event collection. Therefore, the correct first step for meeting the Sentinel requirement to monitor Server1’s Security log via AMA is to create a DCR, then assign it to Server1 and the Sentinel workspace.

The problem described in the case study states that “Cloud App Security frequently generates false positive alerts when users connect to both offices simultaneously.” This behavior is commonly associated with the “Impossible travel” anomaly detection policy in Microsoft Defender for Cloud Apps.

According to Microsoft documentation, the “Impossible travel” policy detects when a user signs in from two locations that are geographically distant within an unrealistic timeframe. However, in multi-office environments (such as Boston and Seattle) or when VPN connections are used, this policy can frequently trigger false positives, since it may misinterpret legitimate connections as anomalous.

Microsoft recommends adjusting the impossible travel detection policy to account for trusted IP ranges, known locations, or VPN endpoints to reduce false alerts. Specifically, administrators can modify the policy’s sensitivity, include the organization’s office IP addresses as trusted, and exclude known network ranges.

This approach directly aligns with the case study’s scenario and satisfies the Defender for Cloud Apps requirement to reduce false positives while maintaining user anomaly detection accuracy.

✅ Final Answer for Question 3: D. Impossible travel

For a near-real-time (NRT) analytics rule that detects sign-ins by a designated break-glass account, the most direct and performant pattern is to filter SigninLogs by joining to a Microsoft Sentinel watchlist that contains the protected account(s). Sentinel exposes watchlists to KQL through the helper function _GetWatchlist('<watchlist-name>'), which returns a table with standard columns (including SearchKey) plus any custom columns you imported. Using join kind=inner ensures the result set includes only those SigninLogs rows whose UserPrincipalName matches an entry in the watchlist—ideal for alerting on a high-value account without post-filtering.

The completed query is:

SigninLogs | join kind=inner (_GetWatchlist('breakglass_account')) on $left.UserPrincipalName == $right.SearchKey

This approach satisfies the requirement to implement an NRT rule for the break-glass account because:

NRT rules support KQL with joins and watchlists and are optimized for rapid evaluation over fresh data.

Using a watchlist lets SecOps adjust monitored accounts without editing the rule—minimizing administrative effort and aligning with least-privilege operations (no extra permissions beyond watchlist management).

The inner join pattern reduces noise by returning only matched events, which are then turned into alerts/incidents by the NRT rule.

Thus, select join and GetWatchlist, and join UserPrincipalName to the watchlist’s SearchKey.

The case study requires:

“Ensure that the Group1 members can create and edit playbooks.”

In Microsoft Sentinel, the ability to create, edit, and assign playbooks is granted by the Microsoft Sentinel Automation Contributor role.

This role allows users to:

Create and manage automation rules,

Create and edit playbooks (Logic Apps) in the connected subscription,

Associate playbooks with Sentinel incidents or alerts.

By contrast:

Logic App Contributor allows Logic App creation but doesn’t include Sentinel-level integration permissions.

Automation Operator can run playbooks but not edit or create them.

Sentinel Playbook Operator can execute playbooks but cannot modify or assign them.

✅ Answer for Question 11: A. Microsoft Sentinel Automation Contributor

In Microsoft Sentinel, Hunting queries are used to proactively search for threats and anomalies across collected security data. The requirement states that HuntingQuery1 must run automatically when the Hunting page of Microsoft Sentinel is accessed. According to Microsoft’s official Sentinel documentation, this behavior is achieved by adding the hunting query to “Favorites.”

When a query is marked as a favorite in the Sentinel Hunting blade, Sentinel automatically runs it every time the Hunting page is opened. This provides updated results without the need for manual execution, ensuring analysts always see the most current data for that query. This configuration also adheres to the organization’s requirement to minimize administrative effort, since it eliminates the need for scheduling, automation, or manual refresh actions.

Other options do not meet this functional requirement:

A. Add to a livestream is used to monitor near-real-time data streams, not to auto-run queries upon accessing the Hunting page.

B. Create a watchlist is used for referencing static external data sets (like IPs, users, or devices) inside KQL queries, not for automating hunting query execution.

C. Create an automation rule applies to incident management workflows, not hunting query execution.

Therefore, as per Microsoft Sentinel’s hunting documentation and best practices, the correct and verified answer is:

D. Add HuntingQuery1 to favorites.

To attach notes that you can later see during investigations and hunting, you use Bookmarks in Microsoft Sentinel. Bookmarks are created from the Hunting (or Logs) experience inside the Sentinel workspace and let you pin a specific query result (including IPs, accounts, hosts) with notes, tags, and mapped entities so it appears in the investigation graph and is easily referenceable. The correct workflow is: first, run your KQL query from the Microsoft Sentinel workspace (not from generic Azure Monitor), because Sentinel’s hunting experience is where bookmarks integrate with incidents and the investigation graph. Next, select a specific query result that represents the suspicious activity (e.g., a data access event from the target IP). Finally, create a Bookmark and map the relevant entity (IP address, Account, etc.) while adding your notes. Mapping the entity ensures the bookmarked event is connected in the investigation graph; the notes provide the narrative/context you need when pivoting later. Adding the query to favorites is optional for convenience but does not attach notes to a specific event, and running the query from Azure Monitor would not place the bookmark within Sentinel’s investigation context.

Azure Sentinel “playbooks” are Azure Logic Apps. Granting the minimal permissions to configure (create/edit) playbooks requires the Logic App Contributor role on the resource group where the playbooks reside. This satisfies the business requirement to use least privilege and specifically enables admin1 to design, modify, and manage Logic Apps that Sentinel automation rules or analytics rules will invoke. Roles like Automation Operator or Automation Runbook Operator apply to Azure Automation, not Logic Apps, and therefore don’t allow creating or editing Sentinel playbooks. Azure Sentinel Contributor allows managing Sentinel resources (incidents, analytics rules, workbooks) but, by itself, does not grant permissions to author Logic Apps. Assigning Logic App Contributor provides precisely what is needed to configure Sentinel playbooks without unnecessary broader permissions.

To block unsanctioned cloud apps on Windows 10 endpoints with Microsoft Defender for Endpoint and Microsoft Defender for Cloud Apps (formerly Cloud App Security), you must enable and configure the product integration on both sides. First, in Microsoft Defender Security Center → Settings → Advanced features, turn on the Microsoft Defender for Cloud Apps integration (and ensure network protection prerequisites are met). This allows Defender for Endpoint to receive the unsanctioned app list and enforce endpoint-based blocking when users on CLIENT1 attempt to access those apps via the browser or client.

Second, in Defender for Cloud Apps → Settings → Cloud Discovery, configure the Microsoft Defender for Endpoint integration and enable Block unsanctioned apps. In Cloud Discovery, apps are discovered, assessed, and can be tagged as Unsanctioned. Once the MDE integration is enabled, that tag is exported to endpoints, which then enforce blocking based on the tenant’s app catalog and policies.

Options A (Onboarding settings) are for enrolling devices and do not control app blocking behavior. B (Anomaly detection policies) govern behavioral detections (e.g., impossible travel, anonymous IP) and are unrelated to endpoint enforcement of app access. Therefore, the two configurations you must modify to meet the requirement “block unsanctioned apps on Windows 10 computers by using Microsoft Defender for Endpoint” are C. Advanced features in Microsoft Defender Security Center and D. Cloud Discovery settings in Cloud App Security.

To show labeled files from Windows 10 endpoints in the Azure Information Protection – Data discovery dashboard, you must first enable the built-in integration between Microsoft Defender for Endpoint and Azure Information Protection (AIP). This is turned on in the Microsoft Defender Security Center under Settings → Advanced features. When enabled, Defender for Endpoint inventories sensitivity labels seen on files across managed Windows devices and streams that telemetry to the AIP Data discovery experience, providing visibility into where labeled data resides on endpoints. Scanner clusters and content scan jobs in AIP are intended for on-premises repositories (file shares/SharePoint servers), not for endpoint discovery. Device health/compliance reports do not surface or forward label inventory to AIP. Therefore, the first configuration step is enabling the AIP integration advanced feature in Defender for Endpoint so labeled files on Windows clients appear in the AIP Data discovery dashboard.

 Log Analytics workspace to use: LA1

 Windows security events to collect: All Events

To meet the Azure Defender (Microsoft Defender for Cloud) requirement that all servers send logs to the same Log Analytics workspace, you should select the existing workspace LA1. Defender for Cloud best practices recommend centralizing data in a single workspace for unified analytics, incident correlation, and cost control. Using the “Default workspace created by Azure Security Center” or creating a new workspace would fragment telemetry, complicate management, and contradict the stated requirement and the business goal to minimize costs (multiple workspaces can increase ingestion/retention overhead and complicate RBAC and automation).

For Windows hosts, Defender for Cloud’s Data collection setting controls the level of Windows Security Events collected: Minimal, Common, or All Events. The business requirement calls for logs that provide a full audit trail of user activities. In Microsoft guidance, All Events is the level intended for comprehensive auditing (including logon/logoff, account changes, privilege use, process creation, object access, and other advanced categories). Therefore, to satisfy the “full audit trail” requirement and ensure complete visibility for investigations and Sentinel analytics, choose All Events.

In summary: centralize on LA1 (single workspace) and collect All Events to achieve both operational and compliance objectives with Defender for Cloud and Sentinel.

In Microsoft Sentinel’s Advanced Security Information Model (ASIM), DNS queries are normalized through the Im_Dns parser, which unifies DNS telemetry from multiple sources (Infoblox, Windows DNS, Azure Firewall DNS proxy, etc.). Microsoft guidance states that when you need broad compatibility and want to “use built-in ASIM parsers whenever possible,” you should call the generic Im_Dns() parser. To minimize overhead, ASIM provides a pack parameter that restricts the parser to a specific content pack (vendor/source) so it won’t iterate through all available source parsers under the hood. For Infoblox NIOS, you pass the Infoblox pack via the pack parameter, which limits parsing to the Infoblox implementation and reduces query cost/latency while keeping the query portable across environments.

Putting it together, the recommended pattern is:

Im_Dns(pack="InfobloxNIOS")

| where DnsResponseCodeName == "NXDOMAIN"

| summarize count()

This approach satisfies all requirements:

Uses built-in ASIM (Im_Dns).

Minimizes query overhead (uses pack to limit parsing to Infoblox).

Targets NXDOMAIN responses for counting DNS request failures from Infoblox1.

To restrict cloud apps running on CLIENT1 (a Windows 10 endpoint) in compliance with Microsoft Defender for Endpoint (MDE) requirements, you must integrate Microsoft Defender for Endpoint with Microsoft Defender for Cloud Apps (formerly Cloud App Security) using Cloud Discovery. This integration enables the blocking of unsanctioned cloud apps through the endpoint’s network protection capabilities.

According to Microsoft Defender for Cloud Apps documentation, Cloud Discovery uses traffic data from Defender for Endpoint to identify and manage the use of shadow IT. The relevant steps include:

1️⃣ Enable advanced features in Microsoft Defender for Endpoint (M365 Defender portal → Settings → Endpoints → Advanced features).

You must enable the following advanced features:

Microsoft Defender for Cloud Apps integration

Network protection (in block mode)

Custom network indicators (if applicable)These options allow Defender for Endpoint to share telemetry and enforce app restrictions received from Defender for Cloud Apps.

2️⃣ Configure Cloud Discovery settings in Microsoft Defender for Cloud Apps.

In the Defender for Cloud Apps portal, Cloud Discovery must be configured to receive continuous reports from Defender for Endpoint devices. Within these settings, you define sanctioned and unsanctioned applications. Once an app is marked as unsanctioned, Defender for Endpoint enforces blocking on all onboarded devices (like CLIENT1).

This two-part configuration ensures that MDE enforces the blocking of unsanctioned cloud applications discovered through Cloud App Security telemetry, fulfilling the business requirement that “All Cloud App Security unsanctioned apps must be blocked on the Windows 10 computers by using Microsoft Defender for Endpoint.”

According to Microsoft Defender for Cloud (formerly Azure Security Center) documentation, when integrating servers and virtual machines for security monitoring, the Defender for Cloud data is stored and analyzed in a Log Analytics workspace. Microsoft best practices recommend using an existing workspace when one is already deployed for centralized log collection—especially if it already gathers telemetry from Azure and on-premises resources.

In this case, the existing workspace LA1 already “contains logs and metrics collected from all Azure resources and on-premises servers.” This satisfies the business requirement of “all servers must send logs to the same Log Analytics workspace.” Creating a new workspace would violate the cost-minimization and centralization requirements. Therefore, LA1 is the correct workspace to use.

For the Windows security events collection setting, Defender for Cloud offers three levels:

Minimal – collects essential security events only (insufficient for comprehensive monitoring).

Common – collects a balanced set of security-related events (such as account logon, privilege use, and object access), recommended by Microsoft for most environments.

All Events – collects every possible security event, which increases data ingestion cost and is typically used only for high-security or regulated environments.

Because Litware Inc. must minimize cost while ensuring a full audit trail of user activities, the Common level provides the optimal balance of visibility and cost efficiency.

Therefore, based on Microsoft Defender for Cloud configuration guidelines:

✅ Log Analytics workspace to use: LA1

✅ Windows security events to collect: Common

The requirement states that Cloud App Security (Defender for Cloud Apps) must determine whether a user’s connection is anomalous based on tenant-level patterns, and the current false positives occur when users connect through two office egress points at the same time. These symptoms align with the Impossible travel anomaly detection policy, which learns normal sign-in geolocation patterns and flags sign-ins from distant locations within an unrealistically short time window. To meet the requirement and reduce false positives, you modify the Impossible travel policy settings—such as excluding trusted corporate IP ranges/VPN egress points and tuning sensitivity—so detections better reflect tenant-wide behavior rather than isolated user hops via different office exits. Policies like Activity from anonymous/suspicious IP addresses rely on threat-intel lists of anonymizers or known-bad sources and don’t address the “two-office” scenario. Risky sign-in is part of Azure AD Identity Protection, not the MCAS anomaly policy to tune here. Thus, the policy to modify is Impossible travel.

According to Microsoft’s official Defender for Identity deployment documentation, setting up Microsoft Defender for Identity (MDI) on an on-premises domain controller (DC) such as DC1 requires a specific sequence of steps. MDI monitors and protects Active Directory from advanced threats by using sensors installed directly on domain controllers.

The correct sequence is as follows:

1️⃣ Provide global administrator credentials to the Azure AD tenant.

Microsoft Defender for Identity is created and managed in the Microsoft 365 Defender portal or Microsoft Security portal, which requires global administrator permissions to provision the MDI instance and connect it to the Azure AD tenant.

2️⃣ Create an instance of Microsoft Defender for Identity.

You must create an MDI instance in the portal before deploying any sensors. This instance defines your Defender for Identity workspace and generates the configuration package that sensors will later use to connect to the cloud service.

3️⃣ Provide domain administrator credentials to the on-premises Active Directory domain.

Domain admin credentials are required for the sensor installation because the sensor must access the domain controller’s security logs, event logs, and directory services to monitor authentication traffic and suspicious activities.

4️⃣ Install the sensor on DC1.

Since DC1 is a domain controller connected directly to the internet, the standard sensor (not the standalone sensor) is installed directly on it. The standalone sensor is used only when you do not want to install the sensor directly on a DC. The sensor automatically connects to the created MDI instance and begins collecting telemetry for detection.

This sequence aligns with Microsoft Defender for Identity deployment guidance, ensuring secure onboarding of DC1 while maintaining the principle of least privilege and meeting the business requirement to protect all domain controllers.

✅ Final Order:

Provide global administrator credentials →

Create instance of Microsoft Defender for Identity →

Provide domain administrator credentials →

Install the sensor on DC1.

In Microsoft Sentinel, analysts manage and investigate incidents through the Incident page, which provides multiple investigation and triage tools. The two core aspects of incident analysis relevant here are entity visualization and investigation audit tracking.

Entity Map (Investigate):

Selecting Investigate opens the Investigation Graph view in Microsoft Sentinel.

This interactive map visually displays all the entities (users, IPs, hosts, accounts, files, etc.) related to the alert and their relationships.

It helps analysts understand how alerts are connected, uncover lateral movements, and explore correlated suspicious activities.

Microsoft documentation describes this as:

“The investigation graph provides a visual representation of the entities involved in the incident, showing relationships between them to aid root-cause analysis.”

Hence, to view a map of connected entities, choose Investigate.

Investigation Activities (Comments):

The Comments tab tracks the activities and analyst notes during the incident lifecycle.

This includes changes to status, assignments, and documented investigation steps — essentially functioning as an activity log for the incident.

Microsoft’s official Sentinel documentation states:

“The Comments section in the incident pane provides a timeline of analyst interactions, investigation notes, and changes performed on the incident.”

Therefore, to view the list of investigation activities, select Comments.

To integrate Microsoft Defender for Cloud Apps (MCAS) with Microsoft Sentinel, Microsoft’s official SecOps and Sentinel documentation specifies a two-step configuration process.

In the Defender for Cloud Apps portal – You add a security extension to enable integration with external SIEM platforms. This action allows MCAS to forward its alerts, activities, and discovered app telemetry to other Microsoft or third-party security platforms. By adding the security extension, Defender for Cloud Apps is authorized to send data streams and alerts to Microsoft Sentinel through a supported API connection.

In Microsoft Sentinel (Azure portal) – You then add a data connector. Data connectors in Sentinel are predefined integration pipelines that bring in telemetry from Microsoft or external security solutions. The Microsoft Defender for Cloud Apps connector specifically ingests MCAS alerts and audit logs into Sentinel, where they can be correlated with other Microsoft Defender XDR signals, enabling unified detection and investigation across identity, endpoint, and cloud layers.

This integration approach adheres to Microsoft’s principle of minimizing administrative effort by using native connectors rather than custom ingestion or log collector configurations. Once connected, Sentinel automatically normalizes MCAS alerts into its SecurityAlert and CloudAppEvents tables for rule creation, playbook automation, and incident correlation.

Therefore, the verified correct configuration is:

Defender for Cloud Apps: Add a security extension

Sentinel: Add a data connector

To integrate Microsoft Defender for Cloud Apps (MCAS) with Microsoft Sentinel, Microsoft’s official SecOps and Sentinel documentation specifies a two-step configuration process.

In the Defender for Cloud Apps portal – You add a security extension to enable integration with external SIEM platforms. This action allows MCAS to forward its alerts, activities, and discovered app telemetry to other Microsoft or third-party security platforms. By adding the security extension, Defender for Cloud Apps is authorized to send data streams and alerts to Microsoft Sentinel through a supported API connection.

In Microsoft Sentinel (Azure portal) – You then add a data connector. Data connectors in Sentinel are predefined integration pipelines that bring in telemetry from Microsoft or external security solutions. The Microsoft Defender for Cloud Apps connector specifically ingests MCAS alerts and audit logs into Sentinel, where they can be correlated with other Microsoft Defender XDR signals, enabling unified detection and investigation across identity, endpoint, and cloud layers.

This integration approach adheres to Microsoft’s principle of minimizing administrative effort by using native connectors rather than custom ingestion or log collector configurations. Once connected, Sentinel automatically normalizes MCAS alerts into its SecurityAlert and CloudAppEvents tables for rule creation, playbook automation, and incident correlation.

Therefore, the verified correct configuration is:

Defender for Cloud Apps: Add a security extension

Sentinel: Add a data connector

The test analytics rule must generate alerts for inbound Office 365 access by several test users and group those alerts into separate incidents—one per user. In Azure Sentinel, incident grouping by entity depends on the rule’s Entity mapping. When you create a scheduled analytics rule, under Set rule logic you map columns from your query to entities like Account, IP, or Host. Once mapped, you can configure Event grouping so alerts with the same entity value (e.g., the same Account) are automatically grouped into a single incident. Turning suppression on/off or changing severity/tactics doesn’t influence entity-based incident grouping. Therefore, to ensure “one incident per test user account,” you must map the Account entity (and any other relevant entities) in Set rule logic, then enable grouping by that entity—fulfilling the Sentinel requirement.QUESTION NO: 3 HOTSPOT

You need to create the analytics rule to meet the Azure Sentinel requirements.

What should you do? To answer, select the appropriate options in the answer area.

NOTE: Each correct selection is worth one point.

Answer:

According to Microsoft Security Operations (SecOps) and Azure Sentinel documentation, when you need to create an analytics rule that executes a custom KQL query and automatically initiates a playbook, the correct configuration is to create a Scheduled rule and ensure the playbook includes a trigger.

Here’s why:

A Scheduled analytics rule in Microsoft Sentinel (Microsoft Defender XDR portal) is designed for running custom KQL queries at defined intervals (for example, every hour or every few minutes) to detect specific patterns of suspicious activity. When the rule’s conditions are met, Sentinel generates alerts that can automatically trigger a playbook for response and automation.

A playbook in Sentinel is an Azure Logic App that automates responses to incidents or alerts. To connect a playbook to an analytics rule, it must include a trigger—specifically, the “Microsoft Sentinel Alert” or “Incident trigger.” This allows the rule to start the playbook automatically when the defined condition is met.

The other options are incorrect because:

Fusion rules are built-in and use Microsoft’s machine learning to correlate signals automatically; they can’t be used for custom queries.

Microsoft incident creation rules are also built-in and handle alert-to-incident grouping logic, not custom query execution.

A service principal would be needed for permissions (e.g., admin1 configuring playbooks), but not inside the playbook itself.

Diagnostics settings apply to log collection and retention, not rule automation.

Therefore, based on Microsoft Sentinel best practices and documentation:

✅ Create the rule of type: Scheduled

✅ Configure the playbook to include: A trigger

In Microsoft Sentinel, entity mapping is a critical configuration that ensures detected events and alerts are correctly represented in the investigation graph, incidents, and hunting experiences. The Sentinel requirements in the case study specify:

“Add notes to events that represent data access from a specific IP address to provide the ability to reference the IP address when navigating through an investigation graph while hunting.”

To meet this requirement, the analytic rule must be configured to map entities such as IP address, user, hostname, or URL in the Set rule logic section. This mapping allows the incident and its related alerts to visually associate with those entities, enabling analysts to pivot and investigate in the Sentinel investigation graph.

According to Microsoft Sentinel documentation:

“Entity mapping in analytic rules helps correlate alerts and incidents to specific entities such as accounts, IPs, or hosts, enabling richer investigation experiences and faster triage.”

Therefore, configuring entity mapping directly under Set rule logic ensures that incidents are enriched with contextual information (for example, the specific IP address), meeting both the functional and investigative requirements.

✅ Final Answer for Question 2: C. From Set rule logic, map the entities.

To release quarantined items on a Windows device protected by Microsoft Defender for Endpoint/Antivirus, you use the Microsoft Defender command-line utility MpCmdRun.exe. This tool supports maintenance actions including scanning, definition management, and quarantine operations. For quarantine specifically, the supported switch is -Restore, which restores items from quarantine. The typical syntax for restoring all items for a specific threat name is:

MpCmdRun.exe -Restore -Name "" -All

Here, the -Name parameter specifies the detected threat family or name (for custom indicators it reflects the custom threat label, e.g., EUS:Win32/CustomEnterpriseBlock), and -All applies the restore operation to all items associated with that name—ideal when multiple files (e.g., 20) were quarantined by the same indicator.

Other options are not appropriate for this task:

-GetFiles collects diagnostic logs for support.

-RemoveDefinitions and -ResetPlatform handle antimalware engine/definitions, not quarantine.

MsMpEng.exe is the Defender service binary (not invoked directly), and Start-MpRollback is a separate PowerShell cmdlet for rolling back remediations, not for restoring quarantined files by name.

Therefore, to release the 20 files: MpCmdRun.exe -Restore -Name "EUS:Win32/CustomEnterpriseBlock" -All.

Defender for Cloud alerts include a kill chain intent field that maps to MITRE ATT&CK tactics (for example, PrivilegeEscalation, Persistence, CredentialAccess). In the alert JSON this is exposed as intent; searching that key lets you filter for alerts where the tactic is Privilege Escalation.