Hard Difficulty Questions

Configure a new Schema Extension using the Azure AD Graph API

Why wrong: The Azure AD Graph API is deprecated and does not support the modern Custom Security Attributes feature. Furthermore, Schema Extensions are a different technology used for application-specific data and do not provide the built-in RBAC and administrative separation that is characteristic of the Custom Security Attributes management framework.

Create a new Directory Extension in Microsoft Entra Connect

Why wrong: Directory extensions in Microsoft Entra Connect are used to sync custom attributes from an on-premises Active Directory to the cloud. While they extend the schema, they do not support the advanced RBAC features of Custom Security Attributes and are managed through the sync engine rather than the cloud-native attribute UI.

The role can view the definitions and allowed values of all custom security attributes in the tenant.

Why wrong: The permission for viewing definitions is 'Microsoft.Directory/customSecurityAttributes/definitions/read'. The permission in the exhibit specifically targets the 'values' of the attributes assigned to objects, not the administrative structure or the configuration of the attribute sets themselves, which requires a different set of directory-level permissions.

The role can assign new custom security attribute values to users but cannot modify existing ones.

Why wrong: Assignment or modification of attribute values requires the 'values/write' permission. A 'read' operation is strictly limited to viewing existing data and does not grant any authority to create, update, or delete the information stored within those custom attributes, maintaining the integrity of the sensitive metadata.

The role can only read custom security attributes if they are also a member of the Attribute Definition Administrator role.

Why wrong: RBAC in Microsoft Entra ID is additive; having this specific permission in a custom role is sufficient to read values without needing membership in other built-in roles. The Attribute Definition Administrator role is actually focused on managing the schema rather than viewing the values assigned to specific users.

Disable the 'External user' account type in the User Settings blade.

Why wrong: There is no single toggle to 'disable' the external user account type in the User Settings blade that would achieve the desired restrictions. Managing external access is done through the External Collaboration settings and Cross-tenant access policies rather than a global account type disablement in user settings.

Enable 'Self-service sign-up via user flows' for all external users.

Why wrong: Enabling self-service sign-up is the opposite of a restrictive policy, as it allows external users to join the tenant without a direct invitation from an administrator. This is typically used for B2C scenarios or broad B2B applications and would undermine the goal of limiting access to specific partners.

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.

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.

The tenant must have at least a Microsoft Entra ID Free edition.

Why wrong: Custom Security Attributes are an advanced feature that requires a Microsoft Entra ID P1 or P2 license. The Free edition does not include the necessary governance and security infrastructure to support custom attribute sets and the associated granular delegated administration required for this functionality.

The attributes must be stored in the 'Default' attribute set.

Why wrong: There is no requirement to use a 'Default' set; in fact, creating custom attribute sets is recommended to group related attributes and apply specific access controls. This allows for better organization and ensures that different departments can manage their own specific sets of sensitive metadata independently.

Global Administrators can view all custom attributes by default.

Why wrong: One of the key security features of Custom Security Attributes is that they are hidden from Global Administrators by default. A Global Administrator must explicitly assign themselves the appropriate Attribute roles to see or manage the data, providing an extra layer of protection against unauthorized data access.

Disable the user account temporarily by setting AccountEnabled to false in Microsoft Entra ID.

Why wrong: Disabling the account blocks all future authentication attempts but does not guarantee immediate termination of already active session tokens cached by applications. Attackers can sometimes maintain session access until the existing access token naturally expires within its active lifetime.

Modify the user password to a temporary value and require password reset upon next sign-in.

Why wrong: Changing the password stops new token issuance but leaves existing valid refresh tokens fully operational until their expiration time or explicit revocation. Attackers exploiting active sessions retain access until those specific refresh tokens are actively invalidated.

Delete the user object from the directory and restore it from the deleted items container.

Why wrong: Deleting and restoring a user object removes group memberships, license assignments, and application access settings, causing severe operational disruption. This destructive workaround is unnecessary when targeted token revocation commands resolve the active security incident cleanly.

SMS-based authentication

Why wrong: SMS-based authentication is vulnerable to SIM swapping and interception. It is specifically excluded from phishing-resistant categories in security best practices because the one-time code can be easily phished by an attacker prompting the user to enter it into a fraudulent website during an active session.

Microsoft Authenticator push notification

Why wrong: While more secure than SMS, standard push notifications are susceptible to 'MFA fatigue' attacks, where an attacker sends constant prompts until the user accidentally approves one. They are not considered phishing-resistant because the user does not verify the context of the request, making them unsuitable for high-security environments.

Voice call authentication

Why wrong: Voice-based MFA is highly insecure and vulnerable to social engineering and automated interception tools. Like SMS, voice codes can be read out by a user who has been successfully phished into a fraudulent portal, providing the attacker with the means to authenticate successfully as the user.

Public Preview features for all users.

Why wrong: Enabling public preview features for all users is a security risk, as these features have not undergone the full testing and validation required for production stability. It can lead to unpredictable behavior, potential security holes, or breaking changes in authentication flows that could impact user access and service availability.

SMS as the only MFA method.

Why wrong: SMS is not a secure MFA method due to vulnerabilities like SIM swapping and interception. Relying on it as the only method leaves the organization exposed to attacks that bypass legacy MFA. Stronger methods like Microsoft Authenticator or FIDO2 keys should be preferred over SMS to maintain adequate security.

Configure a Conditional Access policy to enforce password changes every 90 days.

Why wrong: Conditional Access policies are designed for access control, not for managing local password aging policies. Password aging is managed through Microsoft 365 or on-premises Active Directory policy settings. Using Conditional Access for this purpose is technically impossible and violates the intended design of identity protection features.

Enable 'Self-service password reset' for all users in the tenant.

Why wrong: Self-service password reset is a convenience feature for users to regain account access. It is not required to enforce the banned password policy, as the policy is applied whenever a password is set or changed, regardless of whether the user uses the self-service portal or an administrator changes it.

Set the Password Protection mode to 'Audit' mode permanently.

Why wrong: Audit mode is designed for testing and gathering data about which users would have been blocked. Leaving it in Audit mode permanently means the policy is not actually enforced, and users will continue to choose weak passwords, rendering your security efforts ineffective for actual credential protection.

Use the 'Country-based' location filter in the administrative portal settings.

Why wrong: While country-based blocking exists, it is based on IP geolocation, which is unreliable and easily bypassed using VPNs or proxy services. It is not a robust security control for high-value administrative interfaces and should be used only as a secondary layer, not as the primary defense.

Create a new security group for administrators and add an IP restriction to the group.

Why wrong: There is no built-in feature to add an IP restriction directly to a security group. Security groups manage membership and roles, not network-level access. Entra ID enforces network access policies via Conditional Access, not through group-based memberships or attributes, so this solution is technically non-functional.

Configure 'Restrict access to Microsoft Entra administration portal' to 'No'.

Why wrong: This setting is the exact opposite of what is required; it allows broader access to the admin portal rather than restricting it. Disabling this restriction would essentially open the administrative portal to more users, which would be a catastrophic security error for an organization seeking to harden access.

Configure a sign-in risk policy.

Why wrong: Sign-in risk policies evaluate individual login attempts, not the user's overall account risk. Requiring a password change is a user-remediation action, not a sign-in remediation action, which typically focuses on requiring MFA or blocking the specific login attempt based on the risk detected at the time of sign-in.

Manually reset the user's password in the admin center.

Why wrong: Manual intervention does not scale for enterprise-level security. Entra ID Protection is designed to provide automated, real-time responses to risk. Relying on manual resets defeats the purpose of risk-based identity protection and leaves the account vulnerable during the time gap between detection and the administrator's manual action.

Create a Conditional Access policy that blocks the user's IP.

Why wrong: Blocking an IP address is an ineffective remediation because modern attackers rotate IPs constantly. It also impacts legitimate users if the IP belongs to a proxy or corporate gateway. The goal of risk-based remediation is to secure the identity, not to block connectivity based on volatile network factors.

Require ticket number on activation

Why wrong: While ticket numbers are a valid requirement option in PIM, the question specifically mandates justification and MFA. Requiring a ticket number would be an additional, unrequested administrative burden that does not satisfy the primary security objectives described in the prompt regarding standard identity verification and accountability.

Require approval on activation

Why wrong: Approval workflows add a secondary layer of human oversight but are not requested by the requirements. The prompt specifies justification and MFA as the necessary controls. Adding approval would change the operational flow significantly without directly addressing the specific security constraints requested for these administrative roles.

Enable persistent assignment

Why wrong: Persistent assignments grant roles indefinitely without the need for activation, which directly contradicts the core philosophy of PIM. Using persistent assignments would negate the security benefits of Just-In-Time elevation, making it impossible to enforce MFA or justification requirements at the time of administrative resource access.

Microsoft Authenticator push notifications

Why wrong: While Microsoft Authenticator push notifications with number matching are highly secure, they are generally not classified as fully phishing-resistant in the same category as FIDO2. They are susceptible to advanced adversary-in-the-middle (AiTM) attacks where a proxy site captures the session cookie. Phishing-resistant methods specifically require hardware-bound keys that the browser and operating system verify against the target domain.

SMS-based authentication codes

Why wrong: SMS-based authentication is one of the least secure forms of MFA and is highly vulnerable to phishing, SIM swapping, and interception. It does not use cryptography bound to the hardware or the origin of the request. Attackers can easily set up fake login pages to harvest these codes, making them entirely unsuitable for a phishing-resistant authentication strategy for high-security users.

Windows Hello for Business.

Why wrong: Windows Hello for Business is a primary example of a phishing-resistant authentication method. It uses a hardware-protected private key and a local biometric or PIN gesture to authenticate the user. Because the authentication process is tied to the physical device and the identity provider through public-key cryptography, it satisfies the requirements of the Phishing-resistant MFA authentication strength policy.

FIDO2 security key.

Why wrong: FIDO2 security keys are external hardware devices that provide phishing-resistant authentication using the WebAuthn standard. They are explicitly designed to be included in high-assurance authentication strengths. By requiring a FIDO2 key, the policy ensures that the user possesses a physical token that cannot be duplicated or intercepted by an attacker through common phishing or session hijacking techniques.

Microsoft Entra Certificate-based authentication (Multi-factor).

Why wrong: Certificate-based authentication that uses a certificate stored on a hardware device (like a smart card) is considered phishing-resistant. This method satisfies the high-assurance requirements because it relies on asymmetric cryptography and a physical factor. It is one of the few methods permitted under the 'Phishing-resistant MFA' strength, providing a secure alternative for organizations with existing PKI infrastructure.

Add the external website URLs to the 'Cloud Apps' list as custom applications.

Why wrong: You cannot add arbitrary external website URLs directly to the 'Cloud Apps' list in Conditional Access. Cloud apps must be integrated with Entra ID through enterprise applications or app registrations. Global Secure Access provides the necessary infrastructure to intercept and categorize internet traffic, making it the correct mechanism for applying identity-based policies to standard web browsing activities.

Configure a 'Named Location' for each high-risk website IP address.

Why wrong: Named Locations are used to define the source of a sign-in (where the user is coming from), not the destination (where the user is going). While you can use Named Locations to block traffic from certain countries or IP ranges, they cannot be used to manage access to specific external websites based on their destination IP or domain name within a Conditional Access policy.

Use a 'Microsoft 365' traffic profile and filter by URL category.

Why wrong: The Microsoft 365 traffic profile is specifically for optimizing and securing traffic to Microsoft services like Exchange Online, SharePoint, and Teams. It does not cover general internet traffic or external websites. To manage access to the wider internet, you must use the 'Internet Access' traffic profile provided by the Entra Internet Access component of Global Secure Access.

User department

Why wrong: The user department is an attribute of a user object but is not a native, direct condition type available for selection in a Conditional Access policy. Policies are typically assigned to users or groups, but cannot dynamically filter access based on the 'department' attribute during evaluation.

Password strength

Why wrong: Conditional Access does not evaluate the strength of a user's password as a condition. Password complexity and strength are managed through password policies in Entra ID or on-premises Active Directory. Conditional Access acts on the authentication result, not the internal attributes of the user's password.

The user's account is locked.

Why wrong: Account lockouts generally produce different error codes related to authentication failures or account status. Code 50072 is specifically tied to MFA requirements, not account state or identity status, meaning a lockout would be represented by a different error message in the Entra ID sign-in logs.

The user's password has expired.

Why wrong: Password expiration errors are distinct and typically prompt the user to change their password during the sign-in flow. They do not trigger the MFA-specific error code 50072, which focuses entirely on the presence and validity of secondary authentication factors required by the Conditional Access policy configuration.

The user is on an unauthorized network.

Why wrong: Network-based blockages from Conditional Access generally result in different error codes related to location-based compliance. Error 50072 is uniquely mapped to the requirement for multi-factor authentication, regardless of the network location from which the user is attempting to perform the authentication request.

To register a new FIDO2 key for the user.

Why wrong: The 'Update' verb in Microsoft Graph PowerShell indicates that an existing object is being modified. To register a new FIDO2 key, the administrator would typically use the 'New' verb (New-MgUserAuthenticationFido2DeviceMethod). This distinction is critical for understanding how to manage authentication metadata for users.

To change the label of an existing security key.

Why wrong: By providing a new 'DisplayName' parameter, the administrator is changing the human-readable label associated with the FIDO2 key. This helps both the user and the administrator identify which physical device is being used, especially if the user has multiple keys registered to their account.

To disable FIDO2 authentication for the entire tenant.

Why wrong: Authentication methods for the tenant are managed through tenant-wide policy settings, not on a per-user device method basis. This command targets a specific user and a specific device ID, meaning its scope is limited to that individual's authentication configuration rather than a global tenant setting.

To reset the user's primary password.

Why wrong: FIDO2 methods are part of a passwordless or multi-factor strategy and are separate from the user's traditional password. This command specifically interacts with the FIDO2 hardware metadata and has no effect on the user's Active Directory password or their ability to perform a standard password reset.

Users must MFA every hour.

Why wrong: The policy specifically limits 'MaxAgeSessionSingleFactor', which applies to single-factor authentication. It does not mandate MFA every hour. If MFA is performed, a different token lifetime policy or the default session behavior would apply, so this policy is specifically targeting non-MFA session durations.

Users are blocked after one hour.

Why wrong: A session token expiration does not result in a block; it simply requires the user to perform an authentication flow to obtain a new token. Once they authenticate successfully, they will be granted a new session token, and they can continue working without being permanently blocked from access.

The policy forces MFA for every sign-in.

Why wrong: This policy does not influence the requirement for MFA. It only defines the lifetime of a single-factor session. The actual requirement for MFA is dictated by other policies, such as Conditional Access or User settings, and this token lifetime policy remains independent of the MFA enforcement logic.