Microsoft Updated SC-200 Exam Questions and Answers by nia

When integrating Microsoft Sentinel with an Azure Logic App to automate workflows—such as creating or syncing incidents to an on-premises ITSM system—you must configure the Sentinel connector authentication method. Microsoft’s official guidance emphasizes using Managed Identity wherever possible because it provides automatic credential management, Azure-native security, and requires no secret rotation or manual key storage, which minimizes administrative effort.

A Managed Identity is the recommended authentication method for Logic Apps and other Azure services connecting to Microsoft Sentinel. It eliminates the need for manually creating and maintaining service principals or user accounts. The managed identity is automatically trusted by Azure AD and can be granted the required role directly in the Sentinel workspace’s resource group or subscription. This aligns with the requirement to minimize administrative effort.

Among the Sentinel-specific roles:

Microsoft Sentinel Reader: Read-only access to view incidents and data.

Microsoft Sentinel Responder: Can view and update incidents, run playbooks on incidents, and close incidents—exactly what’s required to raise or synchronize incidents externally.

Microsoft Sentinel Automation Contributor: Used when the Logic App triggers or manages automations, not when it only updates incidents.

Since the playbook needs to raise incidents (perform incident-level actions) but not configure automation at scale, the least privilege role that satisfies the requirement is Microsoft Sentinel Responder.

✅ Final Configuration:

Connector Authentication: A managed identity (low admin overhead)

Assigned Role: Microsoft Sentinel Responder (least privilege sufficient for incident operations)

Controlled Folder Access (CFA) is an anti-ransomware feature that protects specified folders 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.

The scenario describes agentless scanning for virtual machines — a feature of Microsoft Defender for Cloud under the Defender CSPM (Cloud Security Posture Management) plan. Defender CSPM introduces agentless scanning capabilities that use snapshot-based (out-of-band) scanning to assess OS vulnerabilities, sensitive data, and configurations without requiring agents.

Microsoft documentation clarifies:

“Agentless scanning for machines is available in Defender CSPM and Defender for Servers P2. The scanning engine takes snapshots of virtual machines and performs analysis out-of-band to identify vulnerabilities and sensitive data exposure.”

For controlling which virtual machines participate, tag-based inclusion or exclusion is used. You can define which machines to include/exclude using Azure resource tags, such as:

Environment=Production

Scan=Exclude

Microsoft Defender for Cloud reads these tags to determine which resources should have scanning enabled or excluded.

Role-based access control (RBAC) and Azure Policy assignments control access and policy enforcement, but they are not used to exclude specific resources from Defender CSPM agentless scanning.

✅ Final Configuration:

Defender Plan: Defender CSPM

Exclusion Method: Tagging

In Microsoft Defender for Cloud Apps (MCAS), Cloud Discovery collects traffic logs to identify shadow IT usage and cloud app activities. To enrich this discovery data and map the usernames in traffic logs to actual Microsoft Entra ID (Azure AD) users, Defender for Cloud Apps must correlate the username with the user’s User Principal Name (UPN).

According to Microsoft Defender for Cloud Apps documentation, this correlation happens automatically when you connect Microsoft 365 (formerly Office 365) through a Microsoft 365 app connector.

The connector integrates MCAS with Microsoft 365, allowing it to:

Normalize usernames from discovery logs to match UPNs.

Provide enriched identity details and activities across Microsoft 365 apps.

Enable cross-app investigation, alert correlation, and conditional access governance.

Other options explained:

Conditional Access App Control – Used for real-time session control, not Cloud Discovery enrichment.

Enable automatic redirection to Microsoft 365 Defender – Used for portal integration, not data enrichment.

Azure app connector – Used to connect third-party or Azure-hosted applications, not for UPN enrichment.

✅ Therefore, to enrich Cloud Discovery data with UPN mapping, you must create a Microsoft 365 app connector.