Free Microsoft SC-200 Practice Exam with Questions & Answers | Set: 2

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

 Microsoft Entra role: Security Administrator

 Role for WS1: Microsoft Sentinel Contributor

To enable User and Entity Behavior Analytics (UEBA) in Microsoft Sentinel , a user must have permission to configure data connectors that access Microsoft Entra ID (Azure AD) identity data and to manage Sentinel settings for the workspace.

This requires roles in two scopes :

1️ ⃣ Microsoft Entra ID (directory) level – for identity data access.

2️ ⃣ Sentinel workspace level – for Sentinel feature management.

Step 1: Microsoft Entra (Azure AD) Role → Security Administrator According to Microsoft documentation, enabling UEBA requires connecting Microsoft Sentinel to Microsoft Entra ID to import user and identity behavior data.

The Security Administrator role grants the necessary read permissions to user and sign-in data while still adhering to the principle of least privilege .

The Global Administrator role would also work but provides excessive privileges beyond what’s required for UEBA configuration.

The Security Operator role is limited to viewing alerts and cannot configure Sentinel connectors.

Hence, Security Administrator is the correct least-privilege directory role.

Step 2: Role for WS1 (Sentinel Workspace) → Microsoft Sentinel Contributor To manage Sentinel configuration and enable features such as UEBA , data connectors , and analytics rules , the Microsoft Sentinel Contributor role is required at the workspace level.

The Sentinel Contributor role allows enabling/disabling features, managing playbooks, and configuring connectors.

The Sentinel Automa tion Contributor role is only for playbook automation permissions.

The basic Contributor role can manage Azure resources but doesn’t grant Sentinel-specific privileges.

✅ Final Answer:

Microsoft Entra role: Security Administrator

Role for WS1: Microsoft Sentinel Contributor

 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.

To combine Microsoft Graph activity logs with Microsoft Entra ID Protection risky users , while minimizing data volume, you use the lookup kind=leftouter operator.

Microsoft documentation explains:

“Use lookup (instead of join) when you need to enrich a large dataset with a small lookup table to minimize data returned.”

MicrosoftGraphActivityLogs provides user activity records.

AADRiskyUsers lists users detected as risky by Entra ID Protection.

A leftouter lookup ensures all Microsoft Graph activity entri es are kept, while only matching risky user info is appended — reducing output volume compared to a full join .

✅ Correct Answer: A. MicrosoftGraphActivityLogs lookup kind=leftouter AADRiskyUsers on $left.UserId == $right.Id

Comprehensive and Detailed Explanation with all Microsoft Security Operations (SecOps) documents : =

To search for specific criteria in Amazon Web Services (AWS) logs and generate incidents using Microsoft Sentinel , the configuration process follows a structured sequence according to Microsoft Sentin el documentation and the Azure Sentinel playbook for AWS integration.

Add the Amazon Web Services (AWS) connector

Before Sentinel can analyze AWS data, you must integrate AWS logs using the Amazon Web Services data connector . This connector streams AWS Clo udTrail and other AWS log data into your Sentinel workspace. Microsoft’s documentation states: “Use the Amazon Web Services (AWS) connector to stream CloudTrail events and security logs into Microsoft Sentinel for analysis and alerting.”

Without this conne ctor, Sentinel cannot query or detect AWS-specific activities.

Create a custom analytics rule that uses a scheduled query

Once data ingestion is established, you create an analytics rule in Sentinel using a scheduled query to continuously search for specif ic conditions (e.g., unauthorized access attempts, changes to VPC settings, etc.).

Microsoft specifies: “Custom analytics rules run KQL queries on a schedule to detect specific patterns or anomalies across ingested data sources.”

Set the alert logic

After defining your rule, you configure the alert logic to determine when Sentinel should trigger an alert or incident. This includes setting thresholds, event frequency, severity levels, and entity mappings.

Microsoft Sentinel’s official guidance notes: “Alert logic defines the conditions under which an alert is generated from the query results.”

In Microsoft 365 Defender advanced hunting, if you want to automatically receive alerts based on a KQL query—such as detecting when a process disables System Restore—you must convert that query into a custom detection rule . According to Microsoft’s official documentation, custom detection rules “run hunting querie s on a schedule and create alerts and incidents when results are found.”

In order for the detection rule to function properly and correlate results across devices and incidents, the query must output DeviceId and ReportId . These fields are mandatory for an y advanced hunting query that you want to convert into a detection rule be cause they uniquely identify the device and event instance. Without them, the rule cannot properly generate correlated alerts.

Therefore:

Create a detection rule (A) – ensures the qu ery runs automatically and alerts are generated.

Add DeviceId and ReportId (E) – required for detection rule creation and accurate device/event correlation.

Other options are incorrect:

Suppression rule (B) filters alerts, not generate them.

Order by Times tamp (C) is optional for display, not alerting.

DeviceNetworkEvents (D) is unrelated to this process query.

Controlled Folder Access (CFA) is an anti-ransomware feature that protects specified fol ders from unauthorized modification by untrusted apps. While CFA helps prevent malicious processes from encrypting or modifying important files, it is a targeted hardening control and does not provide the broad detection/remediation capability required to ensure devices are protected from arbitrary malicious artifacts that a third-party antivirus missed. CFA blocks certain behaviors (file write/modify) for protected directories but won’t detect, quarantine, or remove unknown malicious files system-wide. The documented purpose of CFA is behavior-based protection for protected folders, not full post-breach remediation or EDR-style blocking. Therefore enabling CFA alone does not satisfy the requirement of ensuring devices are protected from artifacts that were undetected by the third-party AV.

To create a custom workbook in Microsoft Sentinel that displays the number of security alerts per day for each provider , you need to use Kusto Query Language (KQL) functions designed for data aggregation and visualization .

Using bin(TimeGenerated, 1d)

Th e bin() function in KQL is used to group data into time intervals (bins).

In this case, you want to aggregate alerts by day , so the correct syntax is:

bin(TimeGenerated, 1d)

This ensures that the query counts all alerts that fall within each 1-day time window.

The summarize operator then counts the number of alerts for each ProviderName per day.

Example:

summarize count() by ProviderName, bin(TimeGenerated, 1d)

Using render timechart

After summarizing data, you use the render operator to specify how the results should be visualized in the Sentinel workbook.

The timechart rendering type creates a line chart or bar chart where the x-axis represents time (here, days) and the y-axis represents alert counts .

This visualization helps security analysts quickly s ee trends and patterns of alert volume per provider over time.

Example:

render timechart

Complete Query Example:

SecurityAlert

| where TimeGenerated > = ago(30d)

| summarize count() by ProviderName, bin(TimeGenerated, 1d)

| render timechart

This query counts the number of security alerts for each provider (such as Microsoft Defender for Endpoint, Defender for Cloud, etc.) over the last 30 days , grouping results by day and plotting them visually in a time chart .

✅ Final Answer:

Aggregation: bin(TimeGenerated, 1d)

Visualization: render timechart

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

The Fusion analytics rule in Microsoft Sentinel automatically correlates alerts from multiple sources (including Microsoft Defender connectors) to detect multistage attacks . Because Fusion runs continuously and cannot be disabled without losing multi-stage detection, the best practice for temporarily suppressing incidents from a specific connector (like Microsoft Defender) is to use automation rul es , not by disabling the Fusion rule itself.

An automation rule can be configured to trigger on specific conditions (such as “When incident is updated” or “When incident is created”) and then perform an action like running a playbook that applies suppressi on logic.

Here’s the reasoning:

Trigger:

Setting the trigger to “When incident is updated” ensures that the rule evaluates changes to existing incidents—such as enrichment or tagging from Fusion—and provides finer control over suppression, minimizing impac t on the Fusion detection pipeline.

Using “When incident is created” could interfere with Fusion’s initial detection process.

Action:

The appropriate action is “Run playbook” , which allows automated handling (for example, tagging or closing certain inciden ts from a specific connector). This requires minimal administrative effort and avoids turning off the Fusion rule.

This configuration ensures that Fusion continues to detect multistage attacks (so detection isn’t impacted) while automation handles temporar y suppression for specific connectors efficiently.