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

Microsoft’s hybrid identity guidance explains that Microsoft Entra Connect (formerly Azure AD Connect) is the tool used to synchronize identities from on-premises AD DS to a Microsoft Entra tenant, enabling hybrid identity. Microsoft states that hybrid identity is achieved by connecting your on-premises directory with your cloud directory so users have a single identity to access both environments. This does not require two Microsoft 365 tenants; rather, it requires one Microsoft Entra tenant integrated with your on-premises AD DS. For authentication models—Password Hash Synchronization (PHS), Pass-through Authentication (PTA), or federation (AD FS)—Microsoft specifies that directory synchronization is required so that user objects exist in Entra ID and can authenticate to cloud services while maintaining a consistent identity. Thus, Entra Connect is used to implement the synchronization underpinning hybrid identity; two M365 tenants are unnecessary; and synchronization between AD DS and Entra ID is required for authenticating hybrid identities across Microsoft cloud services.

Microsoft’s Conditional Access (part of Microsoft Entra ID) evaluates multiple signals to make access decisions. The official description lists typical signals such as “user or group membership, IP location information, device state, application, and real-time risk.” The device state element explicitly refers to conditions like “compliant or hybrid Azure AD joined devices,” allowing policies that grant or block access—or require extra controls—based on whether a device meets compliance/registration requirements.

Regarding evaluation timing, Microsoft’s guidance states that Conditional Access “policies are enforced after the first-factor authentication is completed.” This means the engine needs the user’s primary sign-in context (who the user is and how they authenticated) to evaluate the conditions and then decide whether to allow, block, or require additional controls. Therefore, the statement that policies apply before first factor is not correct.

Finally, Conditional Access includes grant controls such as “Require multi-factor authentication,” and policies can be scoped to specific cloud apps or actions. As a result, you can target a particular application and require MFA when a user attempts to access it, satisfying application-specific risk mitigation while preserving user productivity.

In Microsoft’s SCI guidance, encryption at rest is defined as protecting data when it is stored on a disk or other persistent media. Microsoft describes it as controls that “help safeguard your data to meet your organizational security and compliance commitments by encrypting data when it is persisted,” distinguishing it from protections for data in transit. Within Azure and Microsoft 365, examples include Azure Disk Encryption for IaaS VMs (using BitLocker for Windows and DM-Crypt for Linux), server-side encryption for storage accounts, and Transparent Data Encryption for databases. A virtual machine’s OS and data disks encrypted with BitLocker or DM-Crypt are canonical cases of at-rest encryption because the encryption keys protect the physical media; the data becomes unreadable if the disks are accessed outside the authorized context. By contrast, site-to-site VPN, HTTPS web sessions, and encrypted email protect data in transit—they secure network communications but do not encrypt the data where it is stored. Therefore, among the options provided, encrypting a virtual machine disk is the correct example of encryption at rest in Microsoft’s security model.

The Content Search tool in the Security & Compliance Center can be used to quickly find email in Exchange mailboxes, documents in SharePoint sites and OneDrive locations, and instant messaging conversations in Skype for Business.

The first step is to starting using the Content Search tool to choose content locations to search and configure a keyword query to search for specific items.

In Microsoft Azure, an NSG consists of ordered security rules evaluated by priority. The Azure documentation specifies that every rule includes identifying metadata and must be uniquely named within the NSG: “Each security rule has a name that is unique within the network security group.” Rule evaluation is deterministic: “Security rules are processed in priority order… once a rule matches traffic, processing stops.”

Azure creates several default security rules in every NSG to provide a safe baseline. These defaults are protected: “You can’t remove the default security rules, but you can override them by creating rules with a higher priority.” This means deletion of default rules is not allowed; administrators add custom rules with lower priority numbers to supersede the defaults as needed.

Regarding protocols, NSG rules can target specific L4/L3 protocols. The platform guidance states that the rule Protocol field supports TCP, UDP, ICMP, or Any: “For Protocol, specify TCP, UDP, ICMP, or Any.” Therefore, configuring rules to check TCP, UDP, or ICMP traffic types is fully supported.

Putting this together: (1) unique rule names are required (Yes), (2) default rules cannot be deleted (No), and (3) NSG rules can indeed be configured for TCP/UDP/ICMP (Yes). These behaviors align with Azure’s prescribed NSG design and management model used across Microsoft Security, Compliance, and Identity learning content.

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.

In Microsoft’s security portfolio, Microsoft Defender for Cloud is the service that provides cloud workload protection for Azure and hybrid cloud resources. Microsoft describes it as a “cloud-native application protection platform (CNAPP) that helps strengthen the security posture of your cloud resources and protect workloads across multicloud and hybrid environments.” The service delivers Cloud Security Posture Management (CSPM) and Cloud Workload Protection (CWP) by continuously assessing configurations and protecting workloads such as virtual machines, containers, databases, and storage. Documentation further states that Defender for Cloud “provides threat protection for workloads running in Azure, on-premises, and in other clouds,” giving a single pane to harden resources, detect active threats, and remediate.

By contrast, Azure Monitor focuses on telemetry and observability; the Microsoft cloud security benchmark is a set of prescriptive best practices; and Microsoft Secure Score is an aggregate metric reflecting security posture. None of those deliver the workload protection and active defense capabilities (e.g., recommendations, hardening, and threat detection for servers, containers, and PaaS services) that Defender for Cloud offers. Therefore, the sentence correctly completes as: Microsoft Defender for Cloud provides cloud workload protection for Azure and hybrid cloud resources.

In Microsoft 365 Defender, security signals from across Microsoft 365 services are raised as alerts. Microsoft’s documentation defines an incident as “a collection of correlated alerts” that represent the end-to-end story of an attack. The incident object aggregates the related signals, entities, and evidence so analysts can triage and remediate holistically rather than handling individual alerts in isolation. Microsoft further explains that incidents “group together related alerts, assets, users, and evidence” to reduce noise and provide context for investigation, and that automated correlation “helps SOCs focus on what matters most” by stitching alerts from Defender for Endpoint, Defender for Office 365, Defender for Identity, and Microsoft Defender for Cloud Apps into one case. Within an incident, analysts see a timeline, impacted assets and users, alert details, and recommended actions, and they can trigger response measures (for example, isolate device, block URL/file, or disable user). This contrasts with events (raw telemetry), vulnerabilities (exposure findings managed by Defender Vulnerability Management), and Microsoft Secure Score improvement actions (posture recommendations). Therefore, in the Microsoft 365 Defender portal, an incident is specifically a collection of correlated alerts, designed to streamline investigation and coordinated remediation across the Microsoft 365 security stack.

Microsoft’s SCI learning content describes the Microsoft 365 Defender portal as a unified security operations experience that surfaces security posture and active threats on a card-based dashboard. In the overview of the portal, Microsoft explains that the home page “presents key security information in dashboard cards,” and that among these cards are summaries that highlight risky entities such as “Users at risk” and “Devices at risk.” These cards provide quick, actionable visibility for analysts by aggregating detections and exposure data across Microsoft Defender services (for identities and endpoints). The guidance emphasizes that the portal “correlates signals across identities, endpoints, email, and applications” and that security teams can use the dashboard cards to pivot directly into incidents and investigations from “Users at risk” or “Devices at risk” to take containment or remediation actions.

By contrast, Compliance Score is part of Microsoft Purview Compliance Manager, not the Microsoft 365 Defender portal; Service Health and User Management are functions of the Microsoft 365 admin center. Therefore, the cards you’ll find on the Microsoft 365 Defender portal that match the choices provided are Users at risk and Devices at risk.