Implement Authentication and Access Management practice questions

Enable 'Restrict access to Microsoft Entra administration portal' for all guest accounts.

Why wrong: While this setting prevents guests from accessing the Azure management portal, it does not prevent them from using Microsoft Graph API or PowerShell to enumerate directory objects if their permissions allow. It is a management portal restriction, not a comprehensive directory visibility restriction for guest users.

Create a Conditional Access policy that blocks guests from accessing the Microsoft Graph API.

Why wrong: Conditional Access policies cannot block specific API endpoints like the Microsoft Graph directly in this granular manner. While you can block access to specific cloud apps, it does not effectively hide directory objects from guests who have legitimate access to other internal applications that query the directory.

Disable the 'Invite guests' setting in the External Collaboration settings menu.

Why wrong: Disabling the invite guests setting would prevent you from adding new guests entirely, rather than restricting the permissions of guests already present in your tenant. This solution breaks business workflows rather than enforcing the principle of least privilege for users who are already part of your ecosystem.

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.

The policy version is outdated and causes compatibility issues with modern Microsoft Graph endpoints.

Why wrong: While the version string might look generic, it is not the cause of the security risk. The primary security issue is the over-privileged permission scope itself, not the version format, which is often a placeholder in many administrative contexts for testing permission sets before full implementation.

The Action field lacks the required 'application:' prefix for service principals.

Why wrong: The syntax issue is a red herring. The primary concern in security reviews is the actual scope granted, not minor naming conventions. Even with the correct prefix, granting 'User.ReadWrite.All' would remain a significant security vulnerability due to the breadth of access granted to the application over the directory.

The Resource '*' is mandatory for all User permission scopes.

Why wrong: The Resource '*' is not mandatory and is actually a sign of poor policy design. Best practices dictate scoping access to specific resources or subsets whenever possible to limit blast radius. Suggesting it is mandatory is technically incorrect and dangerous, as it encourages the use of over-privileged policies.

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.

Reset the user's password.

Why wrong: Resetting a password does not address a Conditional Access failure. If the error is related to CA, the user's credentials were valid, but they failed to meet the security requirements for the resource (e.g., non-compliant device). Changing the password will not satisfy these security requirements.

Ask the user to clear their browser cache.

Why wrong: While clearing a cache is a common troubleshooting step for general web issues, it has no impact on Conditional Access policy enforcement, which is evaluated server-side by Entra ID. The policy failure will persist regardless of the client-side browser state until the underlying requirement is satisfied.

Disable all Conditional Access policies for the tenant.

Why wrong: Disabling all policies is a dangerous practice that leaves the entire tenant vulnerable to unauthorized access. Troubleshooting should be surgical and focused on the specific user and policy involved, rather than compromising the security posture of the entire organization to fix a single user's access issue.

The user retains the permissions indefinitely without needing to take any further action.

Why wrong: This describes a permanent assignment, not an eligible one. Eligible assignments are strictly about requiring an activation process, meaning the user does not have permissions until they successfully navigate the request and approval workflow defined in the PIM settings for that specific role assignment.

The user is automatically notified via email whenever an administrative change occurs.

Why wrong: While notification settings can be configured in PIM, it is not the primary outcome of choosing 'Eligible' over 'Permanent'. The main outcome is the transformation of static, dangerous standing access into dynamic, audited, and time-bound privileged access that is governed by specific activation requirements.

The user can bypass Conditional Access policies when activating the role.

Why wrong: PIM activation does not bypass Conditional Access. In fact, it often enforces stricter Conditional Access requirements. Claiming that PIM allows bypassing these policies is incorrect and represents a fundamental misunderstanding of how Entra identity governance functions to protect privileged accounts from unauthorized use or compromise.

Create a policy requiring 'Require approved client app'.

Why wrong: While this ensures the user uses an app like Outlook rather than a native mail client, it does not confirm the device itself is managed or compliant. An attacker could still install the approved app on a personal, insecure device and gain access if this is the only control.

Configure an App Protection Policy in the Microsoft Entra portal.

Why wrong: App Protection Policies are configured in Intune, not in the Conditional Access blade of Entra ID. While they help secure data within apps, they are not the mechanism for enforcing device-level access controls during the authentication flow as requested in the scenario.

Set the user session frequency to 1 hour.

Why wrong: Session frequency limits how often a user must re-authenticate. It does not evaluate the device's compliance status. While it might force a re-check of policy, it does not in itself define or enforce the requirement that a device must be managed to gain access to the resource.

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.

The user entered an incorrect password multiple times.

Why wrong: Incorrect passwords result in a 'Failure' status with a specific error code indicating invalid credentials. The 'Interrupted' status is distinct from a credential failure; it reflects a policy-driven pause rather than a failed authentication attempt due to incorrect security information provided by the user during the login process.

The user's device is not compliant with company policy.

Why wrong: Non-compliant devices result in a 'Failure' status when a Conditional Access policy blocks access. The user is prevented from proceeding entirely, rather than having their session 'interrupted' to perform a task. The system denies the request based on the device state, not a pending user action.

The service principal has an expired client secret.

Why wrong: Expired secrets or certificates lead to 'Failure' statuses during the token request process, not an 'Interrupted' status. Interrupted statuses are almost exclusively related to interactive user sign-ins where the user has the opportunity to resolve the requirement, whereas a service principal cannot perform these interactive actions.

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.

The user does not have sufficient permissions to access the application.

Why wrong: Insufficient permissions would result in a different error code, typically related to authorization (403 Forbidden). Error 50011 is strictly a configuration error related to the reply/redirect URI provided during the OIDC or SAML handshake, not an assessment of the user's rights or roles within the target application.

The client secret has expired.

Why wrong: An expired client secret typically leads to a 'client_authentication_failed' error, not an error related to a mismatched reply address. The reply address error is entirely dependent on the URI string matching the pre-configured value, regardless of the validity of the secrets used by the application to authenticate.

The user is using an unsupported browser.

Why wrong: Browser support issues might cause layout or script errors, but they do not cause a specific '50011' error from the identity provider. This error is a server-side rejection of the authentication request parameters, which is independent of the client-side browser type or version being used by the end user.

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.

Create a local user account in the tenant.

Why wrong: Creating local accounts for contractors is a security anti-pattern. It forces you to manage their credentials, password resets, and life cycle manually. Using B2B allows the guest to use their own home-tenant credentials, which is more secure and shifts the burden of credential management to the contractor's organization.

Create a shared mailbox for the contractor.

Why wrong: Shared mailboxes are not intended for identity management. Using them to grant access to resources is insecure and bypasses standard identity governance processes. It provides a generic, non-auditable identity that lacks the granular security controls, MFA requirements, and lifecycle management features inherent in native Entra guest account management.

Share your own administrative credentials with the contractor.

Why wrong: Sharing credentials is a major security violation and a non-starter in any professional environment. It eliminates non-repudiation and makes it impossible to audit who performed specific actions. It is fundamentally insecure and would lead to immediate failure of any security audit, regardless of the technical controls in place.

Authenticator App (TOTP)

Why wrong: TOTP is vulnerable to phishing because the six-digit code can be entered into a fraudulent website by an attacker. While it is better than SMS, it is still not considered 'phishing-resistant' because there is no cryptographic binding to the service origin or the specific authentication context being provided.

Windows Hello for Business

Why wrong: While Windows Hello for Business is secure, it is technically a biometric or PIN-based method that unlocks a key stored on the device. While it is strong, FIDO2 security keys are specifically defined as the gold standard for phishing-resistant MFA across all platforms and environments, regardless of the OS in use.

OATH hardware tokens

Why wrong: OATH hardware tokens generate time-based codes similar to TOTP apps. They are not phishing-resistant because the code they generate can be phished just like an app-based TOTP code. They are a legacy MFA method that does not provide the cryptographic origin-binding required for modern phishing resistance.

It allows granular exclusion of specific users from MFA requirements.

Why wrong: Security Defaults are 'all or nothing'. They do not support granular exclusions or custom policy settings. This is a deliberate design choice to ensure that the security baseline remains intact across the entire tenant, preventing administrators from accidentally weakening their posture by excluding specific users from the required controls.

It provides advanced threat protection for cloud-based virtual machines.

Why wrong: Security Defaults are focused on identity and authentication. They do not extend to infrastructure-as-a-service (IaaS) security, such as virtual machines, disk encryption, or network security groups. Protecting virtual machines requires dedicated Azure services like Microsoft Defender for Cloud, which operate independently of the identity-focused security defaults in Entra ID.

It automatically upgrades the tenant to a Premium P2 license.

Why wrong: Security Defaults are available in all tiers of Microsoft Entra ID, including the free tier. Enabling them does not change the licensing level of your tenant. They are a free, essential feature intended to provide baseline protection to all customers, regardless of their subscription plan or the size of their organization.

Disable the POP3 and IMAP4 services at the tenant level within the Microsoft 365 Admin Center for every individual user mailbox.

Why wrong: Disabling protocols at the mailbox level is an administrative burden and does not provide a centralized security policy. While it technically stops the protocols for specific users, it fails to address broader access management requirements. Conditional Access provides a more scalable and policy-driven approach to securing the entire tenant against insecure authentication methods.

Enable Security Defaults in the Microsoft Entra admin center to automatically manage all authentication and security settings for the tenant.

Why wrong: Security Defaults provide basic protection by blocking legacy auth, but they are an all-or-nothing setting that cannot be customized. Organizations with existing Conditional Access policies cannot enable Security Defaults without first disabling those policies. For an organization needing specific control over modern authentication, Conditional Access is the preferred and more flexible tool.

Update the default Authentication Policy in Exchange Online to set the AllowBasicAuth setting to false for all available mail protocols.

Why wrong: Modifying Exchange Online authentication policies targets only mail-related traffic and does not cover other Microsoft Entra ID services. While it helps secure mailboxes, it does not provide the unified access control found in Conditional Access. A comprehensive security strategy requires a solution that covers all cloud applications and integrated identity services across the tenant.

MFA registration policy

Why wrong: The MFA registration policy ensures that users are prompted to set up their multi-factor authentication methods before they are actually required. While this is a critical preparatory step for identity protection, it does not automatically remediate active risks like a user risk policy does. It is a deployment tool rather than a real-time risk mitigation or automated remediation control.

App protection policy

Why wrong: App protection policies are primarily used within Microsoft Intune to manage and protect corporate data at the application level on mobile devices. They focus on data loss prevention, such as preventing the copying of data between managed and unmanaged apps. They do not analyze identity risks or provide the automated sign-in remediation found in Identity Protection.

Device compliance policy

Why wrong: Device compliance policies define the security requirements a device must meet, such as encryption and OS version, to be considered compliant. These policies are evaluated by Microsoft Intune and used as a signal in Conditional Access. They do not monitor user-level risks or sign-in anomalies based on behavioral analytics provided by the Entra ID Protection service.

Access is granted only to users within the US_Named_Location if they pass MFA.

Why wrong: This policy does not specify a 'Grant' control requiring MFA; instead, it uses a 'Block' control. Conditional Access policies are either Grant-based or Block-based. While users in the US might be granted access by other policies, this specific policy only defines who is blocked. It does not provide any instructions for MFA or other specific grant requirements.

Access is blocked for all users regardless of their current geographic location.

Why wrong: The 'excludeLocations' property prevents the block from applying to everyone. If the policy were intended to block everyone, the 'excludeLocations' list would be empty or absent. Because 'US_Named_Location' is listed as an exclusion, users matching that specific location property are not affected by this specific block rule, allowing them to proceed to other policy evaluations.

Access is granted to all users as long as they are not in the US_Named_Location.

Why wrong: The policy logic is the inverse of this statement. The 'Grant' control is set to 'block', meaning the action taken on included locations is to deny access. Users outside the exclusion are blocked, while users inside the exclusion are simply ignored by this policy. This policy does not have the capability to grant access; it can only deny it.

The registration policy in Microsoft Entra ID Protection for MFA enrollment.

Why wrong: While the MFA registration policy ensures users sign up for authentication methods, it does not specifically handle the periodic re-confirmation of existing SSPR data. The MFA registration policy is designed to get users into the system initially. Re-confirmation is a distinct lifecycle management feature found specifically within the SSPR settings menu, rather than the Identity Protection risk policies.

The password expiration policy within the Microsoft 365 Admin Center settings.

Why wrong: Password expiration policies manage how often a user must change their actual password string to meet compliance or security requirements. This is unrelated to the verification of the recovery methods used to reset that password. Modern security best practices often recommend against frequent password expiration, focusing instead on strong authentication and maintaining accurate, verified recovery contact information.

The 'Notify users on password resets' toggle in the SSPR notification settings.

Why wrong: The notification setting determines whether an email is sent to the user after a successful password reset has occurred. It is a post-event security measure intended to alert users of potential unauthorized changes to their account. It does not play a role in the proactive verification or maintenance of the contact information that is stored for use during the reset process.

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.