Implement and manage Microsoft Entra identity and access practice questions

SMS sign-in

Why it fails: SMS sign-in is not a primary authentication method in Microsoft Entra ID; SMS is used only to deliver one-time passcodes for multifactor authentication or self-service password reset. Conditional Access authentication strength does not list SMS as a method because it lacks cryptographic proof of possession and is susceptible to SIM-swap attacks. Therefore, SMS sign-in is not a valid authentication method.

Hardware OATH token

Why it fails: Hardware OATH tokens generate time-based one-time passwords and are registered as a secondary verification factor for MFA, not as a primary identity credential. In Conditional Access, an OATH token can only be required as a second factor after the user has already signed in with a primary method such as a password. Because the token does not identify the user on its own, it is not a valid authentication method.

FIDO2 security key

Why it fails: FIDO2 security keys are a passwordless authentication option, but Conditional Access does not expose them as a separate authentication strength method; they are grouped under the broader 'Passwordless' or phishing-resistant authentication strength. In Microsoft Entra ID, authentication strength bundles FIDO2 with Windows Hello for Business and certificate-based authentication rather than offering a distinct 'FIDO2' grant control. For this question, the valid methods are Password and Certificate-based authentication, so FIDO2 is incorrect.

Set up Microsoft Entra Connect Sync for the application

Why it fails: Incorrect. Microsoft Entra Connect Sync is for synchronizing on-premises directories; it is not required for provisioning to a cloud SaaS app.

Migrate from Microsoft Entra Connect to Microsoft Entra Connect cloud sync

Why it fails: Incorrect. Migrating to cloud sync is unrelated; it's a different synchronization method, not needed for SaaS app provisioning.

Install and configure a provisioning agent in your on-premises environment

Why it fails: Incorrect. A provisioning agent is used for on-premises applications, not for cloud-based third-party SaaS apps.

Requires MFA for all users accessing all apps from any client type

Why it fails: Only mobile apps and desktop clients are included.

Blocks access for all users except Admin@contoso.com when accessing from mobile apps

Why it fails: The policy grants MFA, not blocks.

Requires MFA for all users accessing all apps from any device

Why it fails: Excludes Admin and only applies to mobile apps and desktop clients.

Disable sign-in for the emergency access accounts until needed

Why it fails: Disabling sign-in would prevent their use in an emergency.

Make the emergency access accounts cloud-only and enforce MFA

Why it fails: Emergency accounts should not have MFA to avoid lockout.

Assign FIDO2 security keys to the emergency access accounts

Why it fails: FIDO2 keys may not work if the authentication infrastructure is down.

Terms of Use

Why it fails: Terms of Use in Microsoft Entra ID are presented to users during sign-in through conditional access, requiring acceptance of legal or policy documents before access to applications. They are static acceptance records and do not initiate recurring access reviews, expire guest assignments, or otherwise manage the guest access lifecycle. Since they provide no entitlement governance actions, they cannot be used to automate access reviews for guest users.

Access Reviews

Why it fails: Access Reviews is a feature that lets you create attestation tasks to verify whether users still need access, and it can be scheduled to repeat on a regular basis. However, it only reviews existing entitlements; it does not provision or remove guest access by itself. To link access reviews to the full guest lifecycle and take action automatically, Entitlement Management access package policies are required to schedule the review and act on its outcome, making Access Reviews a supporting component rather than the orchestrator of the automation.

Privileged Identity Management

Why it fails: Privileged Identity Management (PIM) is designed to provide just-in-time activation for Microsoft Entra ID roles and Azure resource roles, typically with approval or multi-factor authentication required for elevation. PIM's access reviews focus on users who hold privileged admin roles, not guest users' access to applications, groups, or SharePoint sites. Because the requirement is about automating guest access reviews, not admin role activation, PIM does not address this scenario.

Password spray

Why it fails: Password spray is a type of brute-force attack where an attacker tries a small number of common passwords against many accounts to avoid lockout. Microsoft Entra ID Protection treats password spray as a sign-in risk detection, not a user risk, because it indicates suspicious authentication attempts rather than confirmed compromise of a specific user. While it contributes to the overall risk, it is not a user risk itself.

Malware

Why it fails: Malware detection is not part of Microsoft Entra ID Protection risk detections. Instead, malware is identified by Microsoft Defender for Endpoint or other threat protection solutions, which focus on devices and endpoints. Entra ID Protection only evaluates identity-based risk signals like sign-in patterns and credential exposure, so malware is outside its scope.

Microsoft Entra ID P2

Why it fails: Microsoft Entra ID P1 already includes self-service password reset for cloud users, so P2 exceeds the minimum requirement. P2 is tempting because it adds Identity Protection and risk-based conditional access, which are needed only when SSPR must be gated by risk detection or writeback to on-premises directories.

Microsoft 365 Business Basic

Why it fails: Microsoft 365 Business Basic includes Entra ID Free, but it is not the minimum licensing required because the free tier can be used standalone without any paid subscription.

Microsoft Entra ID P1

Why it fails: Microsoft Entra ID P1 is a premium license that includes SSPR, but it is not the minimum because the free tier already covers cloud-only users.

Set user consent to 'Do not allow user consent'.

Why it fails: Setting user consent to 'Do not allow user consent' in Entra ID blocks users from granting any permissions to applications, regardless of risk level. While this maximizes security by forcing every consent request through an administrator, it also disables low-risk self-service consent for enterprise apps. As a result, this approach is overly restrictive for the requirement to allow low-risk permissions while still requiring admin approval for high-risk ones.

Set user consent to 'Allow user consent for apps'.

Why it fails: Choosing 'Allow user consent for apps' enables users to consent to any application permission, including those classified as high-risk or requiring admin consent, without any admin review. This effectively eliminates consent governance and exposes the tenant to potentially dangerous Graph API permissions and broad data access. It does not satisfy the need for differentiated handling based on permission risk, making the tenant vulnerable to malicious or over-privileged applications.

Create a Conditional Access policy that blocks high-risk consent.

Why it fails: Creating a Conditional Access policy to block high-risk consent is ineffective because Conditional Access policies only evaluate authentication and session context, not consent grants or permission requests. Consent decisions are exclusively controlled by the consent and permissions settings in Enterprise applications, such as user consent settings, permission classifications, and the admin consent workflow. Therefore, such a policy would not prevent users from consenting to high-risk permissions and fails to meet the security objective.

Multi-factor authentication settings.

Why it fails: Multi-factor authentication (MFA) settings require users to provide a second form of verification—such as a mobile app code, phone call, or hardware token—after entering their correct password. While MFA significantly strengthens sign-in security by mitigating credential theft, it does not manage or enforce password history in any way. Password reuse prevention is handled solely by password policies, not by the number or type of authentication factors required.

Account lockout threshold.

Why it fails: The account lockout threshold determines how many consecutive failed sign-in attempts a user can make before their account becomes temporarily locked. This setting protects against brute-force password guessing by denying further attempts after a threshold is reached, but it has no relationship to password change operations or password reuse. Even with a strict threshold, a user could still reuse an old password when changing it, because lockout only triggers on failed logins, not on password update requests.

Smart lockout settings.

Why it fails: Smart lockout is a Microsoft Entra ID feature that detects and blocks malicious sign-in attempts based on heuristics and user behavior, allowing legitimate users while locking out attackers. It automatically adapts its lockout rules based on IP reputation and sign-in patterns, but it only operates during the authentication process. Smart lockout cannot enforce password history because it never evaluates the content or uniqueness of a user's submitted password during a password change—it merely protects the sign-in flow from intrusion.

Assign the existing role to the user and create a Conditional Access policy that blocks credential update.

Why it fails: Conditional Access cannot block specific permission usage.

Assign the built-in Application Administrator role instead.

Why it fails: Application Administrator includes credential update permission.

Create a new custom role and manually add all permissions except credential update.

Why it fails: Manually adding all permissions is error-prone and time-consuming.

Microsoft Entra ID P1 or P2 license.

Why it fails: Microsoft Entra ID P1 or P2 licenses are premium editions that add capabilities like conditional access, Privileged Identity Management, and on-premises password writeback for hybrid identities. However, for cloud-only users, the self-service password reset feature is available in the free Microsoft Entra ID tier included with any paid Microsoft 365 license, so premium licenses are not a requirement. You only need P1/P2 if you want SSPR for synchronized on-premises users with writeback.

Microsoft Entra Connect synchronization.

Why it fails: Microsoft Entra Connect (or Microsoft Entra Connect) is a synchronization tool that connects on-premises Active Directory to Entra ID, primarily for hybrid environments. Since cloud-only users are created and managed entirely in Entra ID, there is no directory to sync, so the tool is unnecessary for configuring SSPR. Even in hybrid scenarios, sync itself does not enable SSPR—it is the licensing and user configuration that matters.

Users must register for MFA.

Why it fails: Microsoft Entra ID MFA registration, which enrolls users in multi-factor authentication security defaults, is a separate security feature that is not a prerequisite for SSPR. Users of SSPR must instead register authentication methods such as a mobile phone, alternate email, or security questions directly in the password reset portal. While some admins combine MFA and SSPR registration for convenience, the latter functions independently and does not require any MFA enrollment.

Risk detections such as leaked credentials and anonymous IP address.

Why it fails: Risk detections such as leaked credentials and anonymous IP address are types of risk detections, not features of Identity Protection. The features are the policies (sign-in risk and user risk).

Conditional Access policies integration.

Why it fails: While Conditional Access policies can integrate with Identity Protection, Conditional Access itself is a separate feature of Microsoft Entra ID. Identity Protection provides risk-based policies.

Advanced Threat Protection (ATP) for identities.

Why it fails: Advanced Threat Protection for identities is a separate product (now part of Microsoft Defender for Identity), not a feature of Identity Protection.

Only administrators are targeted for registration.

Why it fails: The IncludeTargets property in the PowerShell output is set to all_users, which explicitly includes every user type in the tenant, not just those with administrative roles. A configuration that targeted only administrators would instead show a value such as admin_users or a group containing privileged accounts. Because no such role-based restriction appears in the output, the statement that only administrators are targeted is false.

Users in the ExcludeTargets group will be excluded.

Why it fails: The ExcludeTargets array in the returned output is empty, which means no users or groups are currently carved out of the registration campaign. An exclusion would only occur if there were at least one target object—such as a specific group ID—listed in that collection. Since the array has no entries, the premise of this statement is factually incorrect.

The registration campaign is disabled.

Why it fails: The PowerShell output clearly displays the State property as enabled, which is the opposite of disabled. When a registration campaign is disabled, the State value would be set to disabled, causing the email prompts to be suppressed; that is not what the output shows. Therefore, the assertion that the campaign is disabled is directly contradicted by the command's result.

Federation with AD FS

Why it fails: Federation with AD FS issues security tokens based on authentication performed by on-premises Active Directory. Although AD FS supports a wide range of authentication methods (including certificates and smart cards in certain configurations), the most common deployment still relies on users entering their Active Directory domain password at a login prompt. The password is the underlying credential that unlocks access; federation merely moves the authentication event from the cloud back to the on-premises AD FS proxy. Therefore, AD FS does not satisfy a passwordless requirement because the username/password pair remains the primary authentication factor.

Password hash synchronization

Why it fails: Password hash synchronization (PHS) is a synchronization technology that copies a salted hash of a user's on-premises Active Directory password into Entra ID. While this enables users to use the same password for cloud resources, it does not eliminate the password itself—the user still must type the password, and the hash is simply replicated to a second directory. The credential material remains a shared secret that can be replayed against the cloud if the hash is compromised (though mitigated by features like hash sync'ing and smart lockout). PHS is a password-based sign-in mechanism, not passwordless, because the secret is still ultimately the password.

Pass-through authentication

Why it fails: Pass-through authentication (PTA) validates a user's password by having the Entra ID authentication service forward the plaintext password to an on-premises agent, which checks it against the local Active Directory domain controller. Unlike PHS, PTA never stores password hashes in Entra ID; however, the security token is still derived from the user typing their exact password at sign-in. The process fundamentally depends on the password being sent and validated over the wire every time, so it offers no passwordless experience. PTA simply keeps password verification on-premises while retaining the password as the sole authentication factor.

Use Microsoft Defender for Cloud Apps session controls

Why it fails: Microsoft Defender for Cloud Apps session controls use a reverse proxy to monitor and restrict web-app sessions in real time, such as blocking downloads from a sanctioned SaaS app. These controls only apply to browser-accessible web applications and cannot intercept Copilot, which is embedded across Microsoft 365 services and client apps rather than a single proxy-able web endpoint. Additionally, session controls do not evaluate sensitivity label metadata or enforce file-level classification; they govern app action behavior, not the licensed data content Copilot ingests. Therefore, session controls are not a mechanism to require labels for Copilot data access.

Configure Privileged Identity Management (PIM) for Copilot roles

Why it fails: Privileged Identity Management (PIM) provides just-in-time, time-bound, and approval-based activation of built-in Entra ID roles, such as Global Administrator or Security Administrator, to reduce standing privilege. While you could assign a role like 'Copilot Administrator' via PIM, that role only manages Copilot settings and lifecycle; it confers no control over which labeled documents Copilot can retrieve or synthesize. PIM governs role assignment and elevation, not data access permissions, and it has no awareness of sensitivity label enforcement or Conditional Access conditions. Thus, PIM cannot ensure that Copilot only accesses data carrying required sensitivity labels.

Enable Identity Protection for Copilot users

Why it fails: Identity Protection continuously evaluates sign-in risk and user risk, enabling conditional policies to force MFA, block risky sign-ins, or require password changes for compromised accounts. It is a security control for the authentication path, not the authorization path for content-based data access. Even if a user passes all Identity Protection checks, Copilot will still retrieve any data that the user's existing permissions allow, regardless of whether the data carries a sensitivity label. Since the requirement is to enforce label-based data access for Copilot, Identity Protection does not address missing or misapplied sensitivity labels.

Temporary Access Pass

Why it fails: Temporary Access Pass is for recovery, not passwordless.

Windows Hello for Business

Why it fails: Windows Hello requires a Windows device.

Text message (SMS) verification code

Why it fails: SMS is not passwordless; it's a second factor.

The policy does not exclude specific users

Why it fails: The policy does not exclude specific users; this would not cause the policy to fail enforcement for included users.

The policy does not include all cloud apps

Why it fails: The policy does not include all cloud apps; but the reported issue is about the ones included still being accessible from non-compliant devices.

The grant control operator is set to "OR" with only one control, which requires no controls to be satisfied

Why it fails: Having a single grant control with the OR operator still requires that control to be satisfied. This is not the most likely reason for the reported behavior.

The query uses ago(30d) but the data retention is only 7 days

Why it fails: If retention were 7 days, the query would return data for the last 7 days, not zero.

The summarize statement is incorrect

Why it fails: The summarize syntax is correct.

The query excludes successful sign-ins

Why it fails: The query includes failed attempts only.

The group has more than 500 members

Why it fails: There is no 500-member limit for group-based licensing. Microsoft Entra ID can process license assignments for groups of any size, including dynamic or assigned groups with thousands of members. While very large groups may take longer to evaluate and may require careful monitoring of the licensing processing logs, the group size itself does not prevent the license from being applied.

The group is a dynamic group

Why it fails: Dynamic groups are fully supported for group-based licensing. Entra ID evaluates dynamic membership rules on a schedule and automatically applies or removes licenses based on the current group membership. Choosing a dynamic group as the licensing group does not block license assignment, so a dynamic group cannot be the reason a user fails to receive a group-assigned license.

The product license is out of stock

Why it fails: Group-based licensing assigns licenses only if enough seats or product units are available in the tenant. If the product is completely exhausted, license assignment will fail, but Entra ID records a specific error in the licensing processing logs for that user, such as a quota or stock error. Therefore, 'out of stock' is not a silent conflict; it produces a visible error state, not the situation described in the scenario.

Use identity protection to enforce MFA for risky sign-ins

Why it fails: Identity Protection enforces MFA only for sign-ins assessed as risky, leaving normal sign-ins single-factor, so it does not cover all users. It is tempting because it targets MFA precisely where risk is detected, and would be correct when the requirement is risk-based rather than blanket enforcement.

Assign MFA per user in the Microsoft Entra admin center

Why it fails: Per-user MFA is legacy and, when enabled, prompts users to register security info at next sign-in regardless of existing methods. It is tempting because it enforces MFA for named accounts without Conditional Access licensing, and would be correct for a small pilot group rather than a tenant-wide rollout preserving registrations.

Enable security defaults

Why it fails: Security defaults enforce MFA tenant-wide but require every user to register authentication methods, including those with existing security info. It is tempting because it is a free, one-click baseline for tenants without Conditional Access licences, and would be correct where no existing registrations must be preserved.