Free Microsoft SC-900 Practice Exam with Questions & Answers | Set: 3

Sensitive Information Types (SITs) support regular expressions (regex), which allow for custom pattern matching to detect sensitive content like credit card numbers, social security numbers, or custom identifiers. Regex is fundamental to the detection logic within SITs.

SCI Extract: "Sensitive information types use pattern matching techniques, including regular expressions, keyword matches, and checksums to identify sensitive data."

In the Core eDiscovery (Microsoft Purview) workflow, you first create a case, add case members, and then (typically) apply eDiscovery holds to relevant locations to preserve potentially responsive content before you run searches. While a hold isn’t strictly required to execute a search, Microsoft’s documented workflow shows holds occur prior to creating and running content searches so that items aren’t altered or deleted during the investigation. After holds, you create searches, review, and export.

Microsoft describes Azure Policy as the built-in governance service that lets you “create, assign, and manage policies” to enforce organizational standards and “assess compliance at scale.” It continuously evaluates existing resources for compliance and can take effect-enforcement actions such as deny, append, or modify during create/update operations. Azure Policy “helps you audit and enforce your standards” across subscriptions and resource groups, and its compliance dashboard shows overall and per-policy compliance states for all resources. By contrast, Azure Blueprints focuses on orchestrating deployments of artifacts (such as policy assignments, role assignments, and templates) for new environments; Microsoft guidance positions Policy as the engine that evaluates and enforces those standards on existing resources. Sentinel is a SIEM/SOAR for security analytics, and Anomaly Detector is a Cognitive Service—not a governance/compliance enforcement tool. Therefore, to assess compliance and enforce standards for existing Azure resources, the prescribed control plane is Azure Policy with its evaluation cycle, initiative (policy set) support, and remediation tasks.

According to Microsoft’s Security, Compliance, and Identity (SCI) documentation and learning paths (specifically SC-900, SC-300, and Azure AD Identity Protection modules):

“Conditional Access policies in Azure AD are the primary method for enforcing access controls based on specific conditions such as user, group, location, device compliance, and application.”

In this case, the organization can configure a Conditional Access policy that targets a specific Azure AD group and requires MFA as a condition before access is granted. The typical policy setup includes:

Assignments: Target users or groups (e.g., “Finance Department Users”).

Cloud apps or actions: Specify which applications or services are protected (e.g., Microsoft 365).

Access controls: Set the control to “Require multi-factor authentication.”

Microsoft’s SCI training materials further state:

“Conditional Access enables administrators to enforce MFA for specific users, groups, or scenarios. It provides flexibility to protect access without enabling MFA globally for all users.”

Other options explained:

Azure Policy (A) applies to Azure resources, not user authentication.

Communication compliance policy (B) monitors message content for compliance violations.

User risk policy (D) is part of Azure AD Identity Protection, enforcing MFA based on detected user risk levels, not group membership.

Therefore, the verified and correct answer is: ✅ C. a Conditional Access policy.

Microsoft Entra Conditional Access (CA) evaluates signals from the user, device, location, and risk to make access decisions. The platform explicitly notes that CA decisions occur after primary sign-in: “Conditional Access policies are enforced after the first-factor authentication has been completed.” This means a user must successfully present their initial credentials (e.g., password, Windows Hello, FIDO2) before the CA engine evaluates policy logic. Therefore, the statement that CA is evaluated before a user is authenticated is not correct.

Regarding scoping, CA can target ordinary and privileged identities. The assignment options allow administrators to aim policies at users, groups, and directory roles: “You can include or exclude users and groups… [and] include or exclude specific Azure AD directory roles from a Conditional Access policy.” Because Global Administrator is a directory role, policies can be applied to those accounts (with Microsoft’s best-practice guidance to maintain at least one excluded break-glass account to prevent lockout).

For signals/conditions, CA supports device platform filtering. The documented device platform condition states: “This condition is based on the operating system platform of the device… iOS, Android, Windows, macOS (and others).” Administrators commonly use this to require different controls (like MFA or compliant device) based on Android or iOS.

Putting these together:

CA can apply to Global Administrators (Yes).

CA is evaluated after first-factor authentication (No to “before”).

Device platform (e.g., Android/iOS) is a valid CA signal (Yes).

Microsoft’s Zero Trust guidance defines three core principles: “Verify explicitly, use least-privileged access, and assume breach.” In Microsoft’s SCI learning content and Zero Trust overview, the model is described as one that “treats every access attempt as though it originates from an open, untrusted network” and therefore requires explicit verification using all available signals (identity, device health, location, data sensitivity, and anomalies). This directly confirms the first statement as true: Verify explicitly is a guiding principle.

The same guidance states organizations must “assume breach”—designing controls so that if an attacker is already inside, blast radius is minimized through segmentation, Just-In-Time/Just-Enough-Access, continuous monitoring, and rapid detection and response. Microsoft’s Zero Trust materials repeatedly explain to “assume attackers are present” and to “contain and remediate” through defense-in-depth controls, which validates the second statement as true.

Finally, Zero Trust rejects perimeter-based implicit trust. Microsoft clarifies that the model does not rely on a trusted internal network protected by a firewall; instead it “never trusts, always verifies,” continuously enforcing policy regardless of network location (on-premises or internet). Therefore, the statement that Zero Trust assumes a firewall secures the internal network from external threats is false because Zero Trust presumes no inherent safety from being “inside” the network and requires continuous verification and least-privileged access everywhere.

Microsoft documents for Defender for Endpoint (MDE) describe it as an enterprise endpoint security platform that supports Windows 10/11, Windows Server, Linux, macOS, and mobile platforms (Android and iOS/iPadOS). The platform provides threat and vulnerability management, attack surface reduction, next-generation protection, endpoint detection and response, and automated investigation and remediation across those supported operating systems. Because MDE supports Windows client operating systems and servers, it can also be used on Azure virtual machines that run supported Windows versions; onboarding methods include local scripts, Microsoft Endpoint Manager, or cloud integrations, allowing VM endpoints to receive the same protection and EDR capabilities as physical devices.

By contrast, malware scanning in SharePoint Online, OneDrive, and Microsoft Teams is provided by Microsoft Defender for Office 365 (Safe Attachments for SharePoint, OneDrive, and Teams)—a different service within the Microsoft 365 Defender family. This service analyzes files as they are uploaded or shared to detect and block malicious content in collaboration workloads, which is outside the scope of MDE’s endpoint-focused protections. Therefore: Android protection (Yes), Azure VMs running Windows 10 (Yes), and SharePoint Online anti-virus protection by MDE (No, handled by Defender for Office 365).

Microsoft Purview Insider Risk Management is designed to identify, investigate, and act on risky activities by internal users—for example data exfiltration, data theft, policy violations, and user sentiments/signals that may indicate insider risk. SCI documentation explains that Insider Risk policies analyze signals such as file downloads, copying to USB, sharing to personal cloud, printing, or anomalous activity following events like performance warnings or resignation notices. Because it focuses on insider behaviors, it is not used to detect external threat vectors like phishing scams; those are addressed by Microsoft Defender for Office 365 and related anti-phishing protections—hence statement 1 is No. The solution is accessed in the Microsoft Purview (formerly Microsoft 365) compliance center under Insider risk management, where admins configure policies, alerts, and workflows—so statement 2 is Yes. Finally, its core purpose includes detecting and investigating potential data leaks by disgruntled or departing employees, using built-in policy templates (e.g., Data theft by departing employee, Data leaks), making statement 3 Yes.

In the Microsoft 365 security center (now Microsoft 365 Defender), incidents are used to triage and investigate threats across the tenant. Microsoft’s security documentation explains that “an incident is a collection of related alerts” that are automatically correlated to give analysts a single, end-to-end view of an attack. Within each incident, the portal surfaces impacted assets such as devices, users, mailboxes, and applications, enabling responders to quickly identify which endpoints are affected by a given alert and to take response actions (isolate device, collect investigation package, run AV scan, etc.). This design allows security teams to move beyond individual alerts and instead work a consolidated investigation that lists affected devices in the incident’s Evidence & Response/Assets sections, complete with alert timelines and device details.

By comparison, Secure Score measures the organization’s security posture and recommendations; policies are configuration/enforcement objects (e.g., Defender or compliance policies) and are not the investigative view for alerts; classifications relate to information protection labeling rather than alert investigation. Therefore, to identify devices that are affected by an alert, you use the Incidents experience in Microsoft 365 Defender, where correlated alerts show the devices involved alongside the entities and evidence connected to the threat.

Yes

NO

NO

YES - As an administrator, you can lock a subscription, resource group, or resource to prevent other users in your organization from accidentally deleting or modifying critical resources. The lock overrides any permissions the user might have.

NO - The most restrictive lock in the inheritance takes precedence.

NO - If you delete a resource group with a locked resource, the portal UI will give you an error and no resources are deleted.

https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/lock-resources?tabs=json