Free SC-900 Practice Test

Dynamic groups in Azure Active Directory (Azure AD), now Microsoft Entra ID, automate the process of adding and removing members based on user or device attributes. The primary purpose of managing group membership is to control permissions and entitlements for resources such as applications, licenses, and data. By automating group composition, dynamic groups directly automate the provisioning and de-provisioning phases of the access lifecycle. For instance, when an employee joins the 'Sales' department (an attribute change), they can be automatically added to the 'Sales Team' group, granting them immediate access to necessary sales applications and files. This removes the need for manual administrative intervention to grant or revoke access as roles and attributes change.

Microsoft Entra Documentation: Dynamic membership rules for groups in Microsoft Entra ID.

Reference: Under the section "What are dynamic membership rules?", the documentation explains that dynamic groups add/remove members based on attributes. The provided use cases, such as creating a group for all users in a specific department or assigning licenses, are fundamentally about managing access. This automation is a core component of managing the access lifecycle.

Microsoft Entra Documentation: What is group-based licensing in Microsoft Entra ID?.

Reference: This document provides a specific example of access lifecycle automation. It states, "you can assign one or more product licenses to a group. Microsoft Entra ID ensures that the licenses are assigned to all members of the group. Any new members who join the group are assigned the appropriate licenses. When they leave the group, those licenses are removed." This describes the automation of granting and revoking access to licensed software.

Azure Active Directory (Azure AD) is deployed to an on-premises environment: No. Azure AD (now Microsoft Entra ID) is a cloud-based identity and access management service. It is managed by Microsoft and operates as a multi-tenant service in the cloud. The on-premises equivalent is Active Directory Domain Services (AD DS).

Azure Active Directory (Azure AD) is provided as part of a Microsoft 365 subscription: Yes. When an organization subscribes to a Microsoft cloud service like Microsoft 365 or Microsoft Azure, a dedicated Azure AD tenant is automatically created and associated with that subscription. This tenant is used to manage users and access to the services included in the subscription.

Azure Active Directory (Azure AD) is an identity and access management service: Yes. This is the core definition and primary function of Azure AD. It is Microsoft's cloud-based Identity and Access Management (IAM) service that helps employees sign in and securely access internal and external resources.

Microsoft Entra documentation, "What is Microsoft Entra ID?".

Reference for Statement 1 & 3: The official documentation explicitly states, "Microsoft Entra ID is a cloud-based identity and access management service." This confirms it is an IAM service (Statement 3) and cloud-based, not on-premises (Statement 1).

Microsoft Entra documentation, "Compare Active Directory to Microsoft Entra ID".

Reference for Statement 1: This document clearly distinguishes the two services: "Microsoft Entra ID is a cloud-based identity and access management (IAM) solution... Active Directory Domain Services... are run on-premises..."

Microsoft 365 Enterprise documentation, "Subscriptions, licenses, accounts, and tenants for Microsoft's cloud offerings".

Reference for Statement 2: Under the section "Tenants", it states, "A subscription to a Microsoft cloud service, such as Microsoft 365, Microsoft Azure, or Dynamics 365, includes a Microsoft Entra tenant. The Microsoft Entra tenant stores the accounts and passwords..."

Yes: Conditional Access policies use various signals to make enforcement decisions. The device state, such as whether a device is compliant with security policies or is hybrid Azure AD joined, is a key signal that can be used as a condition in a policy.

No: Conditional Access policies are evaluated after a user has successfully completed first-factor authentication (e.g., providing a username and password). The policies need the user's identity context, established by the initial sign-in, to evaluate the conditions and determine if further actions, like MFA, are required.

Yes: A primary function of Conditional Access is to apply granular controls. Policies can be configured to target specific applications, and a common enforcement action (grant control) is to require multi-factor authentication before granting access to that application.

Microsoft Entra documentation, "What is Conditional Access?" This overview document explains that Conditional Access policies use signals, including device state, to enforce organizational policies like requiring MFA. A diagram illustrates that policy evaluation occurs after the user sign-in.

Source: learn.microsoft.com/en-us/entra/identity/conditional-access/overview (Sections: "Common signals", "Common decisions", and the workflow diagram).

Microsoft Entra documentation, "Conditional Access: Conditions." This document explicitly lists "Device state" as a condition that can be configured in a Conditional Access policy. It details the deprecated and current ways to configure device state policies.

Source: learn.microsoft.com/en-us/entra/identity/conditional-access/concept-conditional-access-conditions#device-state (Section: "Device state (deprecated)").

Microsoft Entra documentation, "Conditional Access: Grant." This source details the available grant controls, listing "Require multifactor authentication" as a primary control that can be enforced to grant access to a cloud application.

Source: learn.microsoft.com/en-us/entra/identity/conditional-access/concept-conditional-access-grant#require-multifactor-authentication (Section: "Require multifactor authentication").

You can add a resource lock to an Azure subscription.

• Yes. Resource locks can be applied at three different scopes: subscription, resource group, or a single resource. When a lock is applied at a parent scope, like a subscription, all resources within that scope inherit the same lock.

You can add only one resource lock to an Azure resource.

• No. An Azure resource can have multiple locks. For example, a resource can inherit a lock from its parent resource group or subscription while also having a separate lock applied directly to it. In cases of multiple locks, the most restrictive lock takes precedence.

You can delete a resource group containing resources that have resource locks.

• No. If a resource within a resource group has a CanNotDelete lock, or if the resource group itself is locked, you cannot delete the resource group. You must first remove the lock before the deletion operation can succeed. This is the primary function of a delete lock—to prevent accidental deletion.

Microsoft Learn (Azure Documentation). (2023). Lock resources to prevent unexpected changes. In "Azure Resource Manager documentation".

Scope of Locks: The document states, "You can apply locks at any scope in the Azure Resource Manager hierarchy. The scope can be a subscription, a resource group, or a single resource." This supports the "Yes" answer for the first statement.

Inheritance and Multiple Locks: The "How locks are applied" section explains, "When you apply a lock at a parent scope, all resources within that scope inherit the same lock... The most restrictive lock in the inheritance takes precedence." This confirms that a resource can be subject to multiple locks (inherited and direct), supporting the "No" answer for the second statement.

Deletion Behavior: The "Who can create or delete locks" section notes that permissions are required to delete locks, and implicitly, the documentation on deleting resource groups states that the operation will fail if locks are present. The article Move resources to a new resource group or subscription also clarifies, "The destination resource group isn't locked," as a prerequisite, reinforcing that locks prevent such operations.

Statement 1: No. Azure AD Identity Protection itself does not have a direct policy action to add users to a group. However, the risk level attribute it calculates (user.riskLevel) can be used as a property to create a dynamic membership rule for a group in Azure AD. Therefore, the action is performed by the Azure AD Dynamic Groups feature, which uses data from Identity Protection, but it is not a direct capability of Identity Protection policies.

Statement 2: Yes. This is a core feature of Azure AD Identity Protection. It works with researchers, law enforcement, and dark web monitoring teams to find publicly available lists of usernames and passwords. When a user's credentials are found on such a list, Identity Protection flags it as a "Leaked credentials" risk detection.

Statement 3: Yes. A primary function of Identity Protection is to automate responses to detected risks. You can configure a user risk policy or a sign-in risk policy that automatically requires a user to perform Multi-Factor Authentication (MFA) when their calculated risk level meets a specified threshold (e.g., medium or high). This helps ensure that even if a credential is compromised, the identity is protected.

Statement 1 (Dynamic Groups):

Microsoft Entra ID Documentation. (n.d.). Dynamic membership rules for groups in Microsoft Entra ID. Microsoft Learn. Retrieved from https://learn.microsoft.com/en-us/entra/identity/users/groups-dynamic-membership.

This document lists user.riskLevel as a supported property for creating dynamic group rules, confirming that the capability exists within Azure AD but is configured under group properties, not Identity Protection policies.

Statement 2 (Leaked Credentials):

Microsoft Entra ID Documentation. (n.d.). What is risk? - Leaked credentials. Microsoft Learn. Retrieved from https://learn.microsoft.com/en-us/entra/id-protection/concept-identity-protection-risks#leaked-credentials.

This official documentation explicitly describes the "Leaked credentials" risk detection type and how Identity Protection identifies it.

Statement 3 (MFA on Risk):

Microsoft Entra ID Documentation. (n.d.). Identity Protection policies - User risk policy. Microsoft Learn. Retrieved from https://learn.microsoft.com/en-us/entra/id-protection/concept-identity-protection-policies#user-risk-policy.

This source details the configuration of the user risk policy, stating that administrators can set the "Access" control to "Allow access" and "Require multifactor authentication".

Azure Bastion is deployed as a dedicated PaaS service within a virtual network (VNet), specifically in a subnet named AzureBastionSubnet. This single Bastion deployment provides secure access to all virtual machines within that VNet and any peered VNets, eliminating the need for multiple Bastion hosts per VNet.

This statement is incorrect. While Azure Bastion facilitates RDP (for Windows) and SSH (for Linux) connections to the target virtual machine, the secure connection from the user's browser to the Bastion service is established over HTTPS (TLS). Bastion acts as a secure gateway; it receives the user's request via a TLS-encrypted web session and then initiates the RDP/SSH session to the VM within the private network. The security is derived from not exposing RDP/SSH ports publicly and using TLS for the external connection.

Azure Bastion is deeply integrated with the Azure portal. Users initiate a secure, seamless RDP or SSH connection to their virtual machines directly from the VM's overview page in the Azure portal. This launches a browser-based session, removing the need for a public IP address on the VM or a separate client application.

Microsoft Azure Documentation, "What is Azure Bastion?".

Reference: Under the "Key features" section, it states, "RDP and SSH directly in Azure portal: You can get to the RDP and SSH session directly in the Azure portal using a single-click seamless experience." This supports the third statement. It also states, "The connection is made using TLS." which contradicts the second statement.

Microsoft Azure Documentation, "Azure Bastion FAQ".

Reference: The FAQ explicitly answers the question, "Do I need a separate Bastion host for each VNet?". The answer clarifies, "No. Azure Bastion is deployed per virtual network... If you have a single Bastion host provisioned in a virtual network, you can use it to connect to any VMs deployed in the same VNet." This confirms the first statement.

Federation is a system used in identity and access management to link a user's identity across multiple, separate organizations. The core principle of federation is to establish a trust relationship between these organizations. In this model, one organization, known as the Identity Provider (IdP), is responsible for authenticating the user. Other organizations, called Service Providers (SPs) or Relying Parties (RPs), trust the authentication performed by the IdP and grant the user access to their resources based on that trusted authentication. This eliminates the need for users to have separate credentials for each organization's services.

Microsoft Corporation. (2023). What is federation with Microsoft Entra ID? Microsoft Learn. In the "What is federation?" section, the document states, "Federation is a collection of domains that have established trust. The level of trust may vary, but typically includes authentication and almost always includes authorization."

National Institute of Standards and Technology (NIST). (2017). NIST Special Publication 800-63-3: Digital Identity Guidelines. Section 6.1.1, "Federation and Assertions". The entire concept of federation described in this section is predicated on a Relying Party (RP) trusting an assertion about an identity that is issued by a trusted Identity Provider (IdP).

Chadwick, D. W., & Inman, G. (2009). A peer-to-peer framework for federated identity management. IEEE International Conference on Communications, 2009. ICC '09. (DOI: 10.1109/ICC.2009.5199395). The paper's abstract discusses establishing a "circle of trust" which is foundational to the concept of federation, stating, "This allows service providers to trust the assertions made by the identity providers of other members of the federation."

The Zero Trust model operates on three core principles: verify explicitly, use least privileged access, and assume breach.

1. Verify explicitly: This principle dictates that every access request must be authenticated and authorized based on all available data points, including user identity, location, device health, and resource classification. It moves away from implicit trust.
2. Assume breach: This principle shifts the security mindset from preventing breaches to assuming they have already occurred or will inevitably happen. This leads to strategies like micro-segmentation and continuous monitoring to minimize the impact and spread of any potential intrusion.
3. The third statement describes a traditional perimeter-based security model (often called "castle-and-moat"), which Zero Trust is designed to replace. Zero Trust does not assume any network, internal or external, is secure. It challenges the idea that a firewall creating a "trusted" internal network is sufficient protection.

Microsoft Corporation. "What is Zero Trust?" Microsoft Security Documentation. Accessed October 13, 2025. "The three principles of Zero Trust are: 1. Verify explicitly. 2. Use least privilege access. 3. Assume breach."

Rose, S., et al. "Zero Trust Architecture." National Institute of Standards and Technology (NIST) Special Publication 800-207, August 2020. Section 2.1, Tenet 2 states, "All communication is secured regardless of network location." This contradicts the notion of a trusted internal network secured by a firewall. The document's foundational premise is to move beyond perimeter-based security. (DOI: https://doi.org/10.6028/NIST.SP.800-207)

Gilman, D. W., & Barth, D. "Zero Trust Networks: Building Secure Systems in Untrusted Networks." O'Reilly Media, Inc., 2017. Chapter 1, "The Core Concepts of Zero Trust," explains that the model eliminates the idea of a trusted internal network and an untrusted external network, treating all network traffic as untrusted.

Microsoft Cloud App Security (now part of Microsoft Defender for Cloud Apps) integrates with Azure AD Conditional Access to enable real-time monitoring and control over user sessions in cloud applications. This feature, called Conditional Access App Control, acts as a reverse proxy. When a user session is routed through it, administrators can enforce granular policies, such as blocking file downloads, protecting files on download with sensitivity labels, or monitoring specific user activities within the app. This provides a powerful way to prevent data leakage and enforce security compliance in real time for sanctioned applications.

Microsoft Learn. "Deploy Conditional Access App Control for featured apps." Microsoft Defender for Cloud Apps Documentation. States, "Session controls in Microsoft Defender for Cloud Apps work with Azure AD Conditional Access to monitor and control user app sessions in real time, based on access and session policies."

Microsoft Learn. "Conditional Access - Session." Azure Active Directory Documentation. Under the "Use Conditional Access App Control" section, it explains, "Conditional Access App Control uses signals from Microsoft Defender for Cloud Apps to apply access controls on an organization's cloud apps."

Microsoft Learn. "What is a session policy?" Microsoft Defender for Cloud Apps Documentation. Describes the capability: "Defender for Cloud Apps session policies enable real-time session-level monitoring, granting you granular visibility into cloud apps and the ability to control different actions depending on the user, location, device, and app."

In compliance management frameworks, such as Microsoft Purview Compliance Manager, templates are pre-defined frameworks containing the necessary groupings of controls that correspond to the requirements of a specific regulation, standard, or policy (e.g., GDPR, ISO 27001, NIST). An organization selects a relevant template to create an assessment. This assessment then uses the controls defined in the template to measure, manage, and track the organization's compliance status against that specific regulation. Therefore, templates are the foundational component used to track compliance with specific control groupings.

Microsoft. (2024). Understand assessment templates in Microsoft Purview Compliance Manager. Microsoft Learn. Retrieved from learn.microsoft.com. In the "How templates are structured" section, it states, "A template is a framework of controls for a specific regulation, standard, or policy."

Microsoft. (2024). Create an assessment in Microsoft Purview Compliance Manager. Microsoft Learn. Retrieved from learn.microsoft.com. The instructions under the "Select a template" section demonstrate that the process of tracking compliance begins by choosing a template corresponding to a specific regulation or standard.