Design identity, governance, and monitoring solutions practice questions

Microsoft Entra ID Privileged Identity Management and Access Reviews

Why wrong: Privileged Identity Management (PIM) provides just-in-time assignment and approval workflows for highly privileged roles, while Access Reviews periodically recertify those assignments to remove stale entitlements. These governance controls reduce standing privilege and audit the lifecycle of admin access, but they do not analyze sign-in risk or enforce conditional policies when a user authenticates, so they don't deliver risk-based zero-trust checkpointing.

Microsoft Entra ID B2B and External Identities

Why wrong: B2B (External Identities) allows you to invite guest users from other tenants or policy-enabled social identity providers and manage their collaboration-specific access via Entra ID tenant settings. External Identities configuration focuses on bringing external users into your directory for resource sharing, not on calculating the risk of a given authentication attempt, and it lacks the risk-detection telemetry needed to make real-time access decisions.

Microsoft Entra ID Domain Services and Managed Identities

Why wrong: Microsoft Entra ID Domain Services (formerly Azure AD DS) supplies legacy authentication protocols like NTLM and Kerberos, LDAP, and group policy for domain-joined VMs, whereas Managed Identities are Azure AD-backed service principals that grant applications a rotation-automated identity for accessing Azure resources. Neither component inspects or scores identity risk; they are infrastructure-level capabilities that support resource connectivity and authentication, not conditional access engines.

Azure Log Analytics workspace with Microsoft Entra ID diagnostic settings

Why wrong: While you can configure Microsoft Entra ID diagnostic settings for 'SignInLogs' and 'AuditLogs' in each tenant to stream into a single shared Log Analytics workspace, that workspace only provides a data store and a KQL query interface. It lacks Sentinel's integrated security analytics features: no built-in analytics rules, no UEBA, no automated incident management, and no native multi-tenant correlation. You would have to manually build and maintain every alert and investigation query, and there is no central overview of health or state across tenants beyond raw log aggregation—so it is not an adequate monitoring solution on its own.

Microsoft Entra ID Reports and Monitoring

Why wrong: Microsoft Entra ID Reports & Monitoring (the built-in sign-in logs, audit logs, and provisioning logs in the Entra admin center) show logging for exactly one tenant at a time; there is no native cross-tenant aggregation or comparison. These reports also rely on the diagnostics/activity blade that offers limited filtering, exports, and retention periods, with no custom detection rules, scheduled queries, or cross-data-source correlation. To monitor sign-ins across several tenants, you would have to navigate into each tenant separately and manually piece together trends, which is not a scalable or analysis-ready approach.

Azure Monitor Workbooks

Why wrong: Azure Monitor Workbooks are interactive reporting canvases that visualize data already stored in sources like a Log Analytics workspace, Azure Data Explorer, or Application Insights, but they do not ingest or collect data themselves. A workbook cannot directly connect to multiple Microsoft Entra ID tenants or pull sign-in logs on its own; it depends on an underlying repository where logs must first be aggregated. Even if you pointed a workbook at a shared workspace, you would still need Sentinel's ingestion, analytics, and alerting to make that data usable for multi-tenant sign-in monitoring—so workbooks are merely a visualization component, not a monitoring solution.

Microsoft Entra ID B2C.

Why wrong: Entra ID B2C was built specifically for customer-facing applications, allowing users to authenticate with local accounts or social identity providers like Facebook and Google. It is a separate external identity service that runs in a dedicated B2C tenant, not the corporate tenant, and cannot issue tokens or entitlements that grant access to internal Microsoft 365 resources such as SharePoint Online. Because the goal is to administer partner access to your own Office 365 content, B2C's customer-centric scopes and tenant architecture are entirely the wrong fit, and it offers no access request or approval policies.

Microsoft Entra ID Conditional Access.

Why wrong: Conditional Access is a policy engine that evaluates real-time signals—such as user location, device compliance, sign-in risk, and application—and then grants or blocks authentication requests by enforcing controls like Multi-Factor Authentication. It does not contain any concept of a user initiating an access request, nor can it set an expiry date after which assigned permissions are automatically revoked. Even if a partner passes every CA policy, their role or group membership persists indefinitely unless another system explicitly removes it, so CA cannot alone deliver time-bound access. It is best used as a security overlay to protect the access Entitlement Management grants.

Microsoft Entra ID Identity Protection.

Why wrong: Identity Protection is a risk-detection layer that uses machine learning to flag risky users and sign-in events, then automatically takes remedial actions such as blocking the sign-in, forcing MFA, or prompting for password change. It performs continuous monitoring of credential compromises, but it has no capability to handle an access request, trigger an approval workflow, or assign a SharePoint Online site to an external user. Since it only reacts to authentication risk, it is orthogonal to the need for governing external resource access and would not solve the access request and expiration requirement.

Azure Policy with built-in policy to enforce MFA and Azure Activity Log to monitor changes.

Why wrong: Azure Policy can audit whether MFA is enabled on accounts, but it cannot enforce MFA during sign-in. It is not the correct tool for requiring MFA at authentication time. Activity Log can capture policy changes, but the enforcement method is wrong.

Microsoft Entra ID Identity Protection to enforce MFA and Azure Sentinel for monitoring.

Why wrong: Microsoft Entra ID Identity Protection primarily enforces multi-factor authentication (MFA) based on detected sign-in or user risks, such as impossible travel or unfamiliar locations. It is not the direct mechanism for a blanket, unconditional MFA requirement for all administrators accessing the Azure portal, which is best achieved using Microsoft Entra ID Conditional Access policies. This option is tempting as Identity Protection *can* trigger MFA, and would be correct if the scenario demanded risk-based MFA enforcement. Azure Sentinel is suitable for monitoring policy changes.

Azure Policy to assign built-in policy 'MFA should be enabled on accounts with write permissions' and Azure Security Center for monitoring.

Why wrong: This policy audits whether MFA is enabled, but again does not enforce MFA during authentication. Azure Security Center (now Defender for Cloud) focuses on security posture and workload protection, not on monitoring identity policy changes.

Identity Protection and Conditional Access

Why wrong: Identity Protection detects risks like leaked credentials and risky sign-ins, while Conditional Access enforces policies such as MFA or blocking access based on that risk. Neither service has any capability to manage privileged role activation, approval workflows, or time-bound assignments. Conditional Access operates at the authentication and session layer, not at the authorization layer for Entra roles, so this combination cannot ensure controlled privileged role usage.

Entitlement Management and Conditional Access

Why wrong: Entitlement Management manages access packages for applications, groups, and SharePoint sites, enabling self-service requests and approvals for those resources, but it does not govern Microsoft Entra ID privileged roles. Conditional Access only enforces sign-in policies and does not perform access reviews or role activation. This pairing addresses resource access governance, not the privileged role lifecycle that the requirement explicitly targets.

Microsoft Entra ID Access Reviews and Identity Protection

Why wrong: Access Reviews alone can review and recertify existing role assignments, but without PIM, there is no mechanism for just-in-time activation or approval for elevating into privileged roles. Identity Protection focuses on identity risk from sign-in behavior, not on delegated privileged role administration or access recertification. Therefore this combination fails to provide the required controlled activation workflow, making it an incomplete solution.

B

Why wrong: Azure Service Health and Azure Advisor are not data-collection and analytics platforms. Service Health only reports on Azure service incidents, planned maintenance, and health advisories; Advisor provides personalized best-practice recommendations for workloads based on configuration, not live performance. Neither ingests VM performance counters, nor do they allow custom log queries, dashboard authoring, or alert rules based on CPU and memory metrics, so they cannot satisfy the customer's operational monitoring requirements.

C

Why wrong: Application Insights is part of Azure Monitor, but it is purpose-built for application-level telemetry—requests, dependencies, and exceptions—not for collecting guest-OS performance counters from VMs. Its SDK and auto-instrumentation monitor the behavior of applications, not the underlying server (CPU, memory, disk, or network). Even when used with virtual machines, it cannot replace Log Analytics for centralized OS performance collection and long-term retention of infrastructure metrics.

D

Why wrong: Azure Sentinel (now Microsoft Sentinel) is a cloud-native SIEM/SOAR solution focused on security information and event management. It ingests security logs like Azure Activity, Microsoft Entra ID, and firewall/IDS data, and is designed for threat detection, incident response, and hunting—not for general operational performance monitoring of server health. While it could technically store Windows event logs, it does not serve as the primary platform for custom performance dashboards and alerting based on CPU/memory counters, making it an incorrect choice for this scenario.

Microsoft Entra ID Identity Protection

Why wrong: Microsoft Entra ID Identity Protection is primarily a risk-detection engine that uses signals like impossible travel, credential leaks, and anonymous IP addresses to assign a risk level to each sign-in. While it can feed those risk levels into Conditional Access for risk-based MFA challenges, it has no native mechanism to enforce MFA based purely on a location condition such as a trusted IP range. Therefore, Identity Protection alone cannot implement the company's 'MFA everywhere except trusted IPs' requirement; it relies on Conditional Access to perform the actual enforcement.

Microsoft Entra ID Privileged Identity Management

Why wrong: Microsoft Entra ID Privileged Identity Management (PIM) provides just-in-time and time-bound activation of privileged roles, with features like approval workflows and Multi-Factor Authentication required during role activation. However, PIM only governs the elevation into administrative roles; it does not apply to standard user sign-ins or general MFA enforcement. Thus, using PIM would not ensure that all users are prompted to pass MFA when accessing the tenant normally, so it falls short of the stated policy.

Microsoft Entra ID Self-Service Password Reset

Why wrong: Microsoft Entra ID Self-Service Password Reset allows users to reset a forgotten password by completing a verification process, typically using a pre-registered phone number, email, or security questions. This flow is designed for account recovery after a sign-in failure and does not control the original authentication event, nor does it provide a location-based policy to require MFA across the organization. Consequently, SSPR cannot satisfy the requirement to enforce MFA on all user sign-ins from non-trusted locations.

Microsoft Entra ID Identity Protection

Why wrong: Identity Protection is a detection and reporting service that identifies risky sign-ins by analyzing signals like anonymous IP addresses, impossible travel, and leaked credentials, assigning risk levels. However, it does not natively enforce controls; instead, it exposes those risk scores to Conditional Access as conditions. Without Conditional Access, Identity Protection merely alerts on risk but cannot automatically block or require MFA.

Microsoft Entra ID Privileged Identity Management

Why wrong: Privileged Identity Management (PIM) focuses on just-in-time administrative role activation, providing approval workflows and time-bound assignments for Azure AD roles and Azure resources. It does not analyze sign-in risk for ordinary end users, nor does it consider anonymous IP addresses as a risk factor for general sign-in policies. Therefore, it is unrelated to configuring policies for risky sign-ins from anonymous sources.

Microsoft Entra ID Audit Logs

Why wrong: Audit Logs in Microsoft Entra ID record sign-in events and directory changes for compliance and forensics, but they are purely a log sink without any policy engine. They cannot evaluate risk levels at runtime or trigger responses like blocking access or requiring MFA. To act on risk, you need a separate policy mechanism such as Conditional Access, which reads those signals and enforces controls.

Microsoft Entra ID Connect

Why wrong: Microsoft Entra ID Connect is designed for hybrid identity synchronization between on-premises Active Directory and Microsoft Entra ID, not for managing user accounts within SaaS applications. It replicates directory objects (users, groups, password hashes) to the cloud identity store, but it does not connect to or update accounts inside Software-as-a-Service applications. Therefore, it cannot automate account creation or deactivation in SaaS apps as required.

Microsoft Entra ID Application Proxy

Why wrong: Microsoft Entra ID Application Proxy provides secure remote access to on-premises web applications by publishing them through the Entra ID authentication layer, using an outbound connector and pre-authentication policies. Its scope is network access and session security, not identity lifecycle administration. It neither creates nor disables user accounts in any target application, making it entirely unsuitable for automating user provisioning.

Microsoft Entra ID Entitlement Management

Why wrong: Microsoft Entra ID Entitlement Management focuses on governing access by creating access packages, assignment policies, and periodic access reviews, but it assumes the underlying user accounts already exist in the target applications. It can grant or revoke a user's permission to an application, yet it does not provision, update, or deactivate the actual user account records in that application. Hence, it is a tool for authorization governance, not identity lifecycle automation.

Azure Blueprints with tag policy and Azure RBAC, and Azure Security Center for compliance

Why wrong: Azure Blueprints is not needed here because the tag requirement is a single policy or initiative assignment, not a full environment archetype with multiple artifacts such as ARM templates and role assignments; Blueprints is also deprecated in favor of Policy/Initiatives and Template Specs, so depending on it is poor architectural judgment. RBAC alone can permit the Finance team to add tags, but it cannot force anyone to add them or stop a developer from creating a resource missing the tag—actual enforcement requires an Azure Policy effect. Azure Security Center, now Microsoft Defender for Cloud, reports on security posture and workload security, not tag governance, so this stack would leave the enterprise without a tag compliance report.

Azure Policy for tag enforcement, Azure Management Groups for governance, and Azure Monitor for compliance reports

Why wrong: Management Groups provide an efficient policy assignment boundary and help organize a large subscription hierarchy, but they are only containers—they do not evaluate resources or produce compliance results; the actual evaluation and reporting must come from Azure Policy. Azure Monitor collects platform metrics, activity logs, and resource diagnostics and can alert on operational conditions, but it has no native view of policy compliance or tag presence. This pairing also omits Azure RBAC, so there is no defined mechanism restricting tag edits to the Finance team, meaning any contributor could change tags. A complete solution must combine policy assignment for enforcement, role-based access control for delegation, and the Azure Policy compliance dashboard for reporting.

Azure Policy for tag enforcement, Azure RBAC for tag modification, and Azure Security Center for compliance

Why wrong: The first two components are correct—Azure Policy should enforce the tag rule, and Azure RBAC should constrain tag modifications to Finance—so the flaw is the compliance-reporting service. Microsoft Defender for Cloud (formerly Azure Security Center) evaluates security configurations such as endpoint protection, encryption, firewall rules, and secure-score recommendations; it does not audit whether resources carry a required cost-center tag. Tag compliance is measured by Azure Policy's built-in compliance view, which shows percentage compliance and the per-resource evaluation state for the assignment. Because this option puts a security tool in place of Azure Policy's reporting function, it is incomplete and incorrect.

Use Microsoft Entra ID Identity Protection to detect risky activations and trigger a Logic App

Why wrong: Microsoft Entra ID Identity Protection analyzes user and sign-in risk—such as leaked credentials, anonymous IP addresses, or impossible travel—and does not consume PIM role-activation events as a first-class signal. A PIM activation that is approved out-of-hours is not a 'risky' sign-in, so Identity Protection would have nothing to flag. Moreover, triggering a Logic App from Identity Protection would require a risk detection to emit a signal, but there is no built-in risk detection type for role activation timing; unsupported workarounds would merely poll audit logs, duplicating what Log Analytics does natively.

Enable Microsoft Entra ID diagnostic settings to send logs to Event Hubs and process with Azure Stream Analytics

Why wrong: This option fails because Azure Stream Analytics is designed for real-time data processing and analytics, not for directly triggering email alerts based on specific log events and time conditions. While it can process logs from Event Hubs, it lacks the native alerting capabilities required to send an email to the security team upon out-of-hours role activation. This solution is tempting as it offers real-time log ingestion and processing. It would be appropriate if the goal was complex real-time data transformation, aggregation, or enrichment of Microsoft Entra ID logs before storage or further custom analysis, rather than immediate, condition-based alerting.

Use Azure Sentinel with a built-in connector for PIM and create a scheduled analytics rule

Why wrong: Using Azure Sentinel with a scheduled analytics rule fails to provide the immediate, real-time email notification required "whenever" a PIM activation occurs outside business hours, due to the inherent latency of scheduled queries. While Sentinel is excellent for collecting Microsoft Entra ID PIM logs for quarterly audits and correlating security events across an estate, its strength lies in broader threat detection and long-term analysis, not instant, event-driven alerts for specific triggers.

Microsoft Entra ID Privileged Identity Management (PIM)

Why wrong: Privileged Identity Management (PIM) is incorrect because it is scoped exclusively to Azure AD roles, Azure resource roles, and other privileged roles like Global Administrator; it enables time-bound, just-in-time activation of these administrative roles. It does not handle requests for access to standard business applications or Microsoft 365 groups, nor does it provide access packages with approval and review cycles for regular employees. Therefore, it cannot automate the two-step governance process described in the question.

Microsoft Entra ID Conditional Access

Why wrong: Conditional Access is a policy engine that evaluates real-time signals such as user location, device compliance, and risk level to allow or block access to applications; it does not provide any mechanism for users to request access or for approvers to review requests. It operates after a user already has an account and attempts to sign in, enforcing session-level controls rather than managing access lifecycle. Thus, it is irrelevant for automating approvals and recurring access reviews.

Microsoft Entra ID Self-Service Group Management

Why wrong: Self-Service Group Management enables users to create their own Microsoft 365 groups, security groups, or distribution lists and manage membership themselves, but it lacks the governance features needed here: no built-in approval workflow for membership requests, no expiration policies, and no recurring access review scheduling. When enabled, it simply lets a group owner approve or deny requests without any time limits or periodic attestation. Consequently, it cannot automate the two-step access request and review process required by the company.

Microsoft Entra ID Audit logs

Why wrong: Microsoft Entra ID Audit logs record every configuration change and administrative action inside the tenant, such as adding a user, modifying a group, updating a conditional access policy, or resetting a password. They are often described as "who did what" and do not capture the outcome of an authentication attempt, so a sign-in failure would never appear here. Sign-in events belong exclusively to the Sign-in logs; audit logs only show the resulting tenant changes made after a successful admin operation.

Microsoft Entra ID Provisioning logs

Why wrong: Microsoft Entra ID Provisioning logs monitor the background synchronization lifecycle of identities into third-party SaaS applications such as ServiceNow, Salesforce, or AWS. These records capture operations like creating, updating, deactivating, and deleting user accounts in those external systems, and they are completely independent of any interactive authentication attempt. A sign-in failure would not generate a provisioning log entry because provisioning doesn't happen at the moment of sign-in; instead, it runs on a schedule or when identity changes are detected.

Office 365 Activity logs

Why wrong: Office 365 Activity logs, also known as the unified audit log, aggregate actions performed in Microsoft 365 workloads, such as an Exchange Online mailbox operation, a SharePoint file access, or a Teams message event, and are scoped to the M365 service plane. They do not capture the authentication transaction that occurs at the Microsoft Entra ID directory boundary before access is granted to an integrated application. Sign-in failures for an integrated app happen in the identity plane, so they are issued in the Sign-in logs, while Office 365 Activity logs would only reflect downstream activity if the user actually gained access.

Microsoft Entra ID

Why wrong: Microsoft Entra ID (formerly Azure AD) is a cloud-native identity and access management service that authenticates users via OAuth 2.0, OIDC, and SAML. It does not expose an LDAP interface or accept LDAP binds, and it does not support NTLM integrated authentication. Because the legacy Windows applications require these directory protocols, Entra ID alone cannot satisfy the authentication requirement.

Active Directory on Azure VMs

Why wrong: Deploying Active Directory on Azure VMs requires provisioning one or more Windows Server instances as domain controllers, using Azure availability sets or Availability Zones for high availability, and continuously applying security patches. This IaaS approach gives full control but demands significant ongoing operational overhead, including domain controller maintenance, backups, monitoring, and disaster recovery. Because AAD DS already provides a managed AD domain with no such administrative duties, the IaaS route is technically feasible but violates the stated preference for minimal management.

Microsoft Entra ID B2C

Why wrong: Microsoft Entra ID B2C is an externally facing customer identity and access management service specialized in sign-up, sign-in, and social identity providers such as Facebook and Google. It has no LDAP server endpoints and does not support the NTLM or Kerberos authentication flows used by legacy enterprise Windows applications. Using it here would require the applications to be rearchitected to OIDC, which is inappropriate for an LDAP-based lift-and-shift migration.

Identity Protection

Why wrong: Identity Protection is a risk-detection service that identifies potentially compromised accounts by analyzing anomalies like impossible travel and leaked credentials. It produces risk signals (user risk and sign-in risk) that can be consumed by Conditional Access policies, but it does not itself contain a location condition or a direct MFA enforcement action. Therefore, while it can be integrated, it cannot alone enforce MFA based on IP location.

Privileged Identity Management (PIM)

Why wrong: Privileged Identity Management (PIM) is designed for managing and activating highly privileged Entra ID roles, providing just-in-time access with approval workflows and time-bound activation. It can require MFA when an admin activates a role, but it does not govern ordinary end-user sign-in or apply MFA based on the user's IP location. Thus it is not the right tool for location-based MFA enforcement across the company.

Microsoft Entra ID roles

Why wrong: Microsoft Entra ID roles, such as 'Global Administrator' or 'User Administrator,' define administrative permissions and scope of management through role-based access control (RBAC). These roles control what an admin can see or do in the tenant, not how users authenticate or what MFA requirements are applied during sign-in. Access policies for end-user MFA are configured in Conditional Access, not by assigning an Entra ID role.

Microsoft Entra ID Privileged Identity Management (PIM)

Why wrong: Microsoft Entra ID Privileged Identity Management (PIM) is designed for just-in-time activation and time-bound assignments of highly privileged administrative roles, such as Global Administrator or Application Administrator, for internal user identities. It does not provide capabilities for external users to request access to line-of-business applications, nor does it include policy-driven approval workflows for app access requests or automatic removal of assignments based on application-specific access package policies. The requirement here is about granting and governing external access to applications, which is outside PIM's scope.

Microsoft Entra ID Identity Protection

Why wrong: Microsoft Entra ID Identity Protection focuses on detecting potential vulnerabilities and risk events affecting identities, such as leaked credentials, impossible travel, or risky sign-in behavior, and automating conditional access responses to those risks. It does not provide an end-user-facing request mechanism, nor does it support catalogs of resources or scheduled expiration of access assignments for external users. Therefore, while it is important for security monitoring, it cannot fulfill the requirement for managing external access to applications with approval and lifecycle controls.

Microsoft Entra ID Access Reviews

Why wrong: Microsoft Entra ID Access Reviews are used to perform periodic recertification of existing access assignments by asking owners to confirm whether users still need their access, after which stale access can be removed. However, Access Reviews do not handle the initial request phase, meaning external users cannot submit a request, and they do not enforce automatic expiration based on a predefined time limit—access remains until a reviewer decides to remove it. In this scenario, you need a solution that both grants external access after approval and automatically expires it, which is not provided by Access Reviews alone.

Microsoft Entra ID Application Proxy

Why wrong: Microsoft Entra ID Application Proxy is an HTTP reverse proxy that publishes internal web applications to authenticated external users via the Entra ID application portal and pre-authentication policies. It does not manage user account lifecycle in SaaS applications; it only handles secure remote access to the published apps. Provisioning is a distinct operation that requires SCIM-based endpoints on the target application, which Application Proxy does not provide.

Microsoft Entra ID Connect

Why wrong: Microsoft Entra ID Connect is a hybrid identity synchronization engine that copies on-premises Active Directory objects and password hashes into Microsoft Entra ID, enabling the same corporate credentials for cloud services. Its purpose is to populate the Entra ID directory, not to push identities directly into third-party SaaS applications. Connect has no awareness of a SaaS app's SCIM provisioning endpoint and cannot write user accounts to external identity stores, so it is not the tool for automating user provisioning into SaaS apps.

Microsoft Entra ID B2B Collaboration

Why wrong: Microsoft Entra ID B2B Collaboration is a feature for granting external partners or guests access to your organization's own applications by creating guest user objects in Entra ID and allowing them to sign in with their own identity providers or Microsoft account. After authentication, those users are not automatically created as accounts in third-party SaaS applications, since access is still at the Entra ID authorization layer. Automating account creation for external users to SaaS apps would also require a provisioning service; B2B alone does not perform lifecycle provisioning.

Microsoft Entra ID External Identities

Why wrong: Incorrect. Microsoft Entra ID External Identities is not a single service but an umbrella category that encompasses both B2B collaboration and B2C scenarios. Specifying this option leaves the intended consumer identity mechanism undefined, and the administrative and developer APIs differ depending on whether you ultimately configure B2B or B2C. The requirement calls for a customer-facing app with consumer sign-up and social sign-in, so you must choose the specific B2C service rather than this broad label.

Microsoft Entra ID B2B collaboration

Why wrong: Incorrect. Microsoft Entra ID B2B collaboration is designed for external business partners, such as vendors or consultants, to access your organization's own applications like SharePoint or line-of-business tools. It relies on the partner's existing corporate credentials or a Microsoft account, Google, or one-time passcode for business guests, and it does not provide consumer self-service registration or customizable sign-in journeys. Because the scenario is a customer-facing web app, B2B collaboration would not give you the CIAM features needed to onboard and manage individual consumers.

Microsoft Entra ID Application Proxy

Why wrong: Incorrect. Microsoft Entra ID Application Proxy is a reverse proxy feature that securely publishes on-premises web applications for remote employees, enabling access via enterprise single sign-on without requiring an Azure-resident app. It operates primarily on authentication for existing internal users and does not manage external consumer identities at all. Therefore it is irrelevant to a customer-facing web application that needs to authenticate individual customers.

Identity Protection with user risk policy

Why wrong: Identity Protection's user risk policy evaluates the probability that a user's identity has been compromised, using signals like leaked credentials, suspicious sign-ins, and impossible travel. While it can block sign-in for high-risk users, it makes no assessment of the device's compliance state, enrollment status, or management. A user on a non-compliant or unmanaged device with a low-risk profile would still be allowed access, so this option cannot block all access based on device compliance.

Privileged Identity Management (PIM)

Why wrong: Privileged Identity Management (PIM) is designed for just-in-time, time-bound activation of privileged roles such as Global Administrator, and it requires approval or Multi-Factor Authentication for role activation. It does not evaluate the endpoint's compliance with device policies, nor does it gate ordinary user access to applications. Even if PIM is used, non-privileged users on non-compliant devices would still be able to sign in, so it cannot serve as a device-based access control mechanism.

Microsoft Entra ID Join process

Why wrong: Microsoft Entra ID Join is the process that creates a device identity in Microsoft Entra ID and establishes a trust relationship to enable SSO and access to cloud resources. However, merely joining a device does not enforce compliance or block access; it only registers the device and provides directory-level identification. Compliance enforcement occurs only when a Conditional Access policy references the device's compliance state (which Intune calculates) as a condition—otherwise, joined devices are treated no differently than unmanaged ones.

Per-user MFA (legacy)

Why wrong: Configuring per-user MFA from the Entra ID user properties sets a persistent state (Disabled, Enabled, or Enforced) on the user account that governs all authentication flows. When enabled or enforced, the user is challenged for MFA on every interactive sign-in across every cloud application integrated with Entra ID, including Office 365, Exchange Online, and all other SaaS apps. It cannot target just the Azure Portal, so it is an over-broad, legacy approach that fails the requirement to limit MFA to a single app.

Security defaults

Why wrong: Security defaults are pre-configured tenant-wide protections that apply MFA to all users for all cloud applications, block legacy authentication, and require AAD admins to use MFA. This setting is global and cannot be filtered by application, so enabling it would require MFA not only for the Azure Portal but also for every other app the company uses. The requirement asks for a specific app scope, and security defaults lack that granularity, making it incorrect.

Identity Protection

Why wrong: Identity Protection is a risk-detection and remediation service that surfaces sign-in risks, user risks, or vulnerabilities and can trigger policies, such as requiring MFA based on a risk level like high or medium. Those risk-based MFA prompts are conditional on detected anomalies, not a standing, unconditional requirement for a specific application. It cannot force MFA for every sign-in to the Azure Portal on its own; that granular control is a Conditional Access capability. Thus, Identity Protection is not a direct answer to the requirement.