4 of the 11 questions we have for this objective, shown with the answer and the reasoning.
Secure access to resources by using Microsoft Entra ID
Orinda Media uses Microsoft Entra ID P1 licenses. The security team wants every user who signs in to the Azure portal, Azure CLI, Azure PowerShell, or Azure Resource Manager REST API to complete multifactor authentication. Sign-ins to Microsoft 365 applications must not be affected by this change.
What should you create?
- AA Conditional Access policy that targets all users, selects the Windows Azure Service Management API as the target resource, and grants access only with multifactor authentication.The Windows Azure Service Management API target resource covers the Azure portal, CLI, PowerShell, and ARM REST calls, so the MFA grant applies exactly to Azure management and nothing else.
- BEnable security defaults for the tenant.Security defaults require MFA broadly across all applications and cannot be combined with Conditional Access policies, so they would affect Microsoft 365 sign-ins as well.
- CEnable per-user multifactor authentication for all users in the legacy MFA portal.Per-user MFA is a legacy setting that prompts for every application, which violates the requirement to leave Microsoft 365 sign-ins unchanged.
- DA Conditional Access policy that targets all users, selects Office 365 as the target resource, and grants access only with multifactor authentication.Targeting Office 365 enforces MFA on exactly the applications the scenario says must not be affected and leaves Azure management uncovered.
Why: Conditional Access scopes a control to a specific set of users and target resources, which is what lets you enforce MFA for Azure management without touching other applications. The deciding constraint is that only Azure management must be affected, and the Windows Azure Service Management API resource represents the Azure control plane across the portal, CLI, PowerShell, and REST. Security defaults and per-user MFA are blunt tenant-wide instruments, and targeting Office 365 is the inverse of what was asked.
Secure access to resources by using Microsoft Entra ID
Lindqvist Analytics added a SAML-based enterprise application named Payroll Portal to its Microsoft Entra tenant. Currently every user in the tenant can sign in to Payroll Portal. Only members of the security group SG-Payroll should be able to sign in. The identity team wants to enforce this in Microsoft Entra ID with minimal administrative effort.
What should you configure?
- AOn the Payroll Portal enterprise application, set the Assignment required property to Yes and assign SG-Payroll to the application.When assignment is required, Microsoft Entra ID issues tokens only to users or groups assigned to the enterprise application, so one group assignment enforces the restriction.
- BOn the Payroll Portal app registration, set Supported account types to accounts in this organizational directory only.Single-tenant scope limits sign-in to this tenant, which is already the case; it does not restrict which users within the tenant can sign in.
- COn the Payroll Portal enterprise application, set the Visible to users property to No.Hiding the application removes its tile from My Apps but does not prevent a user who knows the URL from signing in.
- DIn the consent and permissions settings, require administrator consent for Payroll Portal.Consent settings govern OAuth permission grants for applications that request delegated or application permissions; a SAML application sign-in is not controlled by consent.
Why: The enterprise application object (the service principal) is where you control which identities in your tenant can use an application, and the Assignment required setting is the switch that turns on that enforcement. The deciding constraints are that only SG-Payroll may sign in and that effort must be minimal, which a single group assignment satisfies. Supported account types and visibility are real settings that sound related but govern tenant scope and discoverability, not authorization, and consent controls apply to OAuth permission grants rather than SAML sign-in.
Secure access to resources by using Microsoft Entra ID
Belmont Freight uses Microsoft Entra Privileged Identity Management for Azure resource roles. Finance administrators are eligible for the Owner role on a subscription named Sub-Finance. Most users sign in with Microsoft Authenticator push notifications. A new requirement states that activating Owner on Sub-Finance must require phishing-resistant authentication with a passkey (FIDO2), even if the user already satisfied MFA with a push notification earlier in the session. Activations of other roles and normal portal sign-ins must not change.
What should you do?
- ACreate an authentication context, create a Conditional Access policy that targets that authentication context and grants access only with the Phishing-resistant MFA authentication strength, and in the PIM role settings for Owner on Sub-Finance select the option to require that authentication context on activation.Authentication contexts let a Conditional Access policy be triggered by a specific action such as a PIM activation, and the authentication strength grant forces a fresh phishing-resistant credential regardless of earlier MFA.
- BIn the PIM role settings for Owner on Sub-Finance, select the option to require multifactor authentication on activation.The PIM MFA option is satisfied by any existing MFA claim in the session, including an Authenticator push, so it cannot force a passkey.
- CCreate a Conditional Access policy that targets all users and the Windows Azure Service Management API and grants access only with the Phishing-resistant MFA authentication strength.This forces passkeys on every Azure portal and CLI sign-in for all users, which violates the requirement that normal portal sign-ins and other activations remain unchanged.
- DIn the Authentication methods policy, disable Microsoft Authenticator push notifications so that only passkeys remain available.Removing push notifications tenant-wide changes how every user signs in, which breaks the requirement to leave other sign-ins unaffected.
Why: The combination of Conditional Access authentication contexts and authentication strengths is how you demand a stronger credential for one sensitive action without raising the bar for everything else. PIM role settings can require an authentication context on activation, which triggers the matching Conditional Access policy at that moment. The deciding constraints are that only the Owner activation on Sub-Finance is affected and that a previously satisfied push MFA must not count. The PIM MFA checkbox is the trap because it honors any existing MFA claim, and the broad Conditional Access policy over-applies the control.
Secure access to resources by using Microsoft Entra ID
Pennywell Retail discovered that employees have granted consent to dozens of third-party OAuth applications, including one that requested Mail.ReadWrite. The security team wants users to be able to consent on their own only to low-impact permissions such as openid, profile, email, and User.Read, and only for applications from verified publishers. Any other permission request must be routed to a queue where identity administrators can approve or deny it, and users must not have to open a help desk ticket.
What should you configure?
- ASet user consent to allow consent for apps from verified publishers for selected permissions, classify the low-impact permissions as low-impact, and enable the admin consent workflow with the identity administrators as reviewers.The selected-permissions option combined with permission classification limits self-service consent to the approved low-impact set from verified publishers, and the admin consent workflow gives users an in-product request path that reviewers act on.
- BSet user consent to do not allow user consent, and tell users to request consent through the help desk.Disabling consent entirely blocks even the low-impact permissions the team wants to allow and relies on a ticket process the scenario rules out.
- CSet user consent to allow user consent for apps, and create a Conditional Access policy that blocks unapproved cloud apps.Allowing all consent leaves the Mail.ReadWrite problem in place, and Conditional Access controls sign-in to applications rather than which permissions are granted.
- DSet group owner consent to allow group owners to consent for all groups, and leave user consent unchanged.Group owner consent governs whether owners can grant applications access to group data; it does not restrict the permissions individual users can consent to.
Why: Microsoft Entra consent settings have three tiers, and the middle tier, consent from verified publishers for selected permissions, is the one that balances usability against risk by relying on the permission classification you define. The deciding constraints are that low-impact permissions must remain self-service, that higher-impact requests must reach administrators, and that users must not need a ticket, which is precisely what the admin consent workflow provides. Disabling consent entirely is the common over-correction, and Conditional Access and group owner consent are adjacent features that do not address permission grants.