SC-200 Reviews Questions

To monitor and detect higher-than-normal volumes of password resets, you need to gather password reset event data both from Azure Active Directory (cloud identities) and from on-premises Active Directory (domain accounts). Microsoft’s official Defender XDR and Sentinel integration guidance describes that:

Azure AD Password Protection enforces and monitors password policies in both cloud and hybrid environments. It can detect weak, commonly used, or compromised passwords and logs related password change/reset activities. Deploying Azure AD Password Protection extends password reset visibility to on-premises domain controllers through the Password Protection proxy and DC agent. This makes it the correct choice for implementing monitoring at the identity environment level.

In Microsoft Sentinel, to ingest and analyze password reset activities from on-premises servers (e.g., domain controllers), you must use the Windows Security Events via AMA connector. This connector collects Event ID 4723 (password change), 4724 (password reset), and related security logs directly from Windows Servers into the Sentinel Log Analytics workspace through the Azure Monitor Agent (AMA). Once the events are available in Sentinel, they can be correlated with other identity or behavioral analytics to detect abnormal reset volumes or potential compromise attempts.

The other options are not suitable:

Microsoft Defender for Identity focuses on identity compromise detection, not specifically on password reset volume monitoring.

Smart lockout protects against brute-force sign-in attempts but doesn’t generate detailed reset event telemetry.

Microsoft security rule and UEBA are higher-level analytic configurations, not data ingestion mechanisms.

Therefore, to meet the Sentinel requirements for monitoring password reset anomalies:

✅ Implement in the identity environment: Azure AD Password Protection

✅ Configure in Microsoft Sentinel: The Windows Security Events via AMA connector

In Microsoft Defender for Endpoint (Plan 2), you can use indicator file hashes (IoC file hashes) to block files from executing or being downloaded. When you create a file hash indicator, you specify the exact file hash (for example, SHA-256 or MD5) and choose actions such as “block” or “remediate.”

However, an important detail is that file hash indicators are applied to specific files—that is, for a given executable or file content. You cannot use a hash indicator to block all files of a certain extension generically. If a given file has a different hash, it will not be blocked unless you add its specific hash. Because the question says you found suspected malware files sys, pdf, docx, xlsx, and you need to block users from downloading those files, only those files for which you can compute and apply a specific hash indicator can be blocked. The question implies you can create indicator hashes for each of those file names (assuming each has a unique hash).

Thus you can block all four (File1.sys, File2.pdf, File3.docx, File4.xlsx) by adding each as an indicator hash. The choice E lists all four. That is consistent with Microsoft’s statements that “you can create indicators that define detection, prevention, or exclusion of entities,” and file hash indicators specifically apply to those files. Microsoft Learn+3Microsoft Learn+3Microsoft Learn+3

Options that exclude some file types (e.g. only blocking sys and docx but not pdf or xlsx) would leave gaps, which doesn’t satisfy the requirement of blocking all those suspected files. Hence E is the correct answer.

In Copilot for Security promptbooks, inputs are referenced as placeholders wrapped in angle brackets (for example, ). To define an input named IncidentID in a prompt, format it as .