Microsoft SC-900

Correct answer: C (The Microsoft Cloud Adoption Framework for Azure). The Cloud Adoption Framework (CAF) is explicitly designed to provide best practices, guidance, and tools for adopting and deploying workloads in Azure. It includes structured methodologies (Strategy, Plan, Ready, Adopt, Govern, Manage) and practical resources such as landing zone guidance, governance and management best practices, and organizational alignment recommendations. The wording “best practices from Microsoft employees, partners, and customers” strongly matches CAF’s purpose and positioning. Why the others are wrong: - A (Azure Blueprints) is a governance/deployment mechanism that helps you orchestrate and repeat deployments of compliant environments by bundling artifacts (policies, role assignments, templates). It is not primarily a best-practices guidance library. - B (Azure Policy) is an enforcement and compliance evaluation service that applies rules to resources (audit/deny/modify). It doesn’t provide broad adoption best practices. - D (A resource lock) is a protective control to prevent accidental deletion or modification of resources; it provides no deployment guidance or best-practice framework.

Federation is used to establish a trust relationship between organizations. In a federated setup, one organization (the relying party/service provider) trusts another organization’s identity provider to authenticate users and issue security tokens (claims). This trust allows users to sign in using their home organization’s credentials while accessing resources in the other organization, enabling cross-organization SSO. Why the other options are incorrect: A (MFA): Multi-factor authentication is a control that can be enforced within an identity system, but federation itself does not “establish MFA.” MFA can be required in either organization, yet it’s not the defining purpose of federation. C (user account synchronization): Synchronization copies or aligns identity objects between directories (e.g., Entra Connect syncing from AD DS). Federation avoids needing to synchronize passwords by relying on token-based trust. D (VPN connection): A VPN provides network-level connectivity. Federation is an identity/authentication mechanism and works independently of VPNs.

Yes. “Control” is a key Microsoft privacy principle. In Microsoft privacy guidance, control refers to giving customers and individuals meaningful choices and the ability to manage how their data is collected, used, and shared. In a cloud context, this shows up as capabilities such as configuring privacy settings, managing data retention, choosing where data is stored (where applicable), and using tools to access, export, or delete data. Why not No: Microsoft explicitly positions customer control as foundational to privacy—customers should be able to determine how their data is handled and to configure services accordingly. This is distinct from security controls (like MFA) because the emphasis is on privacy choices and data handling, not only protection from threats.

Yes. “Transparency” is a key Microsoft privacy principle. Transparency means Microsoft communicates clearly about privacy practices—what data is collected, why it is collected, how it is used, how long it is retained, and with whom it may be shared. This is commonly reflected through privacy statements, product documentation, audit/compliance documentation, and service-specific disclosures. Why not No: Transparency is repeatedly emphasized in Microsoft’s privacy posture because it enables informed decision-making and supports compliance obligations (for example, notice requirements under GDPR). In exam terms, transparency is a privacy principle, whereas items like threat protection or identity governance are security/identity capabilities rather than privacy principles.

No. “Shared responsibility” is not a Microsoft privacy principle; it is a cloud service model concept (shared responsibility model) describing how responsibilities for security and compliance are divided between Microsoft (cloud provider) and the customer. For example, Microsoft is responsible for the security of the cloud (physical datacenters, core infrastructure), while customers are responsible for security in the cloud (identity configuration, data classification, access management, endpoint security, etc.), depending on IaaS/PaaS/SaaS. Why not Yes: Although shared responsibility strongly influences privacy outcomes (customers must configure services appropriately to meet privacy obligations), Microsoft does not list “shared responsibility” as a privacy principle. It is taught under cloud security/compliance fundamentals, not as a privacy commitment like control or transparency.

Correct answer: D. Encrypting. Encrypting a file converts readable plaintext into unreadable ciphertext using an encryption algorithm and a cryptographic key. Only viewers (users, services, or applications) that have the appropriate key (and permission to use it) can decrypt the file and make the data readable and usable again. This directly matches the sentence’s wording: “readable and usable to viewers that have the appropriate key.” Why the other options are wrong: - A. Archiving: Typically bundles files and/or moves them to long-term storage (for retention, backup, or compliance). Archived data may still be readable without any key unless it is also encrypted. - B. Compressing: Reduces file size by encoding data more efficiently. Compressed files are still readable by anyone who can decompress them; no cryptographic key is inherently required. - C. Deduplicating: Eliminates duplicate data blocks to save storage. It changes how data is stored, not who can read it. Exam tip: if a question mentions “key,” “ciphertext,” “decrypt,” or “only authorized viewers can read,” it’s pointing to encryption.

Yes. You can create custom roles in Azure Active Directory (Microsoft Entra ID). These are commonly referred to as custom directory roles. They allow you to define a role with a specific set of permissions (directory-level permissions) rather than relying only on built-in roles like User Administrator or Security Administrator. This supports least privilege by granting only the exact permissions required for a job function. Why “No” is incorrect: Entra ID is not limited to only built-in roles. While many organizations start with built-in roles, custom roles are available to meet more granular administrative needs. Note the common exam trap: don’t confuse Entra ID custom directory roles with Azure RBAC custom roles. Both exist, but they apply to different scopes (directory vs Azure resources). The statement is still true because it explicitly says “in Azure AD.”

Yes. Global administrator is a role in Azure Active Directory (Microsoft Entra ID). It is the highest-privileged directory role and has broad permissions across the tenant, including managing users, groups, app registrations, and many tenant-wide settings. Because of its power, best practice is to minimize the number of Global administrators, use dedicated admin accounts, and protect them with strong authentication (MFA) and privileged access controls. Why “No” is incorrect: Global administrator is one of the most fundamental built-in Entra ID roles and is frequently referenced in Microsoft identity documentation and exam objectives. Another common confusion is with Azure subscription roles (Owner/Contributor), but Global administrator is specifically a directory role, not an Azure resource RBAC role.

No. An Azure AD (Microsoft Entra ID) user can be assigned multiple roles. Role assignments are not limited to a single role per user. For example, a user could be both a User Administrator and an Application Administrator, or hold additional roles for security and compliance operations. This flexibility supports real-world operational needs but must be governed carefully to avoid excessive privilege. Why “Yes” is incorrect: Entra ID role-based access is designed to be additive. Limiting users to only one role would be impractical and would force organizations into overly broad roles. From a security best-practice perspective, you should still follow least privilege and separation of duties, but the platform capability absolutely allows multiple role assignments (directly or via group-based role assignment where supported).

No. Azure Active Directory (Azure AD), now Microsoft Entra ID, is a cloud-based directory and identity service hosted and operated by Microsoft. You do not deploy Azure AD into an on-premises environment the way you deploy Windows Server Active Directory Domain Services (AD DS) on domain controllers. What you can deploy on-premises are components that integrate with Azure AD, such as Microsoft Entra Connect (formerly Azure AD Connect) to synchronize identities from on-prem AD DS to Azure AD, Pass-through Authentication agents, or Active Directory Federation Services (AD FS) for federation. These enable a hybrid identity model, but Azure AD itself remains a cloud service. Why “Yes” is wrong: it confuses Azure AD with AD DS. AD DS is installed and managed on-premises; Azure AD is consumed as a service (SaaS) from Microsoft’s cloud.

Yes. Azure AD (Microsoft Entra ID) is provided as part of a Microsoft 365 subscription because Microsoft 365 relies on Azure AD for tenant identity, authentication, and access control. When an organization signs up for Microsoft 365, a tenant is created and backed by an Azure AD directory. Important nuance for the exam: while Azure AD is included, the included capabilities depend on licensing. Microsoft 365 includes the base Azure AD features (often referred to as Entra ID Free). More advanced identity and access features—such as Conditional Access, Identity Protection, and Privileged Identity Management—require Microsoft Entra ID P1/P2 or suites that include them (for example, Microsoft 365 E3/E5 include different security/identity entitlements). Why “No” is wrong: it would imply Microsoft 365 operates without Azure AD, which is not the case; Azure AD is foundational to Microsoft 365 sign-in and authorization.

Yes. Azure Active Directory (Microsoft Entra ID) is an identity and access management (IAM) service. Its primary purpose is to manage identities (users, groups, service principals) and control access to resources through authentication (verifying who you are) and authorization (what you can do). In practice, Azure AD provides capabilities such as Single Sign-On (SSO) to Microsoft 365, Azure, and third-party SaaS apps; Multi-Factor Authentication (MFA); Conditional Access policies; application registrations and OAuth/OpenID Connect/SAML-based sign-in; and device identity integration. These are core IAM functions. Why “No” is wrong: it would misclassify Azure AD as something like a network security tool or a purely on-prem directory. While it can integrate with on-prem AD DS, Azure AD’s core role is cloud IAM, aligning with best practices like least privilege and strong authentication.

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: A. Multi-factor authentication (MFA). MFA requires additional verification beyond a username and password. The prompt’s example—“a verification code sent to a mobile phone”—is a classic second factor (something you have). In Microsoft Entra ID, MFA can be satisfied via SMS codes, voice calls, authenticator app codes, push notifications, or FIDO2/security keys depending on configuration. The goal is to mitigate risks such as password spray, phishing, and credential stuffing by ensuring that a stolen password alone is insufficient. Why the others are wrong: B. Pass-through authentication (PTA) is a hybrid authentication method where the user’s password is validated against on-premises Active Directory via an agent. It doesn’t inherently add a second verification step. C. Password writeback is a Microsoft Entra ID feature (commonly with SSPR) that writes password changes from the cloud back to on-premises AD; it’s not an “additional verification” mechanism. D. Single sign-on (SSO) reduces the number of sign-in prompts by reusing an existing session/token; it is the opposite of requiring extra verification.

Yes. Conditional Access policies can use device state as a signal. In Microsoft Entra, device-related conditions include device platform (iOS, Android, Windows, macOS), and—more importantly for “state”—whether the device is marked compliant by Microsoft Intune (device compliance) and/or whether it is Hybrid Azure AD joined / Microsoft Entra joined. Conditional Access can also use device filters (filter for devices) to include/exclude devices based on device attributes. These device signals allow policies such as “Require a compliant device” or “Allow access only from Hybrid Azure AD joined devices.” This is a common Zero Trust pattern: verify device health/state before granting access to sensitive apps. “No” would be incorrect because device context is one of the core Conditional Access inputs (signals) used to make access decisions.

No. Conditional Access policies do not apply before first-factor authentication is complete. Conditional Access evaluation requires that Entra ID can identify the user and understand the sign-in context (who is signing in, what app/resource is being accessed, and other conditions). That identification happens after the user submits primary credentials (the first factor). After the first factor, Conditional Access is evaluated and can then enforce additional requirements (controls), such as prompting for MFA, requiring a compliant device, or blocking access. In other words, CA is not a pre-authentication gate that runs before the user is known; it is part of the sign-in process that can require extra steps after initial authentication. Answering “Yes” would confuse Conditional Access with network-layer pre-auth controls (like some VPN/NAC scenarios). In Entra, CA is an identity-driven policy evaluated during sign-in, not before first-factor completion.

Yes. Conditional Access can trigger MFA when a user attempts to access a specific application. One of the most common Conditional Access configurations is: Assign the policy to specific users/groups, target one or more cloud apps (for example, Exchange Online, SharePoint Online, Azure Management, or a specific enterprise application), and then set the grant control to “Require multi-factor authentication.” This enables app-specific step-up authentication: users might sign in with only a password for low-risk apps, but when they access a sensitive application, Conditional Access requires MFA before granting access (issuing the token). Answering “No” would be incorrect because “Require MFA” is a built-in grant control in Conditional Access, and scoping policies to specific cloud apps is a core capability used to protect high-value resources.

Correct answer: C. Microsoft Defender for Identity. Microsoft Defender for Identity is a cloud-based security solution designed specifically to use signals from on-premises Active Directory (AD) to identify, detect, and help investigate advanced threats, compromised identities, and malicious insider actions. It typically collects telemetry from domain controllers (via Defender for Identity sensors) and analyzes AD-related activities to surface suspicious behaviors and attack patterns. Why the others are wrong: - A. Microsoft Defender for Cloud Apps focuses on SaaS application discovery, shadow IT, app governance, and controlling/monitoring cloud app usage (CASB capabilities). It is not primarily about on-prem AD signals. - B. Microsoft Defender for Endpoint focuses on endpoint devices (Windows, macOS, Linux, mobile) for EDR, vulnerability management, and attack surface reduction—not AD domain controller telemetry. - D. Microsoft Defender for Office 365 protects email and collaboration (Exchange, SharePoint, OneDrive, Teams) against phishing, malware, and business email compromise, not on-prem AD signal-based identity threat detection.