Secure identity and access practice questions

Microsoft Authenticator app

Why wrong: The Microsoft Authenticator app provides strong authentication by generating a time-based code or supporting push notifications and passwordless phone sign-in. However, it is not a built-in, zero-footprint solution: the user must install the app on a mobile device, register it with their Entra ID account, and maintain an internet connection. Therefore it fails when the requirement is to avoid deploying additional software or hardware.

FIDO2 security keys

Why wrong: FIDO2 security keys are a phishing-resistant passwordless method that uses a physical key (USB, NFC, or Bluetooth) to sign in. This approach requires purchasing and distributing hardware keys to each user, configuring dynamic lockouts, and ensuring device compatibility, which is significantly more complex than a built-in software option. It is wrong when the objective is to avoid hardware deployment and minimize extra prerequisites.

Certificate-based authentication

Why wrong: Certificate-based authentication (CBA) requires an enterprise public key infrastructure to issue, enroll, renew, and revoke client certificates on managed devices. The authentication relies on the certificate being provisioned to the user's device, which demands MDM or GPO deployment and ongoing certificate lifecycle management. This makes it unsuitable if you want to avoid certificate infrastructure and device management overhead.

Configure conditional access policies to require device compliance

Why wrong: 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 wrong: 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 wrong: 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 wrong: Privileged Identity Management with approval workflow governs just-in-time activation of Azure AD 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 wrong: 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 wrong: 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.

Include 'All cloud apps' and set 'Block access'

Why wrong: Including 'All cloud apps' and setting 'Block access' would block all cloud apps, including Microsoft Entra ID Administration, which contradicts the requirement to exclude it.

Include 'Select apps' and choose all apps except admin

Why wrong: Selecting apps individually and choosing all except Microsoft Entra ID Administration is inefficient and error-prone; using 'All cloud apps' with an exclusion is the correct pattern.

Include 'All cloud apps' and exclude 'Office 365'

Why wrong: Excluding Office 365 does not exempt Microsoft Entra ID Administration; the required exclusion is Microsoft Entra ID Administration itself.

Use an Azure Automation runbook to disable users after 90 days

Why wrong: 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 wrong: 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 wrong: 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.

Azure AD B2B collaboration

Why wrong: Azure AD B2B collaboration focuses exclusively on inviting external guest users and enabling them to sign in to your tenant's resources. It handles identity federation and one-time invitation redemption, but it does not provide lifecycle management, approval workflows, or expiration policies for ongoing access. Thus, it is unsuitable when the requirement is full access governance rather than simply extending an invitation.

Privileged Identity Management (PIM)

Why wrong: Privileged Identity Management (PIM) is scoped to time-boxed activation of elevated roles such as Microsoft Entra admin roles or Azure resource roles, requiring justification and multi-factor authentication. It does not manage regular users' access to business applications or group memberships through self-service requests or access reviews. Therefore, it is the wrong tool for general entitlement management of non-privileged resources.

Conditional Access with session restrictions

Why wrong: Conditional Access with session restrictions enforces security signals like sign-in risk, device compliance, or location, and can impose session controls such as sign-in frequency or app-enforced restrictions. It operates at runtime to restrict an existing authenticated session, but it does not proactively provision or assign access to resources. Since the question requires an access governance solution, session controls cannot deliver the necessary approval and expiration lifecycle.

The user's browser cookies are disabled

Why wrong: SAML SSO relies on the browser to relay messages and maintain the authentication session via cookies after redirects, so disabled cookies can interrupt the sign-in flow. However, if the certificate or metadata is invalid, the application will not accept the SAML assertion regardless of cookie state. This is a client-side condition, not the primary cause of a certificate validation or configuration error.

The application is not registered in the app gallery

Why wrong: Being absent from the Microsoft Entra ID application gallery has no bearing on sign-in, because you can register an application as a custom or non-gallery enterprise app and manually configure SAML endpoints and certificates. The gallery simply provides pre-built templates to simplify configuration. The app could still be fully functional without being listed.

The user does not have a license for Microsoft Entra ID

Why wrong: Microsoft Entra ID Free tier supports SAML-based SSO for enterprise applications, so a user does not require a Premium license to sign in. The user merely needs an active directory account that is assigned to the application. If the user lacks any Entra ID license, they may not have an identity at all, but that is different from not holding a paid license; the free tier covers this scenario.

Windows Hello for Business

Why wrong: Windows Hello for Business requires the user to be on a Windows 10 or Windows 11 device that is Azure AD joined or hybrid Azure AD 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 wrong: 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 wrong: 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.

Azure AD Connect Health

Why wrong: Azure AD Connect Health is a telemetry and monitoring service for hybrid identity components like Azure AD 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.

Azure AD Domain Services

Why wrong: Azure AD DS 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 wrong: Seamless SSO silently uses the user's on-premises Kerberos ticket when accessing Azure AD, 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.

Force password change on next sign-in

Why wrong: This is not a valid Conditional Access configuration because force password change at next sign-in is a per-user property, not an assignment condition or access control. It can be set through PowerShell or the Microsoft Entra admin center, but it does not appear anywhere in a policy's users, conditions, or grant blocks.

Block access for users without MFA registered

Why wrong: This is not a valid condition because MFA registration status is not one of the signals Conditional Access can evaluate. Requiring MFA is a grant control, and the policy cannot use registered-or-not as an if-then condition like sign-in risk or location. Even the default MFA experience can prompt a user to register during authentication, so blocking purely on existing registration requires a separate entitlement check.

Assign licenses to users based on location

Why wrong: Assigning licenses is an administrative operation, not a sign-in policy decision. Conditional Access policies control access by evaluating signals and granting or blocking sign-ins; they never assign or revoke licenses. Group-based licensing can be based on group membership or attributes, but location is not a valid license-assignment criterion.

Enforce device compliance via Intune

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

Manage FIDO2 security keys

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

Configure risk-based conditional access policies

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

Security questions

Why wrong: Security questions are not an authentication method for regular sign-in; they are strictly used as a verification mechanism during self-service password reset (SSPR). Asking users to answer pre-configured questions provides only low-assurance identity checks, so Microsoft Entra ID restricts them to password reset scenarios. They can never serve as a first-factor or second-factor authentication method in an interactive login flow.

Smart card with PIN

Why wrong: Smart card with PIN requires a physical card holding a certificate plus a PIN to unlock it, but Microsoft Entra ID does not natively support this interaction for cloud resources without a federated identity provider. The certificate itself may be used via federation, the PIN entry is handled by the on-premises infrastructure rather than by Entra ID. This differs from native CBA, where certificates are presented directly to Entra ID and PIN is not required.

OAuth 2.0 authorization code flow

Why wrong: OAuth 2.0 authorization code flow is an authorization protocol that obtains an access token for delegated resource access, not a user authentication method. It relies on an underlying authentication mechanism, such as a password or certificate, to establish the user's identity before tokens are issued. Equating OAuth flows with authentication methods is incorrect because they solve different problems: token exchange versus identity proofing.

The policy excludes some Office 365 apps

Why wrong: The policy could exclude some Office 365 apps, but that would only allow access to those specific apps without MFA, not all Office 365 apps. The question states users can access Office 365 without MFA, implying the policy is not enforced at all, which is more likely due to empty grantControls.

The 'authenticationStrength' property is not a valid Conditional Access policy property

Why wrong: The 'authenticationStrength' property is a valid property in Conditional Access policy JSON. It can be used to specify authentication strength requirements, but it is not the reason the policy fails.

The policy does not include all users

Why wrong: If the policy does not include all users, some users would be exempt, but the question implies users in general (likely all users) are able to access without MFA, suggesting the policy is not applying to anyone, which points to empty grantControls.

All Users

Why wrong: Static group, not dynamic.

Sales Team

Why wrong: Dynamic group for sales.

Administrators

Why wrong: Dynamic group for administrators, not finance.

Add a connected organization for external users

Why wrong: Connecting an organization to Azure AD entitlement management establishes a trust relationship that makes it easier for external B2B users to request access to your resources, but it does not introduce recurring review workflows. It merely governs how external identities can be added to a connected tenant; no periodic attestation or reviewer assignment is configured. The quarterly review requirement remains unmet.

Set 'isApprovalRequiredForAdd' to true

Why wrong: Setting 'isApprovalRequiredForAdd' to true only demands that a user's access request be approved by designated approvers before they receive the entitlement. This is a one-time approval event that occurs when access is initially granted, not a recurring review. The quarterly review would still be absent, so the requirement is not satisfied.

Set 'durationInDays' to 90

Why wrong: Setting 'durationInDays' to 90 automatically revokes an entitlement after 90 days without any human review, which means an employee could continue to have access for three months regardless of whether it is still appropriate. This is an expiration policy, not a review policy: it forces users to re-request access rather than having a finance manager attest to the continuing need. The organization will not get the required quarterly review.

Grant access, require approved client app

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 Policy

Why wrong: Azure Policy is a governance and compliance tool that enforces rules on Azure resources, such as requiring specific tags or restricting resource locations, but it does not offer just-in-time VM access functionality. While you can use Azure Policy to audit whether JIT is enabled or to mandate Defender for Cloud configurations, the actual JIT capability is implemented by Defender for Cloud, not by Policy itself.

Azure Firewall

Why wrong: Azure Firewall is a managed, cloud-based network security service that applies filtering and threat intelligence at the network layer across perimeters, but it does not provide just-in-time VM access. JIT VM access relies on dynamically managing network security groups around individual VMs, which is performed by Defender for Cloud, not by a centralized firewall appliance.

Microsoft Entra Privileged Identity Management

Why wrong: Microsoft Entra Privileged Identity Management (PIM) is an identity governance feature that manages, restricts, and monitors privileged user roles like Global Administrator, not network-level access to virtual machines. JIT VM access is about opening network ports temporarily, not identity privileges, so PIM has no role in enabling that capability for VMs in Sentinel's context.

Use a custom domain for the app

Why wrong: A custom domain only rebrands the app's URL and TLS certificate; it does not affect how Azure AD issues or validates tokens. Partner access is governed by the app's identity provider settings and tenant-level trust, not by the domain name users type in the browser. Thus, changing the domain neither grants nor restricts access for partner tenants.

Block all external users

Why wrong: Blocking all external users is a blanket denial that prevents any user from outside your tenant from signing in, including legitimate partner users. The requirement is to securely allow partner tenants, not to lock them out, so this approach fails the access requirement. You need a more granular mechanism that selectively trusts specific external identity providers.

Require multi-factor authentication for all users

Why wrong: Requiring MFA for all users adds a second authentication factor but does nothing to control which external tenants can access the app. Partner users would still be able to sign in if they satisfy the MFA policy, so it does not restrict access to only approved partners. MFA is a security control layered on top of identity-based access, not a substitute for configuring trust with partner tenants.

Enroll all devices in Intune

Why wrong: Enrolling all devices may not be feasible for personal devices.

Remove the conditional access policy

Why wrong: Removing the policy would eliminate security controls.

Use app protection policies instead

Why wrong: App protection policies do not enforce device compliance.