Practice Test #2

Correct answer: B. With Windows Hello for Business, a user’s biometric data (the biometric template) is stored on the local device only. The biometric is used as a local gesture to unlock a cryptographic key (typically protected by the TPM). Azure AD/Entra ID does not receive or store the biometric template; it only has the associated public key information needed to validate authentication. Why the others are wrong: A is incorrect because WHfB does not store biometric data on an external device as the standard model; the template is kept on the device where enrollment occurred. C is incorrect because Azure AD does not store biometric templates; storing biometrics centrally would increase privacy and breach risk. D is incorrect because biometric templates are not replicated across a user’s devices. Each device has its own local biometric enrollment and its own key material registration.

Correct answer: B. an identity provider. Azure Active Directory (Azure AD), now branded as Microsoft Entra ID, is Microsoft’s cloud identity provider (IdP) and identity and access management service. It performs authentication (validating credentials and sign-in) and supports authorization by issuing security tokens (for example, OAuth 2.0/OpenID Connect/SAML tokens) containing claims that applications and Azure services use to grant access. It also integrates with Conditional Access, MFA, and RBAC to enforce access decisions. Why the others are wrong: A (XDR system): XDR (e.g., Microsoft Defender XDR) correlates and responds to threats across endpoints, identities, email, and apps; it is not the service that authenticates users. C (management group): Management groups are an Azure governance hierarchy for organizing subscriptions and applying policy/RBAC at scale; they don’t provide authentication. D (SIEM system): SIEM (e.g., Microsoft Sentinel) collects and analyzes logs/events for security monitoring and incident response; it doesn’t act as the IdP for sign-in and token issuance.

Correct answer: D. Incidents. In Microsoft 365 Defender, an incident is the primary container used to group and correlate multiple alerts that are determined to be part of the same attack or campaign. The incident view provides an aggregated “attack story,” showing related alerts, affected entities (users/devices/mailboxes), evidence, severity, and recommended remediation steps. This is exactly what the prompt describes: “an aggregation of alerts that relate to the same attack.” Why the others are wrong: - A. Reports: Reports provide dashboards and analytics (trends, volumes, security posture) but do not serve as the operational aggregation object for related alerts. - B. Hunting: Advanced hunting is for proactive investigation using queries (KQL) across telemetry; it helps you discover suspicious activity but does not automatically aggregate alerts into a single case. - C. Attack simulator: Used for simulated attacks (for example, phishing simulations) to train users and assess readiness, not for correlating real alerts from an active attack.

Azure AD (Microsoft Entra ID) Identity Protection does not add users to groups based on risk level. Identity Protection’s role is to detect and calculate risk (user risk and sign-in risk) and then enable administrators to respond using policies and workflows—most commonly via Conditional Access. Group membership automation is handled by other features, such as Entra ID dynamic groups (rule-based attributes like department, job title, etc.) or Identity Governance capabilities. Risk level is not used as a native rule to automatically place users into groups, and Identity Protection does not provide an action like “move user to high-risk group.” Why “Yes” is wrong: it confuses risk-based access enforcement (Conditional Access actions like require MFA/block) with identity lifecycle/governance functions (group assignment). In exam terms, think: Identity Protection = detect risk + feed Conditional Access; group management = Entra ID groups/governance.

Azure AD (Microsoft Entra ID) Identity Protection can detect leaked credentials. One of the built-in risk detections is “Leaked credentials,” where Microsoft uses threat intelligence and monitoring of publicly available sources (often described as the public web/dark web) to find exposed username/password pairs. If those credentials match accounts in your tenant, Identity Protection raises the user risk. This is a detection capability, not merely a reporting feature: it contributes to the user risk score and can trigger remediation actions (for example, force password reset through a user risk policy or Conditional Access). Why “No” is wrong: it would imply Identity Protection only detects anomalous sign-ins (like impossible travel) but not credential exposure. In reality, leaked credentials is a core Identity Protection detection and a common SC-900 concept tied to preventing account takeover.

Azure AD (Microsoft Entra ID) Identity Protection can be used to invoke Multi-Factor Authentication based on a user’s risk level by integrating with Conditional Access. In practice, you configure Conditional Access policies that use Identity Protection risk signals (user risk and/or sign-in risk) as conditions. When the risk meets a configured threshold (for example, medium or high), the policy can require MFA as a control. This is a key exam point: Identity Protection provides the risk assessment; Conditional Access enforces the response (require MFA, block access, require password change, etc.). Together they implement adaptive access aligned with Zero Trust. Why “No” is wrong: it overlooks the standard design pattern where risk-based Conditional Access uses Identity Protection signals. Even though Identity Protection itself isn’t the MFA provider, it is explicitly used to trigger MFA requirements through Conditional Access based on risk.

Yes. “Azure Defender” (now Microsoft Defender for Cloud’s workload protection plans) includes protection for Azure Storage. The Defender for Storage plan provides threat detection for suspicious activities such as unusual access patterns, potential data exfiltration, and malicious uploads, and it can surface security alerts related to Storage accounts. In addition, Defender for Cloud can identify certain security issues related to storage configuration (for example, overly permissive access settings) as part of posture management recommendations. Why not No: Storage is one of the core Azure resource types with a dedicated Defender plan. The exam often expects you to recognize that Defender for Cloud is not limited to VMs; it also covers PaaS services like Storage, SQL, and Kubernetes with specific threat detection capabilities (CWP).

Yes. Microsoft Defender for Cloud provides Cloud Security Posture Management (CSPM) capabilities for Azure subscriptions, including secure score, security recommendations, and policy-based assessment of resources. At the SC-900 level, this is treated as being available across Azure subscriptions once Defender for Cloud is used for that subscription. The statement is about Azure subscriptions specifically, not advanced multicloud or premium CSPM features. Therefore, No is incorrect because it overcomplicates the basic product capability being tested.

Yes. Azure Security Center (now Microsoft Defender for Cloud) can evaluate the security of workloads in Azure and extend to on-premises environments. For Azure resources, it natively assesses posture and can provide recommendations and secure score. For on-premises (and other clouds), you can onboard servers using agents and/or Azure Arc-enabled servers, allowing Defender for Cloud to collect security signals, assess configurations, and (with appropriate plans) provide threat protection. Why not No: A common exam concept is that Defender for Cloud is a cloud-native security management tool that supports hybrid scenarios. It is not restricted to Azure-only workloads; it can provide unified security management across Azure and non-Azure environments when those resources are connected/onboarded.