Implement and Manage User Identities practice questions

Security group with Assigned membership

Why wrong: Assigned membership requires manual intervention to add or remove users from the group. If a user moves from the Marketing department to Sales, they would remain in the group until an administrator manually removes them, which fails to meet the requirement for automatic removal based on attribute changes in the directory.

Microsoft 365 group with Assigned membership

Why wrong: Microsoft 365 groups are designed for collaboration with shared mailboxes and calendars, but assigned membership still relies on manual updates. This choice does not provide the automation needed to manage users based on their departmental or location attributes, leading to potential security gaps and stale access over time.

Microsoft 365 group with Dynamic Device membership

Why wrong: Dynamic Device membership evaluates the properties of devices, such as operating system or model, rather than user attributes like department or city. Using this membership type would prevent the group from correctly identifying and including the relevant employees, as it looks at hardware metadata instead of the identity profile.

Set 'Guest user access' to 'Guest users have the same access as members'

Why wrong: This setting would significantly weaken the security posture of the tenant by granting external guests the same directory visibility as internal employees. It does not address the requirement to limit invitations to a specific domain or control who has the permission to invite other guests into the environment.

Enable 'Self-service sign-up via user flows' for the tenant

Why wrong: Self-service sign-up is typically used for B2C scenarios or broad B2B scenarios where you want to allow users to register themselves. This does not restrict invitations to a specific domain like 'partner.com' and would likely lead to unauthorized users from various domains gaining access to the resources.

Set 'Guest invite settings' to 'Only users assigned to specific admin roles can invite guest users'

Why wrong: By restricting invitation permissions to specific administrative roles, you prevent guest users (and standard members) from inviting additional guests. This satisfies the requirement to ensure external users cannot invite others, maintaining tight control over the lifecycle of guest accounts and preventing unauthorized access expansion.

Create a Cross-tenant access policy with 'Block all' for Inbound access

Why wrong: Blocking all inbound access in a cross-tenant access policy would prevent any collaboration with external partners, including those from 'partner.com'. This contradicts the objective of allowing specific partners to be invited and instead implements a zero-trust boundary that completely disables the B2B collaboration features for the tenant.

The user will be prompted to set up Multi-Factor Authentication immediately

Why wrong: While Multi-Factor Authentication is a common requirement, it is not explicitly triggered by the 'passwordProfile' settings in the Graph API JSON payload. MFA is typically enforced through Conditional Access policies or per-user MFA settings, which are independent of the initial password change flag set during the user creation process.

The user will be denied access because the password does not meet complexity requirements

Why wrong: Microsoft Entra ID validates password complexity at the time of the API request, not during the login attempt. If the password 'ComplexPass123!' did not meet requirements, the API call to create the user would have failed with a 400 Bad Request error rather than allowing the account to be created.

The user will be logged in normally and can keep the temporary password indefinitely

Why wrong: This would only occur if 'forceChangePasswordNextSignIn' were set to 'false'. Because the attribute is explicitly set to 'true', the system will intercept the login process and mandate a change, preventing the user from continuing to use the static password defined in the initial provisioning script or payload.

The 'Registration' tab in the Password Reset settings

Why wrong: The Registration tab determines whether users are required to register for SSPR when they sign in and how many days they can go before they must provide their info. It does not control the actual logic of how many methods must be used during the password reset event itself.

The 'Combined security information registration' policy

Why wrong: Combined registration is a feature that allows users to register for both MFA and SSPR in a single experience. While it facilitates the collection of authentication data, it does not define the specific requirements for how many factors are needed to perform a password reset action in the tenant.

Conditional Access policies for the 'My Profile' application

Why wrong: Conditional Access can be used to require MFA when users access the registration portal, but it cannot override the internal SSPR engine settings that dictate the number of verification steps. The SSPR configuration is managed within the dedicated Password Reset section of the Microsoft Entra admin center.

The 'contains' operator is case-sensitive in dynamic group rules

Why wrong: In Microsoft Entra ID dynamic group membership rules, operators like '-contains' and '-eq' are generally not case-sensitive. Therefore, 'Manager' would match 'manager' or 'MANAGER', so the casing of the job title in the user profile is not the reason for the users being excluded from the group.

The users have the 'accountEnabled' attribute set to false

Why wrong: While this would exclude users, the scenario implies these are active managers. If they were disabled, it would be a deliberate exclusion by the rule. However, a more common technical issue in dynamic groups is the latency of the evaluation or the specific way strings are handled in the rule logic.

Dynamic groups are limited to a maximum of 1,000 members

Why wrong: Microsoft Entra ID dynamic groups can support significantly more than 1,000 members; the limit is actually in the hundreds of thousands depending on the tenant tier. A membership size of a few managers would not hit any system limits that would prevent the addition of valid users to the group.

A JSON file containing the user display names and emails

Why wrong: The Microsoft Entra admin center bulk invite tool does not support JSON files for this specific operation. It requires a specific CSV format provided by the portal to ensure the data is parsed correctly by the background processing engine that handles the creation and invitation of guest accounts.

An active subscription to Microsoft Entra ID P2

Why wrong: Bulk invitations are available in all tiers of Microsoft Entra ID, including the Free tier. While P2 offers advanced features like Access Reviews and Privileged Identity Management, it is not a prerequisite for using the standard bulk invite functionality to bring external guests into the tenant for collaboration.

The 'Invite redirect URL' for each user in the upload file

Why wrong: The redirect URL is a required field in the bulk invite CSV template. It specifies the location (such as a SharePoint site or the MyApps portal) where the guest user will be directed after they click the link in their invitation email and successfully complete the redemption process.

Alex will only have the E5 license as it is the higher SKU

Why wrong: Microsoft Entra ID does not automatically prioritize higher SKUs over lower ones when both are assigned via groups. The system will attempt to assign both licenses, and Alex will consume one seat of E5 and one seat of E3 simultaneously until one of the assignments is manually or dynamically removed.

The E3 license assignment will fail due to a license conflict

Why wrong: License conflicts only occur if specific service plans within the licenses cannot coexist, but generally, E3 and E5 can be assigned to the same user without the entire assignment failing. The user would simply have the combined set of features enabled, and the portal would show both licenses as active.

Alex will have the E5 license, and the E3 will be in a 'Suspended' state

Why wrong: There is no 'Suspended' state for individual licenses assigned via groups in this context. The license is either assigned, or it results in an error state if there are no seats available. Since both are assigned via groups, the system treats them as independent requirements for the user's identity.

Native support for synchronizing Device objects like Windows 10 computers

Why wrong: Currently, Microsoft Entra Cloud Sync has limited support for device synchronization compared to the standard Microsoft Entra Connect Sync. Connect Sync is still the recommended solution for organizations that require Hybrid Azure AD Join for their Windows devices, as it provides the necessary attributes and sync flows for hardware.

The ability to sync custom directory extensions larger than 2KB

Why wrong: Directory extensions and their size limits are generally consistent across the Entra ID platform. Cloud Sync does not provide a specific advantage in terms of the size of individual attribute extensions; rather, its advantages lie in the deployment architecture and the reduction of on-premises software maintenance requirements.

Support for Pass-through Authentication (PTA) without additional agents

Why wrong: Pass-through Authentication still requires the installation of specific PTA agents on-premises, regardless of whether you use Cloud Sync or Connect Sync. Cloud Sync itself is an evolution of the sync engine, but it does not eliminate the need for the separate authentication agents required for the PTA identity model.

It will create a duplicate user account with the new userName

Why wrong: The provisioning service is designed to avoid duplicates by using matching attributes. If a match is found based on the unique 'externalId', the service will attempt to update the existing record rather than creating a new one, ensuring that the identity lifecycle remains consistent across the HR and directory systems.

It will stop the synchronization and log a 'Critical Error' in the audit logs

Why wrong: While errors can occur, a mismatch in a non-matching attribute typically triggers an update rather than a critical failure. The service will only stop if it cannot resolve a required unique constraint or if the configuration specifically instructs it to abort when certain conditions are met during the synchronization cycle.

It will ignore the 'externalId' and create a new user based on the 'userName'

Why wrong: The provisioning engine follows the 'matching precedence' defined in the attribute mappings. If 'externalId' is set as the primary matching attribute, it takes priority over 'userName'. The service will always act on the first match it finds according to the order of operations defined in the configuration.

Conditional Access 'Session' controls

Why wrong: Conditional Access session controls manage the user's experience after they have authenticated, such as enforcing sign-in frequency or persistent browser sessions. They do not have the capability to redirect the authentication method from a federated identity provider like AD FS to a cloud-based method like Password Hash Synchronization.

Microsoft Entra Connect 'Express Settings'

Why wrong: Express Settings in Microsoft Entra Connect are used for a standard, tenant-wide configuration of synchronization and authentication. They do not support the granular, user-level control required to test a new authentication method for a small group while keeping the majority of the organization on a federated model.

Active Directory 'Shadow Groups'

Why wrong: Shadow groups are an on-premises Active Directory concept used to simplify management of users for certain applications or services. They have no native functionality within Microsoft Entra ID for controlling the authentication protocol or managing the transition between federated and managed identity models during a cloud migration project.

Smart cards

Why wrong: Smart cards are used for primary authentication and MFA in many high-security environments but are not a native authentication method for the Entra ID SSPR flow. SSPR typically relies on software-based factors or simple hardware tokens that do not require specialized readers for the password recovery process.

FIDO2 security keys

Why wrong: While FIDO2 keys are excellent for secure sign-in and MFA, they are currently not supported as a standalone method for resetting a password via the SSPR portal. They are intended to replace passwords entirely rather than serve as a recovery mechanism for a forgotten password within the standard SSPR workflow.

User1 will have both the E3 and E5 licenses assigned, and all services from both will be available.

Why wrong: Entra ID supports multiple license assignments. In this scenario, the direct E3 assignment remains, and the group-based E5 assignment is added. User1 will consume one seat of each license type, and their available services will be the union of all features included in both the E3 and E5 plans.

The direct E3 license is automatically removed, and only the group-based E5 license remains.

Why wrong: Microsoft Entra ID never automatically removes a direct license assignment when a group-based license is added. Direct assignments are considered intentional administrative actions and must be manually removed by an administrator or via a script to stop the consumption of that specific license seat.

The E5 license is assigned, but all its services are disabled until the E3 license is manually removed.

Why wrong: Services are not disabled by default when a new license is added. Instead, the user gains access to any new services provided by the E5 license. While some services might overlap, they function normally. The only reason to remove the E3 license is to save costs or resolve specific sub-service conflicts.

Add the parameter -ForceChangePasswordNextSignIn $true to the New-MgUser command.

Why wrong: While this looks like a valid PowerShell parameter, it does not exist for the 'New-MgUser' cmdlet in the Microsoft Graph SDK. The SDK requires configuration through the structured 'PasswordProfile' object rather than using flat switch parameters for these specific password-related settings and behaviors.

Run the command Set-MgUserPassword -UserId "tuser@contoso.com" -ForceChange $true after creation.

Why wrong: The 'Set-MgUserPassword' cmdlet is not a standard part of the Microsoft Graph SDK for this purpose. While there are commands to update a user, the most efficient and standard way to require a password change is to define it at the moment of user creation within the initial payload.

The user will automatically be prompted to change their password because 'AccountEnabled' is set to true.

Why wrong: The 'AccountEnabled' parameter simply determines if the user can sign in or not. It has no bearing on password expiration or the requirement to change the password. By default, a new user is not forced to change their password unless the administrator explicitly configures the password profile to do so.

Microsoft Entra Connect Sync Engine

Why wrong: While Entra Connect is used for identity synchronization, it is not a component of the Password Protection runtime. Password Protection operates as a separate set of agents that communicate directly with Entra ID to enforce password policies, independent of the main identity synchronization schedule or engine.

Microsoft Entra Application Proxy Connector

Why wrong: The Application Proxy Connector is used to provide secure remote access to on-premises web applications. It has no role in the password validation or enforcement process. Confusing these two types of proxies is a common error; the Password Protection Proxy is a distinct service with a different purpose.

Microsoft Entra Connect Health Agent

Why wrong: Connect Health agents are used to monitor the performance and health of identity infrastructure like AD FS and Entra Connect. While they provide valuable insights into the environment, they do not participate in the active enforcement of password policies or the validation of user credentials during a password change.

7 days

Why wrong: Seven days is too short and does not match the standard retention policy for Microsoft Entra ID. While some specific logs or temporary data might have shorter retention periods, user objects are given a significantly longer grace period to ensure that mistakes can be corrected during a typical business cycle.

14 days

Why wrong: Fourteen days is a common retention period for some Microsoft 365 services like deleted items in Outlook, but it is not the correct duration for Entra ID user objects. The platform provides a longer window to account for users who may be away on vacation or for extended leave.

90 days

Why wrong: Ninety days is often the retention period for audit logs or recycle bins in SharePoint, but it is much longer than the 'soft-delete' window for Entra ID users. Keeping deleted identities for three months would clutter the directory and potentially create security risks if not managed carefully.

The external users must be invited as guests to the host tenant first.

Why wrong: This is incorrect because B2B Direct Connect explicitly avoids the creation of guest accounts. Unlike B2B Collaboration, users sign in with their home tenant credentials and access resources in the host tenant directly without ever appearing as a 'Guest' user object in the host's directory list.

All users in the partner organization must have a Microsoft Entra ID P2 license.

Why wrong: While some advanced security features require P2, basic B2B Direct Connect functionality does not. The licensing follows the Monthly Active User (MAU) model similar to other external identity features, where the first 50,000 users are free regardless of whether they use standard B2B or Direct Connect.

The partner organization must use a third-party identity provider like Okta or Google.

Why wrong: B2B Direct Connect is currently only supported between two Microsoft Entra ID tenants. It relies on the native trust and protocol implementation within the Microsoft ecosystem. For third-party identity providers, organizations must use standard B2B Collaboration, which involves the creation of guest accounts in the host tenant.

Assign the User Administrator role to your account to override the synchronization lock.

Why wrong: Administrative roles in Microsoft Entra ID do not grant the ability to bypass the source of authority restrictions for synchronized objects. Even a Global Administrator must adhere to the rule that synchronized attributes must be managed at the source, which in this specific scenario is the local on-premises directory.

Disable the Microsoft Entra Connect sync temporarily to allow direct edits in the cloud portal.

Why wrong: Disabling the synchronization engine is an extreme measure that can lead to significant identity management issues and does not convert synchronized users to cloud-only users. Attributes remain mastered on-premises until the object is fully disconnected from the sync process, making this an ineffective and risky solution for simple updates.

Use the Microsoft Graph PowerShell module to force the attribute update in the cloud.

Why wrong: Microsoft Graph PowerShell is subject to the same source of authority constraints as the web-based admin center for synchronized objects. Attempting to update a synchronized attribute via PowerShell will result in a validation error because the cloud identity provider recognizes the on-premises directory as the master for that user data.

(user.department -eq "Sales" -and user.department -eq "Marketing") -and (user.city -eq "London")

Why wrong: Using the 'AND' operator between two different values for the same attribute, like department, will result in an empty group because a single user cannot have two primary department values simultaneously. The logic requires an 'OR' operator for the department values to capture users belonging to either specified team.

user.department -contains "Sales" -or "Marketing" -and user.city -match "London"

Why wrong: The 'contains' operator is valid, but the syntax for evaluating multiple values against a single property must be explicitly defined for each instance. Furthermore, the lack of parentheses would cause the 'AND' operator to take precedence in a way that might include all Sales employees regardless of their specific city location.

user.department -in ["Sales", "Marketing"] -or user.city -eq "London"

Why wrong: While the 'IN' operator is efficient for checking multiple values, using an 'OR' between the department and city criteria would include every user in London regardless of department. This logic fails the requirement because it would add non-Sales and non-Marketing employees to the group if they work in London.

Job title [jobTitle]

Why wrong: The job title is a descriptive attribute used for organizational grouping and profile details but is not essential for the technical creation of a user object. You can leave this field blank during the bulk upload and update it later through the admin center or via a dynamic group.

Usage location [usageLocation]

Why wrong: Usage location is required before a license can be assigned to a user, but it is not a mandatory field for the initial creation of the user object itself. While it is best practice to include it, the bulk create operation will complete successfully even if this specific column is empty.

Department [department]

Why wrong: Department information is considered an optional metadata field in the Microsoft Entra ID schema during the user provisioning phase. It is often used for dynamic group rules, but the identity platform does not require it to technically instantiate a new user account within the cloud-based directory service.

License assignments in Entra ID always prioritize the license that was assigned first chronologically.

Why wrong: Entra ID does not use chronological order to determine license priority; instead, it attempts to assign all available service plans from all assigned licenses. If a user is not seeing expected features, it is usually due to a configuration error or a specific service plan conflict rather than a timestamp.

The user has not yet signed out and signed back in to refresh their license token.

Why wrong: While a sign-in refresh can help with some application-level permissions, the Entra ID portal and the underlying service plan availability are updated in near real-time. License features are generally available as soon as the backend processing completes, which typically occurs within minutes of the group membership change or assignment.

The E5 license requires a manual 'Usage Location' update that the E3 license does not.

Why wrong: Both E3 and E5 licenses require a 'Usage Location' to be set on the user object before they can be successfully assigned. If the E3 license is already active, the 'Usage Location' must already be present, so this would not be the reason why the E5 license is failing.