Free Microsoft SC-900 Practice Exam with Questions & Answers

Microsoft’s security guidance for hybrid and cloud environments adopts the Zero Trust approach, which explicitly positions identity as the primary boundary for access decisions. Microsoft states that in modern, distributed environments, “the traditional network perimeter is no longer sufficient” and that identity becomes the new security perimeter for protecting access to resources across on-premises and cloud. In Zero Trust, access is granted based on who the user or workload is, the risk of the sign-in, the device health, and the context of the session. Microsoft summarizes this shift as: “Identity is the control plane,” emphasizing that authentication, authorization, and continuous evaluation of trust are enforced through identity-centric controls such as Conditional Access, multifactor authentication, Privileged Identity Management, device compliance, and session controls.

While tools like firewalls and services such as Microsoft Defender for Cloud remain important layers in a defense-in-depth strategy, they are not the primary perimeter in a hybrid model. Because users, devices, and applications operate from anywhere, identity is the consistent, verifiable layer through which policy is enforced for both on-premises and cloud resources. Therefore, in an environment that spans on-premises and cloud, Microsoft recommends treating identity as the primary security perimeter, applying continuous verification and least-privilege access through identity-driven policies.

Azure Firewall is a managed, cloud-based network security service designed to secure traffic inside and across Azure Virtual Networks. Microsoft describes Azure Firewall as a stateful firewall that “protects Azure Virtual Network resources” by enforcing network and application rules, central logging, and threat intelligence–based filtering. Because it is deployed into a VNet/subnet (often as the hub in a hub-and-spoke), it directly governs East/West and North/South flows to workloads such as Azure virtual machines and platform services reachable through the VNet, using DNAT/SNAT and rule collections. Microsoft guidance highlights capabilities to “centrally create, enforce, and log application and network connectivity policies across subscriptions and virtual networks,” and to filter traffic for peered VNets, branch connections (VPN/ExpressRoute), and internet traffic. These capabilities explicitly map to protecting Azure virtual networks and the VMs and subnets inside them. In contrast, Azure AD users, Exchange Online inboxes, and SharePoint Online sites are SaaS/identity resources protected by Microsoft Entra controls, Exchange/SharePoint security, and Purview/Defender for Office 365—not by a VNet firewall. Therefore, the Azure Firewall–protectable resource types among the options are Azure virtual machines and Azure virtual networks.

In Microsoft 365 compliance, sensitivity labels (Microsoft Purview Information Protection) are the feature designed to classify and automatically protect data. Microsoft states that sensitivity labels “let you classify and protect your organization’s data” and that a label “can apply protection settings such as encryption” to files and emails. Labels can be deployed so that protection is applied without user action: Microsoft explains that labels “can be applied automatically, recommended, or by users,” and that administrators can “auto-apply a sensitivity label to content in SharePoint, OneDrive, and Exchange based on conditions such as sensitive info types, keywords, or trainable classifiers.” When a label with protection is applied, “encryption settings travel with the content” and enforce usage rights like who can open, print, or forward, even outside the organization.

By contrast, Content Search and eDiscovery are discovery/investigative tools and do not enforce protection. Retention policies manage how long content is kept or deleted, but they don’t encrypt content. Therefore, the Microsoft 365 compliance capability that encrypts content automatically based on specific conditions is sensitivity labels with auto-labeling policies in Microsoft Purview.

When you register an application through the Azure portal, an application object and service principal are automatically created in your home directory or tenant.

Microsoft 365 Insider Risk Management follows a clear operational flow: Triage → Investigate → Action. Microsoft’s guidance explains that the Alerts dashboard is used first to review and filter alerts, prioritize by severity, and decide what needs deeper review—this is the Triage stage. The documentation describes triage activities as reviewing alert details, applying filters, and determining whether an alert should be escalated for investigation.

When an alert warrants deeper inquiry, analysts move to Investigate, where they create cases, add relevant alerts and users, and examine activity timelines and related signals. Microsoft states that cases are the vehicle for structured investigations, allowing analysts to group evidence and manage workflow from the Case dashboard.

After investigation, organizations proceed to Action, where insider risk controls allow response steps such as sending user policy reminders, escalating to HR or legal, or taking other governance actions. Microsoft describes that actions can include notifying the user with a policy reminder to reduce future risk or applying stronger controls, all of which are part of the response phase.

Accordingly, the correct matches are: Triage → Review and filter alerts, Investigate → Create cases in the Case dashboard, and Action → Send a reminder of corporate policies to users.

In Microsoft’s Security, Compliance, and Identity learning content and product documentation, Intune administration is performed in the dedicated Intune portal that, for exam and study-guide purposes, is referred to as the Microsoft Endpoint Manager admin center. Microsoft explains that “Microsoft Intune is a cloud-based service that focuses on mobile device management (MDM) and mobile application management (MAM)” and that “administrators manage Intune in the Intune (Endpoint Manager) admin center, where you configure device enrollment, compliance, apps, and endpoint security.” The admin experience consolidates device, app, and policy management, including device compliance policies, configuration profiles, app protection policies, software update rings, and endpoint security baselines, all from this portal.

By contrast, the Azure Active Directory admin center (Microsoft Entra admin center) is designed for identity and access tasks (users, groups, roles, Conditional Access), not full device/app management. The Microsoft 365 compliance center is focused on data governance and risk (DLP, information protection, eDiscovery, audit), while the Microsoft 365 security center/Defender portal is for security operations and threat protection. Therefore, when the sentence states, “You can manage Microsoft Intune by using the…,” the correct completion—aligned with Microsoft SCI study materials—is Microsoft Endpoint Manager admin center, the portal intentionally built for Intune device and app lifecycle management.

Microsoft Entra ID Identity Protection is a risk-based conditional access capability that “automates the detection and remediation of identity-based risks” and enables admins to investigate risky users and sign-ins. SCI guidance explains that Identity Protection evaluates signals such as user risk and sign-in risk, raises risk detections, and can automatically remediate by enforcing actions like password reset or blocking access via risk-based policies. The portal provides rich investigation experiences for risky users, risky sign-ins, and risk detections, allowing security teams to review evidence and confirm/dismiss risks. In addition, identity risk data can be exported through Azure Monitor/diagnostic settings and integrated with SIEM/SOAR tools, enabling “export of risk detections and security alerts to third-party solutions” for correlation and response. Tasks such as configuring external access for partner organizations are handled by B2B collaboration features, and creating/assigning sensitivity labels belongs to Microsoft Purview Information Protection—not Identity Protection. Therefore, the tasks Identity Protection supports are: export risk detection (B), automate detection and remediation of identity-based risks (C), and investigate risks related to user authentication (D).

Microsoft states that Identity Protection is used to “detect potential vulnerabilities affecting your organization’s identities, configure automated responses, and investigate suspicious actions related to your organization’s identities.” It evaluates user risk and sign-in risk using detections such as “leaked credentials, anonymous IP address, unfamiliar sign-in properties, [and] impossible travel.” These built-in detections confirm that the service can detect whether valid user credentials have been found in public or criminal datasets—commonly referred to as leaked credentials—thereby reducing identity compromise risk.

Identity Protection includes policy controls that “automate the response to detected risks,” specifically the User risk policy and Sign-in risk policy. Microsoft describes that these policies can “require password change when user risk is detected” and “require multi-factor authentication when sign-in risk is detected.” Therefore, Identity Protection can invoke MFA based on risk as part of Conditional Access–backed risk policies.

However, Identity Protection does not perform group lifecycle management. Microsoft positions group membership automation under Azure AD dynamic groups/Identity Governance, not Identity Protection. Consequently, adding users to groups based on risk level is not a function of Identity Protection, which focuses on detection, risk evaluation, and policy-driven remediation (e.g., MFA or password reset), not group assignment.

Microsoft states that Security defaults are baseline protections in Azure Active Directory (now Microsoft Entra ID) that “make it easier to help protect your organization from identity-related attacks.” One of the core behaviors is that security defaults “require all users to register for Azure AD Multi-Factor Authentication,” and enforce “multi-factor authentication for all users,” with special emphasis that “administrators are required to do multi-factor authentication.” Security defaults also “block legacy authentication” and add protections for privileged operations, but the universal control that applies to every user is MFA. Importantly, enabling security defaults does not turn on paid capabilities such as Azure AD Identity Protection or Privileged Identity Management (PIM); those are separate, premium features. The baseline is intentionally simple and tenant-wide: require MFA registration, challenge with MFA when risk or sensitive operations are detected, and reduce exposure by disabling legacy protocols. Therefore, when you enable security defaults, multi-factor authentication (MFA) will be enabled for all Azure AD users, aligning with Microsoft’s guidance that security defaults “help protect all organizations by requiring MFA and disabling legacy authentication.”

Microsoft’s identity guidance classifies social identity services (e.g., GitHub, Google, Facebook) as cloud-based identity providers that can be used for external identities with Microsoft Entra ID. In this model, GitHub functions as an IdP using OAuth/OpenID Connect to authenticate users and issue tokens that applications or Entra ID can accept. Federation in Microsoft terms is the trust relationship that allows SSO across organizational boundaries and with multiple identity providers, such as Active Directory Federation Services (AD FS), SAML, or OpenID Connect providers, so users can authenticate once and access multiple apps without repeated sign-ins.

Crucially, SCI materials distinguish roles: an identity provider primarily handles authentication (proving who the user is and issuing claims/tokens). Authorization—deciding what the user can do—is enforced by the application or resource (often using roles/claims from the IdP). Auditing spans multiple planes: the IdP provides sign-in and audit logs, while applications and other services maintain their own activity logs. Therefore, it is incorrect to say a central IdP “manages all modern authentication services” including authorization and auditing; those responsibilities are shared across the identity platform and the relying applications/resources.