Pass the Microsoft Microsoft Certified: Security Compliance and Identity Fundamentals SC-900 Questions and answers with CertsForce

Microsoft Learn explains that Azure Active Directory (now Microsoft Entra ID) is a Microsoft-managed identity and access management service delivered from the cloud. It does not require you to provision or host infrastructure such as virtual machines; the directory is operated as a service by Microsoft, and tenants are created and administered within Microsoft’s cloud environment. The official learning paths further clarify that administration is performed through the Azure portal (the Entra/Microsoft Entra admin center and Azure portal blades), PowerShell, and Graph—so managing a tenant in the Azure portal is fully supported.

Regarding licensing, Microsoft’s SCI study materials detail that Azure AD/Entra ID is offered in multiple editions (Free, Microsoft 365 apps edition, Premium P1, and Premium P2). Each edition unlocks different capabilities: for example, features like Conditional Access are in Premium tiers; Identity Protection and Privileged Identity Management (PIM) are P2 capabilities. Because capabilities vary by tier, the statement that all license editions include the same features is incorrect.

Putting this together: feature parity across editions is not the case (No); tenant management in the Azure portal is supported (Yes); and you do not need to deploy Azure VMs to host an Azure AD/Entra ID tenant (No).

Microsoft Entra Conditional Access evaluates signals to make real-time access decisions. Microsoft describes it as bringing “signals together to make decisions and enforce organizational policies,” where administrators choose controls such as Block access, Require multi-factor authentication, Require device to be marked as compliant, or Require hybrid Azure AD joined device. Because MFA is only one of several grant controls, it is incorrect that policies always enforce MFA; they can also simply block, allow, or require other conditions.

Location is a first-class condition. Microsoft states you can define named locations (by countries/regions or IP ranges) and then use them in policy conditions to block or grant access. A common scenario is “Block access from specific locations” or require additional controls when a sign-in originates from an untrusted network. Therefore, Conditional Access can block access to an application based on user location.

Finally, Conditional Access targets users, groups, workload identities, and cloud apps regardless of device join state. Device-related conditions and filters are optional; policies are not limited to “Azure AD-joined devices.” Controls like Require device to be marked as compliant or Require Hybrid Azure AD joined device are only enforced if configured. Hence, Conditional Access does not only affect users on Azure AD-joined devices.

 An external email address can be used to authenticate self-service password reset (SSPR). → Yes

 A notification to the Microsoft Authenticator app can be used to authenticate self-service password reset (SSPR). → Yes

 To perform self-service password reset (SSPR), a user must already be signed in and authenticated to Azure AD. → No

For Microsoft Entra self-service password reset (SSPR), users must register one or more authentication methods that can later be used when they forget their password or are locked out. Microsoft’s end-user guidance states that an email address option lets users configure “an alternate email address that can be used without requiring your forgotten or missing password,” and that this method is available only for password reset. In practice, this alternate address is typically a personal or external email (for example, Gmail), so using an external email to authenticate SSPR is valid.

SSPR can also use the Microsoft Authenticator app as an authentication method. Microsoft documents that Authenticator push notifications, including number matching, are supported for several scenarios, explicitly listing self-service password reset (SSPR) among them. This means a push notification to the app on the user’s device can be used to verify identity during SSPR.

Finally, SSPR is designed for situations where the user cannot sign in. Official SSPR process descriptions explain that users start from the “Can’t access your account?” or password-reset page, provide their username, and then use their registered methods to prove identity. They do not need to be already authenticated to Azure AD; SSPR exists precisely to recover access when sign-in fails.

Conditional Access session controls enable user app access and sessions to be monitored and controlled in real time based on access and session policies.

Based on this definition, the best answer for your question is B. enable limited experiences, such as blocking download of sensitive information.

https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/concept-conditional-access-session

In Microsoft Purview Information Protection, sensitivity labels are the core mechanism to classify and protect content. The Microsoft SCI learning content explains that a sensitivity label can “apply protection such as encryption and rights restrictions to files and emails,” allowing you to define who can access the content and what they can do (view, edit, print, forward). When you configure a label with Encrypt settings, the service uses Azure Rights Management to enforce protection persistently, so the encryption travels with the file wherever it goes.

Labels can also apply content marking. The official guidance states that labels can “add visual markings—headers and footers—to Office files and email to make the sensitivity of content obvious.” This is commonly used to stamp messages and documents with text such as Confidential or Internal. SCI materials further clarify that labels can apply watermarks to Office documents (Word, Excel, PowerPoint) as part of content marking, but watermarks are not applied to email messages; only headers and footers are supported for email.

Putting it together: encryption (Yes) and headers/footers on documents (Yes) are supported label actions. Watermarks are supported for documents but not for email, so “Sensitivity labels can apply watermarks to emails” is No.

No

No

Yes

Microsoft states that Communication Compliance is administered in Microsoft Purview, not the Microsoft 365 admin center. The Learn article shows configuration and policy templates “in the Microsoft Purview portal” and directs admins to “configure Communication Compliance” there, confirming the management plane is the Purview compliance portal, not the M365 admin center.

Regarding supported locations, Microsoft lists the communication channels that policies can inspect: “Microsoft Teams… Exchange Online… Viva Engage… [and] Third-party sources.” SharePoint Online is not listed among supported channels, so SharePoint content isn’t monitored by Communication Compliance policies.

Finally, Communication Compliance includes built-in workflows to address findings. The Learn page explicitly provides a Remediate step: “Remediate Communication Compliance issues you investigate by using the following options:” such as “Notify the user” and “Escalate to another reviewer.” These actions demonstrate that the solution does more than detect; it supports remediation within the Purview portal workflow.

Exact extracts (selected):

“You can choose from the following policy templates in the Microsoft Purview portal.”

“Communication Compliance policies check… Microsoft Teams… Exchange Online… Viva Engage… Third-party sources.”

“Remediate Communication Compliance issues you investigate by using the following options: Notify the user… Escalate to another reviewer.”

Microsoft defines hybrid identity as enabling a common identity across on-premises and cloud by integrating your directory services. Microsoft Learn states: “Hybrid identity is achieved by integrating your on-premises Active Directory with Azure Active Directory.” This integration is delivered through the synchronization and optional federation capabilities that connect AD DS to Azure AD so users can access both on-premises and cloud resources with one identity.

To implement this integration, Microsoft’s tooling is explicit: “Azure AD Connect is the Microsoft tool designed to meet and accomplish your hybrid identity goals.” Azure AD Connect (now Microsoft Entra Connect) synchronizes users, groups, and optionally passwords or hashes to Azure AD, providing the foundation for hybrid scenarios such as single sign-on and seamless sign-in.

Regarding tenants, Microsoft’s identity platform clarifies that “A Microsoft 365 organization is associated with a single Azure AD tenant.” Therefore, a hybrid identity deployment does not require two Microsoft 365 tenants; it typically links a single Azure AD (Microsoft Entra ID) tenant with one or more on-premises AD DS forests. In summary, Azure AD Connect enables hybrid identity, hybrid identity is the synchronization/integration of AD DS with Azure AD, and it does not necessitate multiple Microsoft 365 tenants.

The recommended way to enable and use Azure AD Multi-Factor Authentication is with Conditional Access policies. Conditional Access lets you create and define policies that react to sign-in events and that request additional actions before a user is granted access to an application or service.

Microsoft Entra Permissions Management is Microsoft’s cloud infrastructure entitlement management (CIEM) solution delivered in the Microsoft Entra admin center, not in the Microsoft Purview compliance portal. Microsoft guidance describes it as a CIEM service that provides “centralized visibility, right-sizing, and governance of permissions across clouds” and is accessed and administered from the Entra portal under Permissions Management. The Purview compliance portal is used for compliance solutions such as Compliance Manager, Information Protection, DLP, eDiscovery, and Insider Risk—not CIEM—so statement 1 is No.

Permissions Management supports multicloud environments. Microsoft documentation states that it “discovers, monitors, and manages permissions for identities and resources across Microsoft Azure, Amazon Web Services (AWS), and Google Cloud Platform (GCP).” It calculates a Permission Creep Index (PCI), surfaces excessive permissions, and recommends remediation across these clouds; therefore, using it to manage permissions in AWS is supported—statement 2 is Yes.

Regarding secure scores: Permissions Management focuses on entitlements (e.g., effective permissions, PCI, right-sizing actions). Microsoft Secure Score (and Identity Secure Score) are separate posture metrics exposed in Microsoft 365 Defender and Microsoft Entra ID, respectively. The Permissions Management blade does not present Microsoft Secure Score; instead, it shows CIEM-specific insights and PCI. Consequently, the claim that Secure Score can be reviewed from Permissions Management in the Entra admin center is No.

In Microsoft Sentinel, automation of routine or repetitive SOC tasks is delivered through playbooks. Microsoft’s Sentinel guidance defines playbooks as “collections of procedures that can be run from Microsoft Sentinel in response to an alert or incident.” They are “built on Azure Logic Apps” and enable teams to “automate and orchestrate responses to threats” such as enriching incidents, opening tickets, notifying responders, quarantining entities, or blocking indicators. The documentation further clarifies that automation rules can “trigger playbooks automatically based on analytics alerts or incident conditions,” allowing consistent, scalable actions without manual intervention. By contrast, workbooks provide “data visualization and reporting” for analysis; hunting search-and-query tools (built on KQL) are used to “proactively hunt for threats”; and deep investigation tools assist analysts during incident investigation. Therefore, when the goal is to automate common tasks—for example, sending incident notifications, enriching with threat intelligence, or creating tickets in ITSM—the correct capability in Microsoft Sentinel is playbooks, because they encapsulate repeatable response procedures and can be executed automatically via automation rules or manually from incidents, alerts, or entities.