Free Practice Questions for Microsoft SC-900 Exam

In Microsoft Entra Conditional Access, policy evaluation occurs after the user successfully completes first-factor authentication (for example, username + password or Windows Hello for Business key). Microsoft Learn explains that Conditional Access “is the tool used by Azure AD to bring signals together, make decisions, and enforce organizational policies” and that it’s applied “after the first-factor authentication is completed.” Once primary authentication succeeds, Conditional Access evaluates signals like user, device state, location, risk (from Identity Protection), and application, and then enforces controls such as requiring MFA, blocking access, or applying session controls.

This design ensures Conditional Access does not replace primary authentication and is not enforced before or during the initial credential verification. Instead, it adds a second policy decision point that can demand stronger proof (e.g., MFA), restrict access paths, or limit sessions. Therefore, “after” is correct, while “before,” “during,” or “instead of” first-factor authentication are incorrect because Conditional Access relies on the initial sign-in to collect the necessary signals and then applies the configured access decisions and protections.

In Microsoft Defender for Cloud, the Free plan provides continuous security assessment and visibility into your posture via Secure Score and security recommendations. Microsoft explains that the free tier offers “foundational CSPM capabilities,” including recommendations and a security score (Secure score) to help you prioritize hardening tasks. Advanced features—such as vulnerability scanning for VMs (Qualys-based), Just-In-Time (JIT) VM access, and threat protection alerts—require the enhanced/paid Defender plans (for example, Defender for Servers). Consequently, among the listed options, only Secure score is available in the free mode. This score aggregates the effect of recommendations across subscriptions and resources so you can track and improve security posture without enabling any of the paid Defender plans.

In Microsoft Sentinel, Logic Apps are used as playbooks for automation and orchestration (SOAR)—to take actions after alerts/incidents occur (notify, enrich, remediate). They are not the component that detects or identifies anomalies; detections come from analytics rules, UEBA (user and entity behavior analytics), Fusion (ML-powered correlation), and anomaly rules. Workbooks are interactive dashboards and visualizations for monitoring and reporting; they don’t correlate alerts. Correlation of alerts into incidents is handled by analytics rules (including alert grouping and Fusion) within Sentinel’s detection pipeline. Finally, Sentinel’s Hunting experience provides KQL-based queries and templates that are mapped to the MITRE ATT&CK tactics/techniques, enabling analysts to explore threats in a framework-aligned way. Thus, automation via Logic Apps ≠ anomaly detection; Workbooks ≠ incident correlation; Hunting tooling does align to MITRE ATT&CK.

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 Windows Hello for Business (WHfB) as replacing passwords with a device-bound credential: “Windows Hello for Business replaces passwords with strong two-factor authentication on devices. This authentication consists of a new type of user credential that is tied to a device and uses a biometric or a PIN.” WHfB authenticators are biometric gesture or PIN unlocking an asymmetric key stored on the device (typically in the TPM). Microsoft clarifies that the PIN is not a password and is “local to the device” and used to unlock the user’s private key. Consequently, Yes—a PIN is a supported WHfB sign-in gesture.

Conversely, the Microsoft Authenticator app is a separate Azure AD (Microsoft Entra ID) authentication method (push notifications, TOTP, passwordless phone sign-in). It is not the WHfB credential; WHfB relies on keys/certificates on the device, not on the Authenticator app.

Finally, WHfB credentials are per-device: Microsoft states the credential is “tied to a device” and the private key never leaves the device, which means it does not roam/sync across a user’s different devices. Each device enrolls and provisions its own WHfB key and gesture. These statements from Microsoft SCI documentation lead to the outcomes: No / Yes / No.

The Compliance score in Microsoft Purview Compliance Manager is a measurement tool that evaluates an organization’s progress toward meeting data protection and regulatory compliance requirements. It is specifically designed to help organizations reduce risks related to data governance, privacy, and compliance with various standards such as GDPR, ISO 27001, NIST 800-53, and Microsoft Data Protection Baselines.

According to Microsoft’s official documentation on Compliance Manager, the Compliance score “helps organizations track, improve, and demonstrate their compliance posture by providing a quantifiable measure of compliance with regulations and standards.” Each action within Compliance Manager contributes a certain number of points to the overall score. These points are weighted based on risk, meaning that actions with a greater impact on reducing compliance risk contribute more significantly to the total score.

The score is not an absolute measure of legal compliance but rather an indicator of progress toward implementing recommended controls and risk-reducing actions. Microsoft emphasizes that Compliance score “assists organizations in identifying areas of improvement, prioritizing compliance tasks, and maintaining an auditable record of their compliance activities.”

By contrast, Microsoft Secure Score measures security posture related to identity, device, and application protection, while Productivity Score evaluates collaboration and technology experience. Thus, the metric that specifically assesses data protection and regulatory compliance progress is the Compliance score in Microsoft Purview Compliance Manager.

Microsoft Defender for Identity (formerly Azure Advanced Threat Protection, also known as Azure ATP) is a cloud-based security solution that leverages your on-premises Active Directory signals to identify, detect, and investigate advanced threats, compromised identities, and malicious insider actions directed at your organization.

Onboarding Microsoft Sentinel starts by enabling Sentinel on an existing Log Analytics workspace and then connecting data sources so analytics can operate on ingested security data. Microsoft’s Sentinel onboarding guidance emphasizes that after you add Sentinel to a workspace, you must “connect Microsoft services, non-Microsoft solutions, and custom sources” using built-in data connectors. Microsoft also states that “you need data in your workspace before you can use Microsoft Sentinel’s analytics, hunting, and investigation capabilities.” Features such as custom analytics rules, hunting queries, and incident correlation depend on ingested telemetry from sources like Microsoft Entra ID sign-in logs, Microsoft 365, Defender products, firewalls, and other appliances. Because the question already gives you a Log Analytics workspace (the prerequisite for enabling Sentinel), the first action in the onboarding workflow that unlocks Sentinel’s value is to connect your security sources. Only after data is flowing should you proceed to create analytics rules, hunting queries, and incident processes. Therefore, the correct first step to onboard Microsoft Sentinel is connect to your security sources.

 Azure DDoS Protection Standard protects against man-in-the-middle (MITM) attacks. = No

 Azure DDoS Protection Standard is enabled by default in an Azure subscription. = No

 Azure DDoS Protection Standard protects against protocol attacks. = Yes

Microsoft’s security guidance for Azure states that DDoS Protection is designed to defend internet-facing resources from distributed denial-of-service events at the network and transport layers (L3/L4). The documentation explains that DDoS Protection Standard provides “adaptive, real-time tuning and automatic attack mitigation for volumetric and protocol attacks (for example, SYN/ACK floods, UDP amplification, and other L3/L4 patterns).” It further clarifies that DDoS Protection is not intended to address attacks like man-in-the-middle (MITM), which are interception/alteration threats rather than traffic-exhaustion scenarios.

Regarding enablement, Microsoft notes that Azure DDoS Protection Standard is not enabled by default. The platform provides “basic DDoS protection for all Azure public IP addresses,” but the Standard plan must be explicitly enabled on a virtual network and then applied to public IP resources in that VNet to gain its enhanced telemetry, mitigation policies, and cost-protection benefits.

Putting this together: (1) MITM is out of scope for DDoS Protection Standard → No; (2) Standard is opt-in, not automatic → No; (3) Protection against protocol attacks is a primary capability of the Standard plan → Yes.

In Microsoft’s Security, Compliance, and Identity guidance, multi-factor authentication (MFA) is based on combining independent categories of credentials to verify a user. Microsoft describes the three factor types as: something you know (knowledge), something you have (possession), and something you are (inherence). A password is explicitly categorized as “something you know,” because it relies on a secret the user memorizes and types during sign-in. MFA improves security by requiring two or more of these distinct factors—e.g., a password (know) plus a phone approval or hardware token (have), or a biometric like Windows Hello (are). Using factors from different categories mitigates common attacks such as password spray, credential stuffing, and phishing, because compromising one factor (for example, the password) does not grant access without the second, unrelated factor. Microsoft recommends enabling MFA broadly and pairing passwords with stronger possession or inherence methods to achieve a measurable reduction in account compromise risk. Therefore, in the MFA model used by Microsoft Entra ID (Azure AD), a password is considered something you know.