Microsoft Security, Compliance, and Identity Fundamentals Practice Test (SC-900)

The Zero Trust model is built on three core principles: verify explicitly, use least-privileged access, and assume breach. The mandate to authenticate and authorize every access attempt based on all available signals-such as user identity, location, and device health-directly aligns with the "verify explicitly" principle. While least-privilege focuses on limiting permissions and assume breach focuses on containment and monitoring, verify explicitly requires continuous validation before granting access, even to internal requests. "Shift-left security" is a software-development concept and is not one of the formal Zero Trust principles.

An identity provider (IdP) is responsible for authenticating users and issuing the security tokens that SaaS applications (relying parties) trust. By validating the user's credentials and providing a signed token, the IdP enables single sign-on across multiple services. Hosting the applications, encrypting all traffic, or backing up application data are important tasks, but they are not core responsibilities of an IdP.

The requirement to assess every access attempt based on multiple signals (identity, device health, location, etc.) illustrates the Verify explicitly principle. Zero Trust stresses three core principles: Verify explicitly, Use least-privileged access, and Assume breach. While least-privileged access limits permissions after authentication and assume breach prepares for compromise, only verify explicitly mandates rigorous, signal-based authentication and authorization for each request. Segmenting by network zone can be part of a Zero Trust architecture, but it is not one of the three core principles.

Azure evaluates NSG security rules in ascending order of their priority number (where 100 is evaluated before 200, and so on). As soon as the first rule that matches the packet's characteristics is found, Azure stops processing further rules and enforces the action (allow or deny) defined in that rule. Rules with higher priority numbers are evaluated later and are ignored if an earlier rule already matched the traffic. Therefore, lower priority numbers have precedence. The other options are incorrect because Azure does not start with the highest priority number, does not aggregate multiple rules, and does not apply the most restrictive action after reviewing all rules.

The scenario describes defense in depth, a strategy that applies coordinated security controls at multiple layers. Each layer (for example, physical, perimeter, network, identity, host, application, and data) provides an additional barrier. If an attacker compromises one layer, the remaining layers continue to limit movement and protect assets. Zero Trust focuses on continuous verification, the shared responsibility model divides duties between provider and customer, and encrypting data in transit is only one control, not an overall strategy.

Identity federation creates a trust relationship between an identity provider-such as Azure Active Directory-and one or more service providers. When the trust is in place, the service provider accepts a security token issued by the identity provider and grants the user access without maintaining its own user store. This allows single sign-on across organizational boundaries while keeping authentication centralized. Directory synchronization only copies account data and still requires local authentication, authorization defines what a user can do after access is granted, and role-based access control is a method of assigning permissions, not of sharing identities between organizations. Therefore, federation is the required concept.

Symmetric encryption converts readable data into ciphertext using a secret key and can be reversed (decrypted) with the same key, meeting the requirement for confidentiality and recoverability. Hashing and salting create one-way digests that cannot be converted back to the original data and are intended for integrity or password storage, not confidentiality. Tokenization substitutes sensitive data with unrelated tokens without providing a built-in way to restore the original value from the token alone. Therefore, symmetric encryption is the only option that both protects the data and allows it to be restored to its initial state.

To scope a Conditional Access policy to a particular application, you configure the Cloud apps or actions assignment. In this section you can select the "Microsoft Azure Management" cloud app, which represents the Azure portal. The other options serve different purposes: "Users or workload identities" chooses who is affected, "Conditions" refines circumstances such as location or device state, and "Session controls" are enforcement actions that apply after access is granted. Without targeting the correct cloud app, the policy would either not run or would apply to unintended services.

Hashing applies a mathematical function to input data and returns a short, fixed-length value (the hash, or message digest). Because the process is one-way, any change to the original data produces a completely different hash, allowing quick verification that data is unaltered. Encryption focuses on confidentiality and is designed to be reversed (decrypted) with the correct key, so it is not inherently ideal for simple integrity comparisons.

Hashing takes an input of any length and produces a fixed-length digest that is designed to be irreversible. Because the process cannot be reversed, hashing is used to verify data integrity, such as when Microsoft 365 checks file hashes after download. Encryption, by contrast, is a reversible operation: the original plaintext can be recovered by applying the correct decryption key, which is why encryption is suited to protecting confidentiality. The other answers are incorrect because hashing does not rely on key pairs, does not inherently enlarge data, and does not provide confidentiality-those properties are associated with encryption.

Hashing uses a one-way mathematical function to convert input data into a fixed-length digest. Because the function is non-reversible, the original password cannot be reconstructed from the hash, yet the application can verify a user by hashing the provided password and comparing the digests. Symmetric and asymmetric encryption are reversible by design, so administrators with the appropriate keys could recover the plaintext. TLS protects data only while it is in transit and does not secure how the password is stored.

The described activities-identifying threats, analyzing their likelihood and impact, and prioritizing mitigation efforts-are core parts of the risk management discipline of GRC. Governance focuses on establishing policies and overall direction, while compliance addresses meeting regulatory or contractual requirements. Data classification is a supporting security practice but is not itself one of the three primary GRC disciplines.

Multifactor authentication is a control that verifies user identities before granting access to resources. In Microsoft's defense-in-depth model, such controls belong to the Identity and access layer. Perimeter and Network layers protect traffic flow, while the Data layer safeguards the information itself; none of these layers are primarily focused on confirming who the user is.

With Platform as a Service (PaaS) offerings such as Azure App Service, Microsoft is responsible for securing and maintaining the underlying platform. That includes installing operating-system updates and patches on the hosts that run customers' code. Customers, however, must protect their own data, manage identities and access, and set any additional network controls they require. Therefore only the operating-system patching task falls under Microsoft's responsibility in this scenario; the other listed tasks remain customer duties.

AD DS stores objects in a hierarchical structure that includes forests, domains, and organizational units (OUs), which administrators use together with Group Policy. Azure AD is a cloud-based, multi-tenant directory that keeps users, groups, and other objects in a flat structure scoped to a single tenant and does not provide OUs or Group Policy. The other options either reverse the protocol support, incorrectly state that Azure AD depends on on-premises domain controllers, or misrepresent which service is multi-tenant.

The scenario describes two separate security realms-your organization and the partners' organization-establishing mutual trust so that authentication is performed by the partners' identity provider and accepted by your application. This is the essence of identity federation. The other options are different concepts: password hash synchronization copies password hashes to Azure AD, role-based access control governs permissions after authentication, and multi-factor authentication adds verification steps but does not establish cross-organization trust.

The sign-in process that confirms the user is who they claim to be is authentication, and it completed successfully because the user obtained a valid token. The process that evaluates the user's permissions to decide whether the requested SharePoint Online site can be accessed is authorization, and that process failed because the user was denied access. Therefore, authentication succeeded while authorization failed. The other options reverse these roles, claim both processes failed, or mix in federation, which is unrelated to the permission decision for a SharePoint resource.

Identity is treated as the first line of defense because users and devices connect from many networks. Azure AD Conditional Access continuously evaluates signals (user risk, sign-in location, device health, etc.) and applies policies to allow, require additional verification, or block access. This makes Conditional Access the key enforcement tool for using identity as the security perimeter. The other options do not provide policy-based, real-time access decisions centered on identity: Azure Information Protection labels classify data, Defender for Endpoint attack-surface rules harden devices, and Azure DDoS Protection safeguards network resources from volumetric attacks.

Google and Facebook perform the authentication step on behalf of the customer. Services that authenticate users and issue the resulting security token to relying applications are known as identity providers. Conditional access policies, resource providers, and session hosts have different roles and do not directly authenticate users.

Assigning the Reader role with Azure role-based access control does not verify who the user is; that occurs during authentication. Instead, the role defines what the signed-in users are permitted to do-view resources within the assigned scope. Deciding and enforcing these post-sign-in permissions is the purpose of authorization. Federation and identity provisioning relate to how identities are established or trusted, not to the permissions they receive after sign-in.