Secure identity and access practice questions

Configure conditional access policies to require device compliance

Why it fails: Conditional Access policies that require device compliance are authorization rules evaluated after authentication, not an authentication mechanism. A compliant device check may block or allow access, but the user still has to provide credentials interactively on first sign-in because CA does not create a security token or cache credentials behind the scenes. In fact, requiring device compliance can add extra MFA or reauthentication requirements, so it does nothing to eliminate or reduce the sign-in prompts you are trying to avoid.

Enable B2B collaboration for the app

Why it fails: B2B collaboration is designed to invite external guest users from other organizations into your tenant so they can access specific apps, and it has no bearing on the authentication experience of your own employees. Enabling B2B for an internal app does not change how domain-joined users are authenticated or whether they see credential prompts. It also introduces external-collaboration settings and user management overhead that are irrelevant to reducing sign-in frequency for your internal workforce.

Set 'Session lifetime' to 'Permanent' in sign-in frequency

Why it fails: The 'Session lifetime' to 'Permanent' option in sign-in frequency only extends how long an already-established session remains valid before the user is asked to reauthenticate, and it does not affect the initial interactive logon. Even with a permanent session, a user who has not yet signed in will still be prompted for username and password once. Additionally, making sessions permanent can weaken security because stolen tokens or devices retain access much longer, which is particularly undesirable if the goal is to reduce prompts without sacrificing control.

Privileged Identity Management (PIM) with approval workflow

Why it fails: Privileged Identity Management with approval workflow governs just-in-time activation of Microsoft Entra ID roles like Global Administrator, requiring human approval for privileged role elevation. It does not, however, evaluate every user's access to all resources, nor does it enforce access policies continuously for regular users and workloads. As a result, it cannot provide real-time revocation of an already-issued token based on a policy change.

Conditional Access with session controls

Why it fails: Conditional Access with session controls applies policies at the moment of sign-in and can restrict a session, for example by enforcing MFA re-authentication or device compliance. However, those controls are evaluated only when the session is established, and they do not pause or revoke an active token if the user's risk profile changes mid-session. Continuous Access Evaluation differs by actively checking critical events and token expiration in real time.

Identity Protection with sign-in risk policy

Why it fails: Identity Protection with a sign-in risk policy evaluates machine-learning risk scores at the initial authentication attempt and then either blocks the sign-in or prompts for multi-factor authentication. Once the token is issued, though, Identity Protection does not continuously monitor the session; a subsequent risk event, such as token replay or anomalies during the session, goes unchecked. It therefore fails to provide the ongoing runtime enforcement that zero trust demands.

Use an Azure Automation runbook to disable users after 90 days

Why it fails: An Azure Automation runbook can disable accounts through PowerShell on a 90-day schedule, but this is a custom operational script rather than a native Entra ID Governance control. It lacks the attestation workflow, reviewer sign-off, and built-in audit trail that Access Reviews provide, and it cannot distinguish between users who are actively needed and those who are merely inactive. Automating 'disable after 90 days' ignores exceptions, access owners, and the human certification step required for compliant access removal.

Enable 'Inactive users' policy in Identity Protection

Why it fails: Identity Protection's policies are risk-based and designed to protect against compromised accounts by requiring MFA or blocking risky sign-ins, not to remove existing access because a user hasn't signed in. There is no 'Inactive users' policy in Identity Protection that disables or unassigns access; inactivity is surfaced as an insight within Access Reviews, where a reviewer makes the removal decision. Enabling a risk policy would not satisfy an Entra ID Governance requirement for periodic certification of continued access.

Create a dynamic group based on sign-in activity

Why it fails: Even if a dynamic group rule could be configured around sign-in activity, Entra ID's dynamic membership engine does not expose a reliable 'days since last sign-in' attribute, and changing group membership only affects access when the target resource is governed by that group. Dynamic groups do not automatically remove direct assignments, nor do they provide the attestation, approval, and audit history required by Entra ID Governance. Without a reviewer certifying that access is no longer needed, this approach is not a compliant removal control.

Windows Hello for Business

Why it fails: Windows Hello for Business requires the user to be on a Windows 10 or Windows 11 device that is Microsoft Entra ID joined or hybrid Microsoft Entra ID joined. It creates a device-bound credential protected by a TPM, so the user cannot use it from unmanaged personal devices or other operating systems. Because many of your 10,000 users may not have managed Windows devices, this does not meet the requirement.

Certificate-based authentication (CBA)

Why it fails: Certificate-based authentication (CBA) mandates that a client certificate be issued to each user and installed on every device they use to sign in. This demands a PKI infrastructure, certificate enrollment (e.g., via Intune or manual import), and ongoing certificate renewal/revocation management. On unmanaged devices, you cannot centrally provision certificates, making this impractical for the described scenario.

FIDO2 security keys

Why it fails: FIDO2 security keys require every user to be issued a physical hardware token, which introduces per-user procurement, shipping, and replacement costs. While a FIDO2 key can be used on many unmanaged devices, the user must carry it and plug it in each time, and if the key is lost, sign-in is blocked until a new one is provisioned. This hardware dependency makes it less suitable than a software-based solution for a large user base.

Microsoft Entra Connect Health

Why it fails: Microsoft Entra Connect Health is a telemetry and monitoring service for hybrid identity components like Microsoft Entra Connect and Active Directory Federation Services. It tracks sync errors, authentication health, and provides alerts, but it has no ability to enforce security actions or alter a user's authentication state. Therefore it cannot revoke sessions or force reauthentication after a credential compromise.

Microsoft Entra Domain Services

Why it fails: Microsoft Entra Domain Services provides managed domain services such as Group Policy, LDAP, and Kerberos/NTLM authentication to Azure virtual machines and legacy workloads. It is an infrastructure service that extends a domain to the cloud; it does not process interactive sign-ins to Microsoft Entra ID or manage session/token state. Consequently, it cannot be used to revoke a user's access or force reauthentication in a hybrid identity incident.

Seamless SSO

Why it fails: Seamless SSO silently uses the user's on-premises Kerberos ticket when accessing Microsoft Entra ID, automatically authenticating them without a password prompt. Its purpose is to reduce authentication friction, so it actually lowers the chance of reauthentication triggers. It does not revoke existing tokens or enforce session controls, and in this scenario it would only help perpetuate an attacker's access, not break it.

Enforce device compliance via Intune

Why it fails: Incorrect. Enforcing device compliance via Intune is not a capability of ID Protection.

Manage FIDO2 security keys

Why it fails: Incorrect. Managing FIDO2 security keys is not a capability of ID Protection.

Configure risk-based conditional access policies

Why it fails: Incorrect. Configuring risk-based conditional access policies is a feature of Conditional Access, not ID Protection itself.

All Users

Why it fails: Static group, not dynamic.

Sales Team

Why it fails: Dynamic group for sales.

Administrators

Why it fails: Dynamic group for administrators, not finance.

Grant access, require approved client app

Why it fails: The 'Require approved client app' grant restricts access to specific Microsoft apps (for example, Outlook or Teams) that have been identified as approved, and it can also enforce app protection policies. However, this control does not query the device's compliance status from Intune/MDM, so a device that is lost, jailbroken, or missing critical security patches can still access resources as long as it uses an approved app. Thus it validates the app and data protection, not the device itself, which is why it does not meet the untrusted-location requirement.

Block access

Why it fails: The 'Block access' grant rejects all sign-in attempts from untrusted locations, regardless of whether the device is compliant or the user has already satisfied MFA. While this is secure, it is operationally unacceptable because it prevents even healthy, managed devices from working remotely and creates an all-or-nothing policy that ignores the risk signals available in Entra ID. The requirement is to permit compliant devices, not to deny all untrusted traffic, so this grant is too restrictive for this scenario.

Grant access, require multi-factor authentication

Why it fails: The 'Require multi-factor authentication' grant validates the user by requiring a second factor, such as a phone call, TOTP, or FIDO2 security key, but it does not assess the security posture of the device. A compromised or non-compliant device can still pass MFA and access resources because MFA proves only that the user has possession of the second factor, not that the device is up to date, encrypted, or free of malware. Therefore, MFA alone does not enforce device compliance and is insufficient for access from untrusted locations.

Privileged Identity Management

Why it fails: Privileged Identity Management (PIM) does not perform risk detection; it manages elevation of privileged roles with just-in-time activation, multi-factor authentication challenge, and approval/justification workflows. While PIM may appear related to protecting privileged accounts, it has no visibility into sign-in risk or user risk signals such as impossible travel or leaked credentials. The intended feature for detecting and responding to these risks is Entra ID Protection's risk policies.

Conditional Access policies

Why it fails: Conditional Access policies are the enforcement layer and can only use risk level as a condition—for example, 'Block access' or 'Require MFA' when sign-in risk is medium or high. However, the detection itself is performed upstream by Entra ID Protection's risk engine, which calculates user and sign-in risk from signals like anonymous IP addresses or atypical travel. Therefore, Conditional Access alone cannot detect risk; risk policies are what enable detection and automated remediation.

Identity Governance

Why it fails: Identity Governance focuses on access reviews, entitlement management, and lifecycle processes such as automatically removing a user's access when they leave the organization or when their role changes. It does not consume the telemetry and analytics that produce user risk or sign-in risk scores, and it cannot respond to a leaked-credential event. Any risk-based capability in Identity Governance is limited to policy violations or access certifications, not the risk detection you need.

Azure AD B2C

Why it fails: Azure AD B2C is a customer identity and access management (CIAM) service designed for consumer-facing applications, where users authenticate via local accounts, social providers, or SAML/OpenID Connect IdPs. It does not support partner organization collaboration because it creates isolated directory tenant instances for customers, not guest accounts in your own tenant. Moreover, B2C has no cross-tenant access settings integration, so you cannot enforce automatic revocation when a partner removes a user, making it unsuitable for B2B partner lifecycle governance.

Direct federation

Why it fails: Direct federation via SAML or WS-Federation is for partners whose identity provider is not Microsoft Entra ID, such as an on-premises AD FS or a third-party IdP. While it enables partners to use their own credentials, it does not provide automatic revocation because sessions rely on token expiration and there is no user lifecycle integration with the home IdP. Additionally, direct federation cannot leverage cross-tenant access settings for granular trust policies, so you lose the ability to enforce per-tenant MFA or conditional access rules, making it less secure for ongoing partner access.

SharePoint external sharing

Why it fails: SharePoint external sharing controls access to sites, documents, and lists at the resource level, allowing external users to authenticate as guests or via anonymous sharing links. It is not an identity federation solution, so it does not create a directory-level guest account for the partner organization or integrate with their user lifecycle. Consequently, if a partner user is deleted or disabled, any previously granted links or sharing permissions remain valid until manually revoked, and you cannot apply conditional access or automatic revocation based on the partner's home tenant state.

The policy is not assigned to any locations

Why it fails: The conditional access policy is explicitly configured to include all locations. In Microsoft Entra ID, the location condition can be set to include or exclude specific IP ranges, countries, or “All locations.” When “All locations” is selected, the policy applies to every network origin, so a user connecting from any IP address would still be subject to the policy. Therefore, a location misconfiguration cannot explain why access is allowed.

The policy does not include all applications

Why it fails: The policy is set to include all cloud applications. The application condition in a conditional access policy allows targeting specific applications or “All cloud apps.” When “All cloud apps” is chosen, the policy applies to every application in the tenant, including Exchange Online and Outlook Web Access. Since the policy already covers all applications, the app assignment is not the reason for the access being permitted.

The policy does not include all users

Why it fails: The policy is assigned to all users. The user/group condition in conditional access can include all users, specific users, or groups. If it includes all users, then every user, including the individual accessing Outlook for iOS, falls within the policy’s scope. Thus, a gap in user coverage cannot be the reason the policy fails to block the access, as the policy explicitly targets everyone.

Enable password hash synchronization

Why it fails: Password hash synchronization (PHS) is an Microsoft Entra Connect component that hashes on-premises user passwords and uploads them to Microsoft Entra ID so cloud sign-ins can verify credentials without federating; it has no role in evaluating password changes inside Active Directory. PHS only supports cloud authentication, and although it is often used alongside password protection in hybrid estates, it is not one of the two actions that implement on-premises banned-password enforcement. The local agent and the portal enablement perform that work, not PHS.

Install Microsoft Entra Connect

Why it fails: Microsoft Entra Connect is the synchronization tool that provisions user and group objects from Windows Server AD to Microsoft Entra ID, but it does not contain or install the password protection DC agent. While you might already use Connect in a hybrid environment, running its installation wizard will not register a password filter on domain controllers and will not apply the banned password list locally. The only way to enable on-premises password protection is to install the dedicated DC agent and enable the feature in the Azure portal.

Configure password writeback

Why it fails: Password writeback is a cloud-side feature that lets users who reset their password through Microsoft Entra ID self-service password reset push that new password back into on-premises Active Directory. It is concerned with writing new credentials from the cloud back to AD, not with blocking weak or compromised passwords at the time a user chooses one on-premises. Thus, writeback is an optional SSPR add-on, not an implementation step for Microsoft Entra ID Password Protection.

All

Why it fails: All is not a valid risk level in the Microsoft Entra ID Conditional Access sign-in risk condition. The risk-based policy engine only recognizes the discrete risk levels Low, Medium, and High; 'All' is not an option because it would include sign-ins with no detected risk, which would undermine the purpose of a risk-based conditional access policy. When configuring a policy, you must explicitly choose one or more of the three actual risk levels, either in the Microsoft Entra admin center or via the Microsoft Graph conditionalAccessPolicy API.

None

Why it fails: None is not a risk level that can be used in a Conditional Access sign-in risk condition. In Microsoft Entra ID, the risk levels are strictly Low, Medium, and High; 'None' is used in reporting to indicate that no risk was detected for a given sign-in. Since Conditional Access evaluates risk levels that have been actively determined, you cannot specify 'None' as a target because it would essentially match all sign-ins that are not risky, nullifying the intent of a risk-based policy. The only way to handle non-risky sign-ins is to exclude them by not setting a risk level or by using other conditions like group or location.

The role is permanently assigned

Why it fails: This is not the cause because the role is configured as an eligible assignment, not a permanent active assignment. A permanent assignment would grant the role immediately without requiring a PIM activation request, so the user would not need to see or request activation. Since the assignment is eligible, the user should be able to activate it unless another PIM setting blocks it.

The activation duration is set to 0 days

Why it fails: The activation duration in PIM specifies how long the role is active after approval. A duration of zero days would be invalid because PIM requires a minimum duration. In the exhibit, the duration is set to P1D (1 day), so this option is factually incorrect. Moreover, an incorrect duration would not hide the role; it would only affect the session length after activation.

The user did not provide a justification

Why it fails: A justification is required when a user requests activation for an eligible role. In this scenario, the user provided a justification, so this is not the issue. If a justification were missing, the PIM activation flow would prompt the user to enter one; the role would still be visible in the eligible assignments list. Thus, the lack of a justification cannot be the reason the user cannot activate the role.

24 hours

Why it fails: The policy output does not contain a 24-hour value anywhere; it explicitly sets AccessTokenLifetime to '01:00:00'. Although Microsoft Entra ID token lifetime policies can define access tokens up to a maximum of 24 hours, that cap applies to custom configurations and not to what the cmdlet returned. Confusing the configurable maximum with the output's explicit value is the error.

6 hours

Why it fails: A value of 6 hours corresponds to the maximum sign-in frequency permitted for single-factor authentication in Conditional Access session controls, not to the token lifetime shown in the policy. AccessTokenLifetime in the exhibit is independent of sign-in frequency and is set to 1 hour. Selecting 6 hours confuses a session control limit with the actual token lifetime property.

12 hours

Why it fails: The 12-hour value is the maximum allowed sign-in frequency for multi-factor authentication sessions, a separate Conditional Access setting from token lifetime. The policy's AccessTokenLifetime is explicitly configured to one hour, and no property in the output evaluates to 12 hours. This answer mistakes the MFA session cap for the reported access token lifetime.

The application's service principal has been accidentally disabled in the European tenant location.

Why it fails: A service principal is a tenant-wide object in Microsoft Entra ID; there is no separate 'European tenant location' where it could be disabled independently. The tenant's home geography is chosen at creation, but all directory objects are replicated globally across Microsoft's identity infrastructure and are not region-scoped. If the service principal were disabled, authentication would fail for every user and application worldwide, not just for users in Europe. A region-specific sign-in failure therefore cannot be caused by this scenario.

The Conditional Access policy requires multi-factor authentication for all users, and the MFA session token expired for European users.

Why it fails: MFA session tokens are issued by Microsoft Entra ID and are stored as tenant-wide session claims, not scoped to a specific geographic region. An MFA session expires based on the configured sign-in frequency or session lifetime, and that expiration logic is time-based, affecting all users who exceed the limit equally regardless of where they are physically located. Additionally, Entra ID silently maintains an already-satisfied MFA session by refreshing the assertion for subsequent token requests within the allowed window, so a regional cluster of expired MFA sessions is not plausible. A pattern limited to European users would require a location-specific access control, not an MFA session timeout.

The token lifetime policy for the application is set too low, causing European users to reauthenticate more frequently.

Why it fails: Token lifetime policies are evaluated at token issuance by the security token service and are applied uniformly to every user of the application across the entire Microsoft Entra tenant, irrespective of their continent. If the token lifetime were set too low, all users—whether in Europe, North America, or elsewhere—would be forced to reauthenticate at the same rate because the policy is globally scoped. Moreover, Microsoft now recommends using Conditional Access session controls for sign-in frequency rather than legacy token lifetime policies, which are not even applicable to all modern token types. A low token lifetime cannot explain why European users are uniquely impacted.

Create a Power Automate flow that triggers monthly to check sign-in logs and disable inactive users.

Why it fails: Not a built-in Microsoft Entra ID feature.

Use Microsoft Entra Connect to synchronize a 'disable' attribute from on-premises and set it for inactive users.

Why it fails: Entra Connect is for synchronization, not for detecting inactivity.

Write a PowerShell script using Microsoft Graph API to check last sign-in times and disable users.

Why it fails: This is not a built-in feature; it requires custom scripting.

Configure an app role assignment policy for the web API.

Why it fails: App roles (application permissions) define discrete permissions that can be granted to user, group, or service principal assignments, letting the API's authorization logic check those roles. An app role assignment policy is not a standard Entra ID construct for restricting which client applications can present tokens; it governs identity assignments, not inbound request source. Even if you assign an app role to a client app's service principal, the API must still independently validate the token's audience and client ID claims, whereas pre-authorization specifically whitelists the client apps in the API's manifest so the API knows to accept tokens from them.

Set a token lifetime policy on the web API to accept tokens only from approved client applications.

Why it fails: Token lifetime policies control how long an issued access or refresh token remains valid (e.g., max age, sliding window) and are configured tenant-wide or per app. They have no effect on which client application the token came from—the API's token validation can inspect the `azp` or `appid` claim to identify the caller, but a token lifetime policy cannot filter or approve client app IDs. Restricting callers to approved client applications is done through the API's pre-authorized applications list, not through a token expiration setting.

Create a Conditional Access policy targeting the web API and require that the client application is managed.

Why it fails: Conditional Access policies are evaluated for interactive user sign-in sessions and are used to gate a user's access to applications based on signal like device compliance, location, or risk. They do not apply to the internal service-to-service authentication flow where the client is an application (using client credentials or certificate) rather than a user, and they do not have a condition that restricts the calling client application's identity. Therefore, such a policy cannot prevent a non-approved client app from calling the web API; only the API's own authorization logic or pre-authorization settings can enforce that restriction.

Configure a session policy in Microsoft Defender for Cloud Apps

Why it fails: A Defender for Cloud Apps session policy enforces real-time controls, such as blocking downloads or requiring multi-factor authentication, on active user sessions in SaaS apps via reverse proxy. It does not scan Entra ID audit logs or react to account provisioning events. Because user creation occurs during the identity lifecycle rather than within an application session, a session policy can neither detect nor disable a newly created account.

Configure an access review in Privileged Identity Management

Why it fails: An access review in Privileged Identity Management recertifies existing role assignments or eligibility for Microsoft Entra ID and Azure resource roles on a periodic schedule. It is not an event-driven response mechanism and does not evaluate when a user account was provisioned. Therefore, it cannot trigger a playbook to disable a user immediately after an anomalous creation event outside business hours.

Configure a risk detection policy in Microsoft Entra ID Identity Protection

Why it fails: Entra ID Identity Protection evaluates risk on existing users and sign-ins, using machine learning to flag risky users, tokens, and service principal operations; it does not subscribe to user provisioning events like directory object creation. Its risk policies typically require MFA or password change on a user's next sign-in, not disable an account. Consequently, a risk detection policy would miss a newly created user unless the same user later exhibits risky sign-in behavior.

Require guest users to register for MFA before accessing any applications.

Why it fails: Requiring guest users to register for MFA adds an authentication step but does not restrict application access. MFA is a Conditional Access grant control or tenant-wide authentication requirement, not an authorization mechanism that scopes which applications a guest may open. A guest who completes MFA can still access any application for which they have been assigned or that permits external users.

Configure cross-tenant access settings to block all applications except those assigned.

Why it fails: Cross-tenant access settings in Microsoft Entra ID manage inbound and outbound B2B collaboration trust at the tenant or organization level, not per application. They can control whether guest users can be invited, and can enforce or suppress MFA, device compliance, or user restrictions from a partner tenant, but they cannot list specific applications to allow or block. Application-level access decisions require app assignment, Conditional Access, or Entra entitlement management.

Configure SharePoint external sharing settings to limit application access.

Why it fails: SharePoint external sharing settings govern who can be invited to share SharePoint sites, files, and folders, and what level of sharing is permitted (such as view, edit, or anonymous links). They do not apply to enterprise applications like SAP, Salesforce, or custom LOB apps, and they do not replace Conditional Access for restricting guest access across many apps. These settings are resource-scoped, not identity- or app-scoped.