SC-900 Practice Questions

Microsoft’s Zero Trust guidance in the Security, Compliance, and Identity (SCI) materials frames three core principles: “Verify explicitly,” “Use least-privilege access,” and “Assume breach.” The guidance explains that identity is the new control plane in cloud-based environments: identity becomes the primary security boundary, with access decisions evaluated continuously using signals such as user identity, device health, location, and risk. In Zero Trust, organizations must “verify explicitly”—that is, require strong authentication and explicit authorization for every access request, not just initial logon, and base decisions on the permissions and context presented. The model also directs organizations to “assume breach”, operating with the expectation that an attacker may already be inside the environment and therefore applying containment practices such as micro-segmentation, telemetry, and rapid detection and response. Conversely, the traditional notion of defining the perimeter by physical locations or network boundaries is explicitly rejected; the documentation emphasizes that network location is no longer a reliable trust signal and should not be treated as the primary boundary. Therefore, the statements that align with Microsoft’s Zero Trust principles are: Use identity as the primary security boundary (B), Always verify user permissions explicitly (C), and Always assume the user/system can be breached (D).

In the Microsoft Cloud Adoption Framework (CAF) for Azure, the methodology is organized into sequential stages that guide an organization from initial intent through operations. Microsoft describes the flow as: “Strategy → Plan → Ready → Adopt → Govern → Manage.” The guidance explains that before building landing zones or preparing environments (Ready), organizations should complete the Strategy and Plan work. Microsoft states that the framework “helps you create and align your business strategy, define business outcomes, and justify cloud adoption” in the Strategy stage; then, in Plan, you “translate that strategy into an actionable adoption plan, rationalize portfolios, and prepare a cloud adoption backlog.” Only after these two stages does the Ready phase occur, where you “prepare your cloud environment (landing zone) to host the workloads.”

Additionally, CAF emphasizes that Govern and Manage are ongoing disciplines that operate alongside and after adoption rather than preceding Ready: “Govern and Manage provide iterative guardrails and operational baselines that evolve as you adopt more workloads.” Therefore, the two phases addressed before the Ready phase are Define Strategy and Plan, aligning with Microsoft’s prescribed order and intent of the Cloud Adoption Framework methodology.

Microsoft Entra Conditional Access (CA) evaluates signals from the user, device, location, and risk to make access decisions. The platform explicitly notes that CA decisions occur after primary sign-in: “Conditional Access policies are enforced after the first-factor authentication has been completed.” This means a user must successfully present their initial credentials (e.g., password, Windows Hello, FIDO2) before the CA engine evaluates policy logic. Therefore, the statement that CA is evaluated before a user is authenticated is not correct.

Regarding scoping, CA can target ordinary and privileged identities. The assignment options allow administrators to aim policies at users, groups, and directory roles: “You can include or exclude users and groups… [and] include or exclude specific Azure AD directory roles from a Conditional Access policy.” Because Global Administrator is a directory role, policies can be applied to those accounts (with Microsoft’s best-practice guidance to maintain at least one excluded break-glass account to prevent lockout).

For signals/conditions, CA supports device platform filtering. The documented device platform condition states: “This condition is based on the operating system platform of the device… iOS, Android, Windows, macOS (and others).” Administrators commonly use this to require different controls (like MFA or compliant device) based on Android or iOS.

Putting these together:

CA can apply to Global Administrators (Yes).

CA is evaluated after first-factor authentication (No to “before”).

Device platform (e.g., Android/iOS) is a valid CA signal (Yes).

access

In Microsoft Entra ID (formerly Azure AD), dynamic groups are a key feature used to automate the access lifecycle for users and devices. SCI learning material on identity governance explains that organizations can automate the access lifecycle process through technologies such as dynamic groups, alongside automated user provisioning. These resources describe the access lifecycle as managing a user’s access to resources from the moment they join the organization, through role or department changes, until they leave. Dynamic groups help with this by using attribute-based rules (for example, department, job title, location, or device platform) to automatically add or remove identities from groups as their attributes change.

Because group membership typically controls access to applications, SharePoint sites, Teams, and licenses, this automatic membership update keeps access aligned with the user’s current role without manual intervention. When a user changes departments, the dynamic rules reevaluate and move them into the appropriate groups, granting new access and removing old access as required. This is exactly what Microsoft refers to as automating the access lifecycle.

The other options do not match the terminology used in SCI content: “object lifecycle” is not the term used in Entra identity governance, and “privileged access” lifecycle is handled specifically by Privileged Identity Management (PIM), not by dynamic groups. Therefore, the sentence is correctly completed with access.

Microsoft defines Microsoft Entra ID (formerly Azure Active Directory) as “a cloud-based identity and access management (IAM) service” that “helps your employees sign in and access resources.” In SCI learning paths, Entra ID is positioned as the tenant’s identity provider (IdP) that authenticates users and issues tokens for applications using standards such as OpenID Connect, OAuth 2.0, and SAML, which applications then use to authorize access based on roles/claims. Microsoft further explains that Entra ID provides single sign-on, Conditional Access, MFA, and token-based authorization—all core IdP capabilities that govern who can access what across Microsoft 365, Azure, and thousands of SaaS apps.

By contrast, an extended detection and response (XDR) system refers to Microsoft Defender XDR, which focuses on incident detection, correlation, and response—not identity provisioning or token issuance. A security information and event management (SIEM) system refers to Microsoft Sentinel, which aggregates and analyzes logs and alerts—not primary authentication. An Azure management group is a governance scope used to organize subscriptions and apply policy/RBAC at scale; it is not an authentication/authorization service. Therefore, within Microsoft’s SCI scope, Microsoft Entra ID is an identity provider used to perform authentication (verifying identity and issuing tokens) and to enable authorization in applications and resources that consume those tokens.