Free practice questions

SC-300 practice questions, with full explanations

75 free SC-300 (Microsoft Identity and Access Administrator) questions, each with the correct answer, a breakdown of why every other option is wrong, a memory hook, and the Microsoft Learn reference. Prefer to be quizzed? Take the interactive SC-300 quiz, which scores you by topic and points you to the guide that fits your weak spots.

Entra ID Fundamentals (15 questions)

Go deeper on this topic in Microsoft Entra ID Fundamentals Field Guide.

An administrator wants to create a group they can assign the Helpdesk Administrator role to, and they want the group's membership to populate automatically using a dynamic rule based on job title. In the group creation blade, when they set "Microsoft Entra roles can be assigned to the group" to Yes, the dynamic membership option becomes unavailable. Why can these two settings not be combined?

Correct answer: A. Role-assignable groups must use Assigned membership; dynamic membership is blocked by design so that editing an attribute cannot silently add someone to a privileged role.

Only groups created with the isAssignableToRole property set to true can be assigned Microsoft Entra roles, and that property is immutable. A core restriction of role-assignable groups is that their membership type must be Assigned and cannot be dynamic. Microsoft designed it this way to prevent elevation of privilege: if dynamic membership were allowed, anyone who could modify the attributes referenced in the rule could add an account to the group and thereby grant it the assigned role. Creating a role-assignable group also requires at least the Privileged Role Administrator role.

Why the other options are wrong:

  • B. The blocker is not a P2 requirement. Dynamic membership needs P1, and role-assignable groups are available with P1 or P2. The conflict is a design restriction, not a licensing gap.
  • C. Helpdesk Administrator can be assigned to a role-assignable group; assigning roles to groups is a supported and recommended pattern. The restriction is only that such a group must be Assigned, not dynamic.
  • D. Both security and Microsoft 365 groups can be made role-assignable. The membership type, not the group type, is what must be Assigned.

Memory hook: Role-assignable means Assigned-only. Dynamic plus a role would turn an attribute edit into a privilege backdoor, so it is forbidden.

Microsoft Learn: https://learn.microsoft.com/entra/identity/role-based-access-control/groups-concept

An administrator uses group-based licensing to assign Microsoft 365 E5 to a parent security group named All-Staff. All-Staff contains a nested child group, Contractors, whose members belong only through that child group. After processing, direct members of All-Staff receive licenses but the contractors do not. Separately, several users who had no Usage location set still received their licenses. Which statement correctly explains both behaviors?

Correct answer: C. Group-based licensing does not support nested groups, so only first-level (direct) members of the licensed group are assigned licenses; and under group-based licensing, users without a Usage location inherit the tenant's location

Group-based licensing does not support nested groups. If you assign licenses to a group that contains other groups, only the first-level (direct) user members are licensed; members who belong only through a nested child group are not. Separately, although a direct per-user license assignment fails without a Usage location, under group-based licensing any user without a location inherits the tenant's location, so licensing still succeeds for those users.

Why the other options are wrong:

  • A. Licensing does not cascade to nested members under any condition. The contractors were skipped because they are nested-only members, not because of a license shortage.
  • B. There is no delayed cascade to nested members; nested-only members are simply not licensed at all. Usage location is also relevant, since users inherit the tenant location under group-based licensing.
  • D. Group type does not enable a nested cascade; nested groups are unsupported for licensing regardless of whether the parent is a security or Microsoft 365 group. And for group-based licensing the location is inherited from the tenant, not required to be set manually.

Memory hook: Group-based licensing is flat: only direct members get licensed, never nested. No Usage location? Group-based licensing borrows the tenant's location.

Microsoft Learn: https://learn.microsoft.com/entra/fundamentals/concept-group-based-licensing

An organization currently has only Microsoft Entra ID Free. The security team wants to create a custom role that grants a narrow set of permissions (for example, managing app registration credentials) and assign it to three engineers. What licensing applies to this plan?

Correct answer: C. Microsoft Entra ID P1 is required for each user assigned a custom role; built-in roles remain free.

Using built-in Microsoft Entra roles is free, but custom roles require a Microsoft Entra ID P1 license for every user who holds a custom role assignment. Microsoft Learn's licensing page states this directly, and the custom-role creation prerequisites list a P1 or P2 license plus the Privileged Role Administrator role. So the three engineers assigned the custom role each need P1 coverage; the organization cannot do this on Free alone.

Why the other options are wrong:

  • A. Only built-in roles are free. The moment you assign a custom role, each assignee requires a P1 license, so this plan is not free.
  • B. The Governance add-on is not required for custom RBAC roles. A P1 license (already the minimum tier above Free) plus Privileged Role Administrator is sufficient.
  • D. Custom roles require P1, not P2. P2 adds Identity Protection and PIM, but it is not what gates the creation or assignment of a custom directory role.

Memory hook: Built-in roles are free. Custom roles cost P1 for every assignee.

Microsoft Learn: https://learn.microsoft.com/entra/fundamentals/licensing

A company must guarantee that Helpdesk Administrators and even tenant-level Global Administrators cannot reset the passwords of C-level executive accounts or read their BitLocker keys, without stripping those admins of their tenant-wide roles. Only a small, explicitly designated set of administrators should be able to manage the executive accounts. Which Microsoft Entra capability meets this requirement?

Correct answer: B. A restricted management administrative unit containing the executive accounts, with a role scoped to that unit assigned only to the designated administrators

A restricted management administrative unit protects specific objects so that only administrators explicitly assigned a role at the scope of that unit can modify them. Even tenant-level Global Administrators and Privileged Role Administrators are blocked from modifying the objects unless they scope themselves to the unit, which is an auditable event. Placing the executive accounts in a restricted management administrative unit and assigning the trusted administrators a role (for example, Authentication Administrator) at that scope meets the requirement without removing anyone's tenant-wide roles.

Why the other options are wrong:

  • A. Conditional Access governs sign-in access conditions, not which administrators may perform a password reset on an object. It cannot enforce this admin-scoping requirement.
  • C. A regular (non-restricted) administrative unit narrows a scoped admin's reach, but it does not block tenant-level administrators. A Global Administrator, or a Helpdesk Administrator with tenant scope, could still reset the executives' passwords. Only a restricted management administrative unit blocks tenant-level admins.
  • D. Privileged Role Administrator manages role assignments tenant-wide and does not restrict who can manage the executives' accounts. Assigning it to executives is both incorrect for the goal and a privilege-escalation risk.

Memory hook: Block even Global Admins from touching sensitive accounts, without removing their roles = Restricted Management AU. A regular AU does not stop tenant-level admins.

Microsoft Learn: https://learn.microsoft.com/entra/identity/role-based-access-control/admin-units-restricted-management

An administrator reviews the Identity Secure Score in Microsoft Entra ID and finds the recommendation 'Require MFA for administrative roles' shows a low score. The administrator implements MFA for all administrator accounts. How frequently does the Identity Secure Score recalculate, and where does the score appear relative to the overall Microsoft Secure Score?

Correct answer: C. The score recalculates every 24 hours and represents the identity category of the Microsoft Secure Score

The Identity Secure Score evaluates your security configuration every 24 hours and computes a new score based on how closely your settings align with Microsoft's recommendations. The score is available in the Microsoft Entra admin center under Identity Secure Score and also under Recommendations. It directly corresponds to the identity category within the Microsoft Secure Score, which has five categories: Identity, Data, Devices, Infrastructure, and Apps. Improvements to the Identity Secure Score improve the identity component of the overall Microsoft Secure Score.

Why the other options are wrong:

  • A. The Identity Secure Score recalculates every 24 hours, not weekly. While the Microsoft Defender XDR portal shows the full Microsoft Secure Score and its history, the Identity Secure Score is primarily accessible in the Microsoft Entra admin center.
  • B. The Identity Secure Score does not recalculate every 30 minutes. The documented recalculation interval is every 24 hours. It is not separate from the Microsoft Secure Score - it is the identity portion of that score.
  • D. The score does not recalculate in real time. Changes to security configuration take up to 24 hours to reflect in the score. It does not replace the Microsoft Secure Score; it feeds into the identity category of it.

Memory hook: Identity Secure Score = daily report card for identity security. It feeds the identity column of the Microsoft Secure Score table.

Microsoft Learn: https://learn.microsoft.com/en-us/entra/identity/monitoring-health/concept-identity-secure-score

A licensing operations team must be able to assign and remove Microsoft 365 licenses for users, but they should not be able to create or delete users, reset passwords, or purchase subscriptions. Following least privilege, which Microsoft Entra role should you assign?

Correct answer: D. License Administrator

License Administrator is the least-privileged role for assigning and removing user and group licenses. Microsoft Learn's least-privileged-roles-by-task reference lists License Administrator as the minimum role for both "Assign license" and "Revoke license." It grants the ability to manage license assignments (and read license configuration) without the broader user-management or purchasing powers that other roles carry, which fits the requirement exactly.

Why the other options are wrong:

  • A. User Administrator can assign licenses, but it can also create and delete users and reset passwords for non-admins, which exceeds what this team needs. It is listed only as an additional (higher-privilege) role for the licensing task, not the least-privileged one.
  • B. Billing Administrator manages purchases and subscriptions (try or buy a subscription) but is not the role used to assign or remove per-user license seats.
  • C. Global Administrator has full control of the entire tenant, far more than required, and violates least privilege for a licensing-only function.

Memory hook: Just licenses and nothing else = License Administrator. User Admin is a bigger hammer than the task needs.

Microsoft Learn: https://learn.microsoft.com/entra/identity/role-based-access-control/delegate-by-task

To reduce casual directory browsing, an administrator sets 'Restrict access to the Microsoft Entra admin center' to Yes for non-admin users. A security reviewer asks whether this reliably prevents those users from reading directory data. What is the correct understanding of this setting?

Correct answer: C. No, it only adds friction by hiding common admin center pages; Microsoft states it is not a security measure and it does not block programmatic access to directory data via Microsoft Graph, PowerShell, or other tools

'Restrict access to the Microsoft Entra admin center' only limits access to a set of commonly visited admin center pages for non-admin users. Microsoft is explicit that this is not a security measure: it does not block programmatic access to Microsoft Entra data via PowerShell, the Microsoft Graph API, or other tools, and many pages remain reachable through direct links. For real enforcement, Microsoft recommends a Conditional Access policy targeting the Windows Azure Service Management API.

Why the other options are wrong:

  • A. It has no P2 dependency and is not guest-specific. It is a member-user default that governs admin center portal access only.
  • B. It is not a security boundary. Microsoft states directly that the setting is not a security measure and that it does not protect directory data; it only adds friction to portal browsing.
  • D. The setting does not touch tokens or Graph access at all. It only limits which admin center pages non-admins can load in the portal UI.

Memory hook: Restricting the admin center hides the portal, not the data. Graph and PowerShell still read the directory. Microsoft says it is not a security control.

Microsoft Learn: https://learn.microsoft.com/entra/fundamentals/users-default-permissions

During a reorganization, an administrator changes an Azure subscription's associated Microsoft Entra directory (tenant) from Tenant A to Tenant B. Which statement best describes the result of this change?

Correct answer: D. Azure RBAC role assignments on the subscription are lost, because a subscription can trust only one tenant at a time; the user accounts themselves are not moved.

Every Azure subscription has a trust relationship with exactly one Microsoft Entra tenant at a time (though one tenant can be trusted by many subscriptions). Changing the subscription's directory changes which tenant supplies identities for Azure RBAC. Microsoft Learn warns that when a subscription is associated with a different directory, users who had access through Azure role assignments lose that access, and classic administrators lose access too. It does not move user accounts between tenants; it only re-points which identity store Azure checks for that subscription.

Why the other options are wrong:

  • A. Role assignments do not follow the subscription. Because the trusted directory changed, existing Azure RBAC assignments that referenced principals in the old tenant are lost.
  • B. A subscription can trust only a single tenant at any given time. It cannot simultaneously trust two directories.
  • C. Directory objects such as user accounts do not move when you change a subscription's trusted tenant. Only the trust (which directory authorizes access) changes.

Memory hook: A subscription trusts exactly one tenant. Re-point it and the Azure RBAC assignments fall off. Identities do not move.

Microsoft Learn: https://learn.microsoft.com/entra/fundamentals/how-subscriptions-associated-directory

An organization set Guest invite settings to 'Only users assigned to specific admin roles can invite guest users.' A project lead who holds no administrator role now needs to invite external partners as B2B guests, but must not receive any broader directory privileges. Which role should you assign?

Correct answer: D. Guest Inviter

The Guest Inviter role gives an individual user the ability to invite B2B guests without assigning a higher-privilege administrator role. Users with the Guest Inviter role can invite guests even when 'Only users assigned to specific admin roles can invite guest users' is selected. It carries no other directory-management permissions, so it exactly meets the least-privilege requirement.

Why the other options are wrong:

  • A. Global Administrator is the most privileged role in the tenant. Assigning it merely to invite guests grossly over-provisions the project lead.
  • B. External Identity Provider Administrator manages the configuration of external identity providers and federation (such as SAML/social IdPs). It is not the role for granting a single user the ability to send guest invitations.
  • C. User Administrator can invite guests, but it also creates and manages users and resets non-admin passwords. That is far more than the ability to invite guests, so it violates least privilege.

Memory hook: Invite guests and nothing else = Guest Inviter. It works even when only specific admin roles may invite.

Microsoft Learn: https://learn.microsoft.com/entra/external-id/external-collaboration-settings-configure

A cloud engineer holds the Microsoft Entra User Administrator role. They can manage users and groups in the Entra admin center, but in the Azure portal they cannot start, stop, or resize the virtual machines in a resource group. What correctly explains this and the appropriate fix?

Correct answer: C. Microsoft Entra roles and Azure RBAC are separate systems: Entra roles govern directory resources, not Azure resources. To manage the VMs, assign an Azure RBAC role such as Virtual Machine Contributor at the appropriate scope (management group, subscription, resource group, or resource)

Microsoft Entra roles and Azure RBAC are independent authorization systems. Microsoft Entra roles control access to directory resources (users, groups, applications) through Microsoft Graph, while Azure RBAC controls access to Azure resources (VMs, storage) through Azure Resource Manager. Entra role permissions can't be used in Azure and vice versa. To let the engineer manage the VMs, assign an Azure RBAC role like Virtual Machine Contributor; Azure RBAC scope can be a management group, subscription, resource group, or individual resource.

Why the other options are wrong:

  • A. Azure RBAC scope can be set at multiple levels, including management group, subscription, resource group, and individual resource, not only the subscription.
  • B. Global Administrator is an Entra role and, by default, does not grant access to Azure resources because the two planes are separate. A Global Administrator can elevate to User Access Administrator at root scope, but that is a deliberate extra step, not automatic full control.
  • D. User Access Administrator is an Azure RBAC role, not a Microsoft Entra directory role, and it manages user access to Azure resources. It does not bridge the two systems as an Entra role, and it would not be the natural role for managing VM power state.

Memory hook: Entra roles = directory; Azure RBAC = Azure resources. To touch VMs, assign an Azure role (e.g., VM Contributor) at MG/sub/RG/resource scope.

Microsoft Learn: https://learn.microsoft.com/azure/role-based-access-control/rbac-and-directory-admin-roles

An administrator adds a security group to an administrative unit and assigns a User Administrator scoped to that unit. A support technician in that role needs to reset the password of a user who is a member of the group. The user object itself has NOT been added directly to the administrative unit. What is the result when the technician attempts the password reset?

Correct answer: A. The password reset fails because adding a group to an administrative unit does not add the group members to the unit

Adding a group to an administrative unit brings the group object itself into the management scope of the administrative unit, but it does not bring the group's members into scope. A User Administrator scoped to the administrative unit can manage the group's properties and membership, but cannot manage individual user properties or reset passwords for group members unless those users are also directly added as members of the administrative unit.

Why the other options are wrong:

  • B. Group membership does not imply administrative unit membership for users. The Microsoft Learn documentation explicitly states that individual users must be directly added as administrative unit members for scoped user management to apply.
  • C. Membership in other administrative units does not affect this outcome. The issue is that the user is not a member of this specific administrative unit, regardless of any other unit memberships.
  • D. Whether the group is dynamic or static does not change this behavior. Dynamic membership controls how users enter or exit the group, not whether they are scoped within the administrative unit.

Memory hook: A group in an AU is like parking a bus in a lot. You control the bus, not the passengers individually.

Microsoft Learn: https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/administrative-units

You enable group-based licensing on a security group named 'All-Staff.' 'All-Staff' contains several other groups as members (nested groups). Users who are direct members of 'All-Staff' receive licenses, but users who are only members of the nested child groups do not. Why?

Correct answer: D. Group-based licensing doesn't support nested groups; only first-level (direct) members of the licensed group are assigned licenses.

Group-based licensing doesn't currently support nested groups. If you assign licenses to a group that contains other groups, only users in the first-level (direct) group receive licenses; members of nested child groups are not licensed.

Why the other options are wrong:

  • A. Wrong: the child group's type doesn't matter. Nested membership isn't honored regardless.
  • B. Wrong: there's no weekly job that resolves nesting; nesting simply isn't supported.
  • C. Wrong: this isn't a licensing-edition issue; it's the nested-group limitation of group-based licensing.

Memory hook: Group licensing is flat: only direct members get licensed; nested groups are ignored.

Microsoft Learn: https://learn.microsoft.com/microsoft-365/admin/manage/manage-group-licenses

A collaboration lead wants end users to create and own their own security groups from the My Groups portal, and to let group owners approve or deny join requests, without granting users any admin role. In Microsoft Entra group settings, which change is needed, and what license is required for the request-to-join and approval behavior?

Correct answer: B. Set 'Users can create security groups' to Yes; a Microsoft Entra ID P1 or P2 license is required for users to request to join a group and for owners to approve or deny those requests

Setting the tenant option 'Users can create security groups' to Yes lets non-admin users create and own security groups (including from the My Groups portal). However, a Microsoft Entra ID P1 or P2 license is required for users to request to join a security or Microsoft 365 group and for owners to approve or deny those membership requests. Without P1/P2, users can still manage groups they own but cannot use the join-request/approval flow.

Why the other options are wrong:

  • A. Groups Administrator is a privileged directory role. The correct approach for self-service is the tenant group setting, not handing every user an administrative role.
  • C. Self-service group management is available only for security groups and Microsoft 365 groups. It is not available for mail-enabled security groups or distribution lists, so the premise is reversed.
  • D. The request-to-join and owner approve/deny flow specifically requires a P1 or P2 license. It is not part of Microsoft Entra ID Free.

Memory hook: 'Users can create security groups = Yes' enables self-service; the join-request + owner-approval flow needs P1/P2.

Microsoft Learn: https://learn.microsoft.com/entra/identity/users/groups-self-service-management

To pre-stage onboarding, you want a dynamic membership group that automatically contains users whose employment start date falls within the next 7 days, so licenses and access provision before Day 1. Which membership rule works?

Correct answer: D. (user.employeeHireDate -ge system.now) -and (user.employeeHireDate -le system.now -plus p7d)

employeeHireDate is the date/time property that supports comparison against the system.now keyword using -ge/-le together with the -plus <duration> operator, where the duration is ISO 8601 (for example p7d = 7 days). Bounding the value between system.now and system.now -plus p7d, and joining the two expressions with the hyphenated -and logical operator, selects users whose hire date falls within the next seven days.

Why the other options are wrong:

  • A. user.startDate is not a supported property and system.add(7) is not a valid function or syntax in dynamic membership rules.
  • B. now() and arithmetic such as '-7' are not valid dynamic-rule syntax; the keyword is system.now used with the -plus <ISO 8601 duration> operator.
  • C. createdDateTime is the object-creation timestamp, not the hire date, and it can't hold a future value, so this never selects upcoming hires.

Memory hook: Future hires = employeeHireDate between system.now and system.now -plus p7d, joined with -and.

Microsoft Learn: https://learn.microsoft.com/entra/identity/users/groups-dynamic-membership#rule-syntax-for-a-single-expression

Fabrikam and Contoso configure a mutual B2B direct connect trust. A Contoso Teams shared channel owner adds a Fabrikam user to a shared channel. What is true about how that Fabrikam user is represented and managed in Contoso?

Correct answer: A. No user object is created in Contoso's directory; the external user is managed within Teams by the shared channel owner.

B2B direct connect users don't have a presence (no user object) in the resource organization's Entra directory. They access only the shared channel using their home-tenant credentials and are managed inside the Teams client by the shared channel owner. B2B collaboration guests, by contrast, do get a user object.

Why the other options are wrong:

  • B. Wrong: no member object is created and no Contoso license is consumed.
  • C. Wrong: no contact object is created either. There is no Contoso directory object at all.
  • D. Wrong: that describes B2B collaboration (which creates a guest object), not B2B direct connect.

Memory hook: Direct connect = no object in your directory (managed in Teams); guests get objects, direct-connect users don't.

Microsoft Learn: https://learn.microsoft.com/entra/external-id/b2b-direct-connect-overview

Authentication and Conditional Access (15 questions)

Go deeper on this topic in Authentication and Conditional Access Field Guide.

Your organization uses Conditional Access with a named location policy that blocks access from outside trusted IP ranges. A user working from a coffee shop loses access to Exchange Online immediately after moving locations, even though their access token has not expired. Which feature is responsible for this near-real-time enforcement?

Correct answer: C. Continuous access evaluation (CAE) Conditional Access policy evaluation

Continuous access evaluation enables resource providers such as Exchange Online to synchronize key Conditional Access policies and evaluate them in near real time. When a user moves outside a trusted IP range, the resource provider detects the location change and issues a 401 claim challenge, forcing the client to request a new token from Microsoft Entra. This results in immediate or near-immediate loss of access rather than waiting for the one-hour default token lifetime to expire. CAE-enabled sessions also use long-lived tokens of up to 28 hours, with security enforced through real-time event evaluation rather than short token lifetimes.

Why the other options are wrong:

  • A. Sign-in frequency controls how often users must reauthenticate, but it operates on the configured interval (e.g., one hour) and does not provide immediate enforcement when location conditions change.
  • B. Microsoft Entra Password Protection blocks weak passwords during password change events. It has no role in session revocation or location-based access enforcement.
  • D. ID Protection sign-in risk policy detects anomalous sign-in behaviors and can require MFA or block access. It does not enforce location-based Conditional Access policy changes in real time after a user's session is already established.

Memory hook: CAE = continuous security conversation between Entra and the app. No expired token needed to kick you out.

Microsoft Learn: https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-continuous-access-evaluation

A SOC analyst turns on Microsoft Entra ID Protection and expects a 'Leaked credentials' risk detection to appear in the Risk detections report within a minute of a user's password showing up in a breach dump. Several hours pass before it appears. Which statement correctly explains the timing?

Correct answer: C. Leaked credentials is an offline detection, and offline detections can take up to 48 hours to surface because ID Protection evaluates them after authentication.

ID Protection calculates some risks in real time and others offline. Real-time detections surface details in roughly 5-10 minutes, while offline detections can take up to 48 hours because they are evaluated after authentication. Leaked credentials is an offline detection (Microsoft matches credential pairs found in breach sources against the tenant), so a delay of hours is normal and expected rather than a fault.

Why the other options are wrong:

  • A. Leaked credentials is detected by matching breach data against the tenant offline and can raise user risk without the user signing in at all.
  • B. Not all detections are real-time; many, including leaked credentials, are offline. Entra ID P2 governs which detections are visible, but it is not the reason for the timing delay.
  • D. Leaked credentials is offline, not real-time, so a delay of hours is expected and is not a licensing issue; real-time detections are the ones that surface in about 5-10 minutes.

Memory hook: Real-time detections = ~5-10 minutes; offline detections (like leaked credentials) = up to 48 hours.

Microsoft Learn: https://learn.microsoft.com/entra/id-protection/concept-risk-detection-types

A Conditional Access policy requires a custom authentication strength that includes ONLY Windows Hello for Business. On a shared Windows device, a user signed in to Windows with a password (not Windows Hello) as their primary method, then opens an application protected by this policy. What is the expected behavior?

Correct answer: D. The user is not prompted for Windows Hello for Business; they must restart the session, select Sign-in options, and choose Windows Hello for Business.

This is a documented Windows Hello for Business behavior for authentication strengths: if the user signed in with a different primary method (such as a password), Microsoft Entra ID does not prompt them to switch to Windows Hello for Business. The user must restart the session, choose Sign-in options, and select a method that the authentication strength requires.

Why the other options are wrong:

  • A. Conditional Access does not fail open here; access is not granted until the required method is used.
  • B. There is no silent step-up to Windows Hello for Business in this scenario; that is the common misconception.
  • C. A password does not satisfy a strength that requires Windows Hello for Business.

Memory hook: WHfB not your primary? No prompt - restart and pick it from Sign-in options.

Microsoft Learn: https://learn.microsoft.com/entra/identity/authentication/concept-authentication-strengths#limitations

An organization historically enabled MFA per user (legacy per-user MFA). They now have a Conditional Access policy that requires MFA for all users and want to follow Microsoft's 'switch from per-user MFA to Conditional Access' recommendation. After confirming the Conditional Access policy covers everyone, what final step completes the migration?

Correct answer: C. In Users, then Per-user MFA, set each affected user's per-user MFA state to Disabled so Conditional Access governs MFA.

The recommendation's action plan is to first require MFA through a Conditional Access policy that covers your users, then ensure the per-user MFA configuration is turned off by setting each affected user's per-user MFA state to Disabled in Users, then Per-user MFA. Leaving users Enabled or Enforced keeps the legacy per-user prompts active alongside Conditional Access.

Why the other options are wrong:

  • A. Security Defaults cannot coexist with Conditional Access policies, so enabling them is not possible here and would not perform the migration.
  • B. 'Manage migration' set to Migration Complete finalizes the Authentication methods policy migration (where methods are managed); that is a different migration and does not turn off per-user MFA enforcement.
  • D. Deleting registered methods forces disruptive re-registration and is not part of the per-user-MFA-to-Conditional-Access migration.

Memory hook: Per-user MFA to CA: build the CA policy, then set per-user MFA state to Disabled. (Migration Complete is the methods-policy migration, not this.)

Microsoft Learn: https://learn.microsoft.com/entra/identity/monitoring-health/recommendation-turn-off-per-user-mfa

An organization has Conditional Access policies that enforce location-based controls using named IP locations. A user is authenticated from an allowed IP range. Their access token is valid. The user then moves to a different physical location, and their outbound IP changes to one outside the trusted range. Using Continuous Access Evaluation with IP-based location policies, which type of named location condition is enforced in near real time when the IP changes?

Correct answer: D. IPv4 and IPv6 address range-based named locations.

CAE only has insight into IP-based named locations defined by IPv4 and IPv6 address ranges. When a user moves outside these ranges and the resource provider detects the IP change, CAE can enforce the location policy near-real-time by issuing a claim challenge. CAE does not have insight into country/region-based locations or the MFA trusted IPs feature in the legacy MFA service settings page. If only country/region or MFA trusted IP locations are used, CAE issues a standard one-hour token without real-time IP enforcement.

Why the other options are wrong:

  • A. Not all named location types are treated equally by CAE. Only IP address range-based named locations are eligible for real-time CAE enforcement.
  • B. Country/region-based named locations are not supported by CAE. When these location conditions are used, CAE cannot enforce real-time location changes; a standard one-hour access token is issued instead.
  • C. MFA Trusted IPs configured in the legacy MFA service settings are not supported by CAE. Using them means CAE does not enforce the location change in real time.

Memory hook: CAE location enforcement = IP ranges ONLY. Country/region and MFA Trusted IPs are invisible to CAE's real-time checks.

Microsoft Learn: https://learn.microsoft.com/entra/identity/conditional-access/concept-continuous-access-evaluation

A company is deploying Microsoft Entra Password Protection for its on-premises Active Directory environment. The security team wants to ensure that domain controllers never communicate directly with the internet as part of this deployment. Which component fulfills this network isolation requirement?

Correct answer: C. The Microsoft Entra Password Protection Proxy service, which acts as an intermediary between DC Agents and Microsoft Entra ID.

On-premises Microsoft Entra Password Protection is designed so that domain controllers never communicate directly with the internet. The DC Agent service requests password policies from the Microsoft Entra Password Protection Proxy service using RPC over TCP within the local network. The Proxy service then communicates with Microsoft Entra ID on the internet and returns the policy to the DC Agent. The DC Agent never listens on a network-accessible port and the Proxy service is stateless.

Why the other options are wrong:

  • A. Microsoft Entra Connect Health monitors sync health and is unrelated to password policy distribution for Password Protection.
  • B. Password Hash Synchronization is a separate feature that Password Protection does not require. It plays no role in distributing password policy.
  • D. The DC Agent intentionally never communicates directly with the internet. Direct internet connectivity from DCs is a core anti-pattern this architecture was designed to prevent.

Memory hook: DC Agent talks to Proxy. Proxy talks to the cloud. DCs stay off the internet - the Proxy is the internet-facing middleman.

Microsoft Learn: https://learn.microsoft.com/entra/identity/authentication/concept-password-ban-bad-on-premises

A Conditional Access administrator builds one policy with two grant controls selected: Require multifactor authentication and Require device to be marked as compliant. The intent is that a user is granted access if they satisfy EITHER control. Which configuration achieves this, and what is the default behavior when multiple controls are selected?

Correct answer: A. Select Require one of the selected controls; by default Conditional Access requires all the selected controls

When multiple grant controls are selected, Conditional Access offers Require all the selected controls (a logical AND) or Require one of the selected controls (a logical OR). By default, Conditional Access requires all selected controls. To let users in when they satisfy either MFA or a compliant device, the admin must explicitly change the setting to Require one of the selected controls.

Why the other options are wrong:

  • B. Require one of the selected controls is not the default. The default requires all selected controls, so the admin must change it explicitly.
  • C. Require all the selected controls is indeed the default, but it enforces an AND, meaning users would need both MFA and a compliant device. That is the opposite of the either/or intent.
  • D. A single Conditional Access policy can enforce multiple grant controls together and combine them with AND or OR logic, so splitting into two policies is unnecessary.

Memory hook: Default = AND (require all). For either/or, flip to Require one of the selected controls.

Microsoft Learn: https://learn.microsoft.com/entra/identity/conditional-access/concept-conditional-access-grant

An administrator builds one Conditional Access policy: 'If a user in the Finance group accesses the Payroll app, require MFA and a compliant device.' During a review, they discover that users who are NOT in Finance are still able to obtain access tokens for the Payroll app. The Finance policy is enabled and working. Why are non-Finance users getting in, and what is the correct fix?

Correct answer: B. Access tokens are issued by default when no Conditional Access policy triggers a control; a grant-only policy scoped to Finance does not restrict anyone else, so a complementary Block policy for non-Finance users (or app-level authorization) is required

Conditional Access is not restrictive by default: access tokens are issued whenever no policy condition triggers an access control. A policy that grants access with conditions to a specific subset (Finance accessing Payroll) only governs that subset; it says nothing about everyone else, so non-Finance users fall through and receive tokens. That coverage gap is the trap this question sets. The fix is a complementary policy that blocks non-Finance users from Payroll (Microsoft's own example pairs a Finance grant policy with a 'not-Finance, block' policy), or enforcing authorization at the application layer. The Conditional Access gap analyzer workbook helps surface apps and users with no policy coverage.

Why the other options are wrong:

  • A. Grant policies do not implicitly deny users outside their assignment. A policy scoped to Finance simply does not evaluate for non-Finance users, so it neither grants nor blocks them; they are covered by no policy and get a token by default.
  • C. The scenario states the Finance policy is enabled and working (Finance users are correctly challenged). The non-Finance access is a coverage gap, not a report-only artifact.
  • D. There is no implicit deny-all in Conditional Access. Default behavior is that a token is issued unless a matching policy blocks or adds a required control, so the cause is a missing block policy, not a disabled one.

Memory hook: Conditional Access is allow-by-default. A grant policy for a subset protects no one else. To keep others out of a resource, add a Block policy.

Microsoft Learn: https://learn.microsoft.com/entra/identity/conditional-access/plan-conditional-access

In an Azure Public (commercial) tenant, an administrator opens Password protection to review smart lockout without customizing any value. What are the default smart lockout threshold and lockout duration?

Correct answer: D. Lock after 10 failed attempts, for 60 seconds, with the duration increasing on repeated lockouts.

Smart lockout is always on. For Azure Public (commercial) tenants the default lockout threshold is 10 failed attempts and the default lockout duration is 60 seconds (one minute), and the duration increases with each subsequent lockout. Azure US Government tenants default to a threshold of 3. Customizing these values requires Microsoft Entra ID P1.

Why the other options are wrong:

  • A. The default lockout duration is 60 seconds, not 5 minutes.
  • B. A threshold of 3 is the default for Azure US Government tenants, not Azure Public/commercial tenants (which default to 10).
  • C. 5 attempts / 30 minutes resembles the default account-lockout behavior of a Microsoft Entra Domain Services managed domain, not Entra smart lockout.

Memory hook: Smart lockout default = 10 tries, 60 seconds (US Gov = 3). Customizing needs P1.

Microsoft Learn: https://learn.microsoft.com/entra/identity/authentication/howto-password-smart-lockout

An administrator needs to exclude a specific fleet of Teams Room devices (tagged with a custom extension attribute) from an MFA-requiring Conditional Access policy. In the policy Conditions, they see a 'Device state (deprecated)' condition and a 'Filter for devices' condition. Which should they use, and what constraint applies?

Correct answer: D. Use Filter for devices with a rule expression on device properties; the deprecated Device state condition and Filter for devices cannot be used together in the same policy

The Device state condition is deprecated, and Microsoft directs customers to use the Filter for devices condition instead. Filter for devices lets you include or exclude devices based on a rule expression over device properties (such as trustType, isCompliant, deviceOwnership, model, manufacturer, or extension attributes), authored with the rule builder or syntax similar to dynamic group rules. A key constraint: Device state and Filter for devices cannot both be used in the same Conditional Access policy. Filter for devices provides more granular targeting, which is exactly what tagging the Teams Room fleet by extension attribute needs.

Why the other options are wrong:

  • A. Device state and Filter for devices are mutually exclusive within a single policy; they cannot be combined. You choose one, and Filter for devices is the supported path.
  • B. This reverses the current guidance. Device state is the deprecated condition; Filter for devices is the current, recommended one that supports richer property-based targeting.
  • C. Filter for devices is specifically designed to evaluate device identity attributes via rule expressions. Device platforms only distinguishes OS type (from user agent) and cannot target a specific tagged device fleet.

Memory hook: Device state is retired. Use Filter for devices with a rule, and never try to run both in one policy.

Microsoft Learn: https://learn.microsoft.com/entra/identity/conditional-access/concept-condition-filters-for-devices

A security administrator is reviewing the Microsoft Entra ID Protection reports and wants to dismiss a user risk detection that was confirmed as a false positive. Which role is the minimum required to dismiss user risk in Microsoft Entra ID Protection?

Correct answer: B. Security Operator

The Security Operator role can view all ID Protection reports and perform remediation actions including dismissing user risk, confirming safe sign-ins, and confirming compromise. The Security Reader role can view reports but cannot take action on risks. The Global Reader role also provides read-only access with no ability to update risks. The User Administrator can reset user passwords but cannot read or write to ID Protection policies or risk data.

Why the other options are wrong:

  • A. Security Reader can view all ID Protection reports and the overview but cannot configure policies, dismiss risk, reset passwords, or take any remediation action.
  • C. User Administrator can reset user passwords, which is one method of remediating a risky user, but the role cannot read or write to ID Protection reports or directly dismiss user risk.
  • D. Global Reader has read-only access across the Microsoft Entra admin center and cannot write to or remediate ID Protection risk findings.

Memory hook: Readers look, Operators act. Security Operator is the minimum role that can dismiss the alarm.

Microsoft Learn: https://learn.microsoft.com/en-us/entra/id-protection/overview-identity-protection

A security engineer is asked to make passkey (FIDO2) security keys available to a pilot group of finance users in Microsoft Entra ID. The engineer wants to use the least-privileged role and the current, supported control surface. Which role and location should the engineer use to enable the method?

Correct answer: D. Authentication Policy Administrator, by enabling Passkey (FIDO2) in the Authentication methods policy and targeting the pilot group

Which authentication methods exist in the tenant and who may register them is governed by the Authentication methods policy, edited by an Authentication Policy Administrator. To enable passkeys, the admin browses to Entra ID, then Authentication methods, then Policies, selects Passkey (FIDO2), turns on the Enable toggle, and targets the pilot group under Include. This is the canonical, current control plane, and passkey (FIDO2) is a method that does not even exist in the legacy MFA service settings.

Why the other options are wrong:

  • A. FIDO2 security keys, Temporary Access Pass, Windows Hello for Business, and certificate-based authentication have no equivalent in the legacy MFA service settings. Using Global Administrator also violates least privilege for this task.
  • B. Registering a key per user is a downstream user action, not how the method is enabled tenant-wide, and it does not scale to a pilot group. The method must first be enabled and targeted in the Authentication methods policy.
  • C. Conditional Access enforces which strength or control is required at sign-in, but it does not enable or make a method available for registration. A user cannot satisfy a FIDO2 requirement if the method was never enabled in the Authentication methods policy first.

Memory hook: New methods (FIDO2, TAP, WHfB) live only in the modern Authentication methods policy. Auth Policy Admin flips the toggle.

Microsoft Learn: https://learn.microsoft.com/entra/identity/authentication/how-to-authentication-passkeys-fido2

You must grant an engineer the least-privileged Microsoft Entra built-in role that lets them enable passkeys (FIDO2) and Temporary Access Pass in the tenant-wide Authentication methods policy, without granting broad identity administration or the ability to reset arbitrary users' credentials. Which role should you assign?

Correct answer: C. Authentication Policy Administrator

Managing the tenant-wide Authentication methods policy (enabling methods such as FIDO2 passkeys and TAP and their configuration) requires the Authentication Policy Administrator role. Microsoft Learn explicitly directs admins to sign in 'as at least an Authentication Policy Administrator' to configure this policy, and this is the least-privileged role for the task.

Why the other options are wrong:

  • A. Global Administrator can do this but is far more privileged than required, violating least privilege.
  • B. Authentication Administrator manages authentication methods for individual (non-admin) users and can force re-registration, but it does not configure the tenant Authentication methods policy.
  • D. Security Administrator manages many security features but does not have rights to configure the Authentication methods policy.

Memory hook: Policy Admin sets the Policy; plain Authentication Admin only resets users.

Microsoft Learn: https://learn.microsoft.com/entra/identity/authentication/how-to-authentication-temporary-access-pass

An administrator creates a named location defined by Countries/Regions and wants to select 'Mark as trusted location' so that sign-ins from it lower Microsoft Entra ID Protection risk and can be referenced as a trusted location in policies. The 'Mark as trusted location' option is not available for this named location. What is the correct explanation?

Correct answer: B. 'Mark as trusted location' is available only for IP address range-based named locations, not for country/region-based named locations

Named locations can be defined by IPv4/IPv6 address ranges or by countries/regions, but the 'Mark as trusted location' option is offered only when you define the location by IP address ranges. When you define a location by country/region, the only extra option is whether to include unknown areas; there is no trusted designation. Trusted (IP-based) locations are used by Conditional Access to include or exclude, and sign-ins from them improve the accuracy of ID Protection's risk calculation. Because CAE and trusted-location behaviors key off IP-based locations, country/region locations cannot be marked trusted.

Why the other options are wrong:

  • A. There is no requirement that a location be referenced by a policy before it can be marked trusted. The trusted option simply does not exist for country/region locations regardless of policy usage.
  • C. Country/region locations are not treated as trusted by default; they are untrusted unless used explicitly in a policy condition, and there is no trusted toggle for them at all.
  • D. Named locations, including marking IP ranges as trusted, are a Microsoft Entra ID P1 capability. Licensing is not why the trusted option is missing for a country/region location.

Memory hook: Only IP ranges can wear the 'trusted' badge. Countries and regions never get marked as trusted.

Microsoft Learn: https://learn.microsoft.com/entra/identity/conditional-access/concept-assignment-network

A resource tenant invites B2B guests from a partner Microsoft Entra tenant. The guests already perform MFA in their home tenant, and the organization wants to avoid challenging them for MFA a second time while still keeping MFA required. Which setting should the resource-tenant administrator enable?

Correct answer: B. In cross-tenant access settings, the inbound Trust setting 'Trust multifactor authentication from Microsoft Entra tenants.'

Enabling the inbound Trust setting 'Trust multifactor authentication from Microsoft Entra tenants' in cross-tenant access settings lets the resource tenant's Conditional Access policies accept a guest's home-tenant MFA claim. MFA is still required, but a guest who already completed MFA in their home tenant is not challenged again in the resource tenant.

Why the other options are wrong:

  • A. Trusting the partner's IP ranges is fragile and does not consume the home-tenant MFA claim; it also breaks if partner egress IPs change.
  • C. Per-user MFA state applies to your own users' credentials, not externally managed guest accounts, and it does not convey trust of a partner tenant's MFA.
  • D. Turning off the MFA policy removes the MFA requirement entirely, which is not the goal; the org wants MFA to remain required.

Memory hook: Trust the guest's home-tenant MFA: cross-tenant access, then inbound Trust settings, then 'Trust multifactor authentication from Microsoft Entra tenants.'

Microsoft Learn: https://learn.microsoft.com/entra/external-id/cross-tenant-access-settings-b2b-collaboration

Hybrid Identity and Global Secure Access (15 questions)

Go deeper on this topic in Hybrid Identity and Global Secure Access Field Guide.

Both the Microsoft traffic profile and the Internet Access profile are enabled and assigned to users running the Global Secure Access client. An administrator opens Microsoft traffic policies and changes the Action for the SharePoint Online policy group (*.sharepoint.com) from Forward to Bypass. What happens to SharePoint Online traffic on those clients?

Correct answer: D. It egresses direct-and-local from the client and is not acquired by the Internet Access profile.

Traffic that is available for acquisition in the Microsoft traffic profile can only be acquired in that profile. Setting a rule to Bypass tells Global Secure Access to skip acquisition entirely, so the client uses its normal network routing path to egress directly; the Internet Access profile never inherits that traffic.

Why the other options are wrong:

  • A. The Internet Access profile never acquires traffic that is eligible for the Microsoft profile, even when that traffic is bypassed.
  • B. Bypass means the traffic egresses directly to the internet, not that it is blocked.
  • C. Private Access carries defined private application segments, not Microsoft 365 SaaS traffic.

Memory hook: Bypass = direct-and-local; the Internet profile never inherits Microsoft traffic.

Microsoft Learn: https://learn.microsoft.com/entra/global-secure-access/how-to-manage-microsoft-profile

In Microsoft Entra Internet Access, an administrator builds a custom security profile at priority 100 for the Sales group and also configures the Baseline profile with organization-wide category blocks. A colleague assumes that when the Sales profile matches, the Baseline profile is skipped. Which statement about the Baseline security profile is correct?

Correct answer: C. The Baseline profile is a catch-all at the lowest priority (65,000) that applies to all Internet Access traffic and always executes, even when a higher-priority profile matches

The Baseline security profile is special: it applies to all Internet Access traffic routed through Global Secure Access without needing a Conditional Access link, sits at the lowest priority (65,000), and always executes as a catch-all even when a Conditional Access policy matches another security profile. Priority ordering follows traditional firewall logic, where 100 is highest and 65,000 is lowest, so higher-priority custom profiles are evaluated first and can create exceptions, but the Baseline still runs. This lets you set org-wide protections in Baseline while allowing higher-priority profiles to override specific rules.

Why the other options are wrong:

  • A. The Baseline profile is the lowest priority (65,000), not the highest. Priority 100 is the highest and is used by targeted custom profiles that take precedence over Baseline for conflicting rules.
  • B. The Baseline profile is the one profile that does not require a Conditional Access link; it applies to all Internet Access traffic by default.
  • D. The Baseline profile applies to all traffic routed through Global Secure Access, including both client-based and remote network traffic, not just remote networks.

Memory hook: Baseline profile = catch-all at priority 65,000, no Conditional Access needed, ALWAYS runs even when a custom profile matches. 100 = highest, 65,000 = lowest.

Microsoft Learn: https://learn.microsoft.com/entra/global-secure-access/concept-internet-access

Quick Access is configured with the wildcard application segment *.contoso.local. An administrator then creates a Global Secure Access enterprise application with an application segment for hr.contoso.local on port 443/TCP and assigns it only to the HR group. A user who is assigned to Quick Access but not to the HR application tries to reach hr.contoso.local. What happens, and why?

Correct answer: D. Access is denied, because the enterprise application segment takes precedence over the overlapping Quick Access segment and the user isn't assigned to that application.

When an enterprise application's network segment overlaps a Quick Access segment, the enterprise application takes precedence for that resource. This enforces explicit per-app assignment, so a user who is not assigned to the HR application is blocked from reaching it even though it falls within the Quick Access wildcard.

Why the other options are wrong:

  • A. Quick Access does not win overlaps; the enterprise application segment takes precedence.
  • B. Overlap does not cancel access; HR users assigned to the application still connect normally.
  • C. The specific enterprise application segment overrides the Quick Access wildcard, not the reverse.

Memory hook: The named app beats the catch-all: explicit assignment wins the overlap.

Microsoft Learn: https://learn.microsoft.com/entra/global-secure-access/tutorial-private-access-app-segmentation

A company currently uses AD FS with password hash synchronization (PHS) configured through Microsoft Entra Connect. The security team wants to move away from AD FS and adopt pass-through authentication (PTA) instead. Which statement correctly describes a key operational difference between PHS and PTA that the team must plan for?

Correct answer: B. PTA validates user credentials against on-premises Active Directory in real time, while PHS synchronizes a hash of the password to Microsoft Entra ID

With pass-through authentication, user credentials are validated directly against on-premises Active Directory Domain Services in real time via lightweight on-premises agents. No password hash or password is stored in Microsoft Entra ID. With password hash synchronization, a hash of the on-premises password is synchronized to Microsoft Entra ID, allowing authentication to occur in the cloud without any dependency on on-premises infrastructure at sign-in time. This is a critical planning difference: PTA requires on-premises PTA agents to be available for authentication to succeed.

Why the other options are wrong:

  • A. PTA does require on-premises agents to handle real-time credential validation. It does not store credentials in Microsoft Entra ID. Only PHS can authenticate solely from the cloud after initial synchronization.
  • C. PTA does not require AD FS. PTA uses its own lightweight agent installed on-premises, separate from AD FS infrastructure. Removing AD FS is actually a common reason for migrating from federation to PTA or PHS.
  • D. This option swaps the two methods. PTA is the one that validates credentials through real-time on-premises agents; PHS is the one that stores a hash in the cloud.

Memory hook: PTA = Phone a friend on-premises every time. PHS = Hash stored in the cloud, no call needed.

Microsoft Learn: https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-azure-ad-connect

After enabling the Microsoft traffic profile, an analyst notices Microsoft Entra sign-in logs now show the security service edge proxy's egress IP instead of each user's real public IP, which breaks IP-based Conditional Access. Which Global Secure Access feature restores the user's actual public egress IP to the sign-in and audit logs?

Correct answer: C. Source IP restoration

Source IP restoration, part of the Adaptive Access feature, detects and securely communicates the user's original public egress IP to Microsoft Entra ID and Microsoft Graph, so IP-based location policies, Identity Protection risk detections, and sign-in/audit logs reflect the real client IP. It requires the Microsoft traffic profile to be enabled.

Why the other options are wrong:

  • A. The compliant network check verifies the user is on Global Secure Access; it does not surface the client IP.
  • B. Source IP anchoring makes a downstream SaaS app see your controlled egress IP; it does not restore the client IP in Entra logs.
  • D. Universal tenant restrictions block sign-ins to external tenants; they do not reveal the client's source IP.

Memory hook: Restoration = give Entra back the real client IP.

Microsoft Learn: https://learn.microsoft.com/entra/global-secure-access/how-to-source-ip-restoration

A company wants remote employees to reach an internal server over RDP (3389/TCP) and SSH (22/TCP) with Zero Trust controls and no legacy VPN. They already use Microsoft Entra application proxy to publish a couple of internal web portals. Which approach fits the RDP/SSH requirement?

Correct answer: C. Publish the server via Microsoft Entra Private Access as an enterprise application with application segments for the required ports; application proxy publishes HTTP/HTTPS web apps only.

Microsoft Entra application proxy publishes HTTP/HTTPS web applications. Arbitrary TCP/UDP protocols such as RDP and SSH are delivered by Microsoft Entra Private Access using application segments (destination, port, and protocol). Both services share the same Microsoft Entra private network connector.

Why the other options are wrong:

  • A. Private Access delivers RDP and SSH with Zero Trust controls and no VPN required.
  • B. Changing pre-authentication to Passthrough does not turn application proxy into a general TCP tunnel.
  • D. Application proxy publishes HTTP/HTTPS web apps only; it cannot expose raw RDP or SSH via external URLs.

Memory hook: App Proxy = web only; Private Access = any port (RDP, SSH, SMB).

Microsoft Learn: https://learn.microsoft.com/entra/identity/app-proxy/overview-what-is-app-proxy

A hybrid organization has Microsoft Entra hybrid joined Windows 11 devices and on-premises Active Directory. They want to deploy Windows Hello for Business so users get single sign-on to on-premises file shares, using the simplest deployment with no requirement to deploy or modify a public key infrastructure (PKI). Which trust type should they choose?

Correct answer: A. Cloud Kerberos trust

Windows Hello for Business cloud Kerberos trust is the recommended hybrid deployment model. It is the only hybrid option that requires no certificate/PKI deployment; users get a partial TGT from Microsoft Entra ID via Microsoft Entra Kerberos, and on-premises domain controllers still issue Kerberos service tickets for resource access.

Why the other options are wrong:

  • B. Key trust still depends on a PKI (domain controller certificates), so it is more complex than cloud Kerberos trust.
  • C. Certificate trust requires an enterprise PKI plus a certificate registration authority (AD FS) to issue user authentication certificates - the most infrastructure.
  • D. 'Federated trust' is not a Windows Hello for Business trust type; the three trust types are cloud Kerberos, key, and certificate.

Memory hook: Cloud Kerberos = no PKI, uses Entra Kerberos - the easy hybrid button.

Microsoft Learn: https://learn.microsoft.com/windows/security/identity-protection/hello-for-business/deploy/

An administrator enabled Microsoft Entra seamless SSO with password hash synchronization. On corporate, domain-joined Windows devices, users are still prompted for their password in the browser instead of being signed in silently. Sync is healthy and the users are in the correct groups. Which configuration is most likely missing?

Correct answer: C. The URL https://autologon.microsoftazuread-sso.com must be added to the users' browser Intranet zone, typically via Group Policy.

Browsers only send Kerberos tickets to endpoints they trust as intranet sites. Seamless SSO works by having the browser answer the Microsoft Entra sign-in service's HTTP 401 challenge with a Kerberos ticket for the AZUREADSSOACC account, so https://autologon.microsoftazuread-sso.com must be in the users' Local intranet zone, normally delivered via Group Policy. Without that zone entry, silent sign-in fails and the browser falls back to a password prompt. Placing the URL in the Trusted Sites zone instead actually blocks sign-in.

Why the other options are wrong:

  • A. Modern authentication is required for seamless SSO to work with current clients, not disabled. Turning it off would break the modern sign-in flow rather than fix silent sign-in.
  • B. The AZUREADSSOACC account is a computer object whose Kerberos decryption key is shared with Entra ID. It must not be made a Domain Admin, and doing so would not resolve the browser-zone issue.
  • D. Kerberos requires the device clock to be within five minutes of the domain controller. Deliberately skewing it by ten minutes would break ticket issuance, not enable SSO.

Memory hook: Silent SSO needs autologon.microsoftazuread-sso.com in the INTRANET zone. Not there = password prompt; Trusted Sites = hard block.

Microsoft Learn: https://learn.microsoft.com/entra/identity/hybrid/connect/how-to-connect-sso-quick-start

Cloud-only users reset their passwords with SSPR successfully, but users synchronized from on-premises AD DS get an error and their on-premises passwords never change. Password hash sync is healthy and all users are licensed for Microsoft Entra ID P1. What must be enabled so the synced users can reset their passwords?

Correct answer: D. Password writeback in Microsoft Entra Connect (or Entra Connect cloud sync)

Password writeback is the feature that writes cloud password changes back to on-premises AD DS in real time, using either Microsoft Entra Connect or Entra Connect cloud sync. Without it, a synchronized user's SSPR cannot commit the new password to AD DS, so the reset fails. Writeback is supported with password hash sync, pass-through authentication, and AD FS.

Why the other options are wrong:

  • A. The custom banned password list blocks weak passwords during change or reset; it does not enable writing the new password back to on-premises AD DS.
  • B. Seamless SSO silently signs users in on corporate devices; it has nothing to do with writing a reset password back to on-premises AD DS.
  • C. Pass-through authentication is an authentication method (and its agents do not run on domain controllers). Password writeback, not PTA, commits the SSPR change to AD DS, and writeback works with PHS, PTA, or AD FS.

Memory hook: Synced-user SSPR needs Password Writeback - the cloud change must be written back to AD DS.

Microsoft Learn: https://learn.microsoft.com/entra/identity/authentication/concept-sspr-writeback

Contoso wants a lightweight hybrid identity option: a cloud-managed, lightweight agent (supporting multiple active agents for automatic failover) that can synchronize users from a disconnected, newly acquired forest, configured entirely from the Microsoft Entra admin center. Which solution best fits?

Correct answer: C. Microsoft Entra Cloud Sync

Cloud Sync uses lightweight provisioning agents (supporting multiple active agents for automatic failover), is configured and managed in the cloud from the Microsoft Entra admin center, and supports disconnected forests, making it ideal for merger/acquisition scenarios.

Why the other options are wrong:

  • A. Wrong: Connect Sync is a heavier server-installed engine configured on-premises, and its multiple instances aren't active/active; it isn't the cloud-managed lightweight-agent option described.
  • B. Wrong: AD FS is a federation/authentication service, not a directory synchronization engine.
  • D. Wrong: Connect Health is a monitoring service for hybrid components, not a sync engine.

Memory hook: Cloud Sync = lightweight cloud-managed agents; great for M&A / disconnected forests.

Microsoft Learn: https://learn.microsoft.com/entra/identity/hybrid/cloud-sync/connect-to-cloud-sync-decision-guide

A network engineer configured a Global Secure Access remote network (a site-to-site IPsec tunnel from the branch's customer premises equipment) so that branch users can reach an internal line-of-business app published through Microsoft Entra Private Access, without installing any client. Users at the branch cannot reach the private app. What is the reason?

Correct answer: C. The Private Access traffic forwarding profile is not supported over remote network connectivity; it requires the Global Secure Access client on end-user devices.

Global Secure Access remote networks support the Microsoft traffic and Internet Access traffic forwarding profiles, but the Private Access profile is not supported over remote network connectivity. Private Access traffic can only be acquired by the Global Secure Access client installed on end-user devices. To give branch users access to a Private Access-published application, deploy the GSA client to those devices rather than relying on the clientless remote-network (IPsec) path.

Why the other options are wrong:

  • A. There is no dedicated second-tunnel requirement for DNS. Private Access simply is not available over remote network connectivity and needs the client.
  • B. Remote networks are not limited to a single port. The failure is that the Private Access profile is not carried over remote networks at all, regardless of the app's port.
  • D. The Microsoft Entra traffic profile is always-on and system-managed; disabling it is neither possible nor related to Private Access over remote networks.

Memory hook: Private Access = client only. Remote-network IPsec carries Microsoft and Internet Access profiles, never Private Access.

Microsoft Learn: https://learn.microsoft.com/entra/global-secure-access/concept-remote-network-connectivity

A company is planning a forest consolidation over the next year and will move user accounts between Active Directory domains and forests. They are installing Microsoft Entra Connect now and want the link between each on-premises user and its Microsoft Entra ID object to survive the cross-forest moves. Which attribute should be configured as the source anchor?

Correct answer: D. ms-DS-ConsistencyGuid, because its value can be carried forward when an object moves between domains or forests, preserving the link to the cloud object

Microsoft recommends ms-DS-ConsistencyGuid as the source anchor whenever objects may move between domains or forests, which is common in consolidations, mergers, and acquisitions. objectGUID is system-assigned and regenerated when an object is recreated in a new domain or forest, which breaks the link to the existing cloud object. Because ms-DS-ConsistencyGuid is a writable attribute, migration tooling can copy the value forward to the target forest so Microsoft Entra ID still hard-matches the moved object to its existing cloud identity. Microsoft's operations guidance is explicit: if you are currently using objectGUID and have cross-forest movement, switch to ms-DS-ConsistencyGuid.

Why the other options are wrong:

  • A. userPrincipalName is disqualified as a source anchor: it can change (rename, marriage, department move) and it contains an @ character, which the wizard blocks. A source anchor must be immutable.
  • B. objectGUID is stable only as long as the object stays in the same directory. When an account is recreated in a different domain or forest, AD assigns a new objectGUID, breaking the source anchor link. That is precisely the scenario ms-DS-ConsistencyGuid was designed to solve.
  • C. objectSID also changes when an account is migrated to a new domain (the account receives a new SID, with the old one retained only as SID history). It is not a supported source anchor attribute.

Memory hook: Cross-forest moves coming? Use ms-DS-ConsistencyGuid - you can carry it forward. objectGUID is reborn in the new forest and breaks the link.

Microsoft Learn: https://learn.microsoft.com/entra/identity/hybrid/connect/plan-connect-design-concepts

An organization with a federated domain wants to pilot cloud authentication (PHS) for one department before converting the whole domain from federated to managed. It needs those pilot users to authenticate directly to Microsoft Entra ID while everyone else in the same domain continues to use AD FS. Which feature accomplishes this?

Correct answer: C. Staged rollout, which overrides authentication on a per-user (security group) basis so pilot users use cloud authentication while the domain stays federated.

Staged rollout is a temporary migration mechanism for federated organizations. Adding users to a staged rollout security group makes Microsoft Entra ID stop redirecting those specific users to the federation server and instead authenticate them directly with cloud authentication (PHS, PTA, or certificate-based authentication) plus optional seamless SSO, while the domain itself remains federated for everyone else. This narrows the blast radius of migration testing: you validate cloud authentication, MFA, and Conditional Access behavior with a pilot group before performing the full domain cutover from federated to managed. Staged rollout is explicitly not intended as a permanent state.

Why the other options are wrong:

  • A. Cross-tenant synchronization provisions B2B users between separate tenants. It does not change how existing users in one federated domain authenticate.
  • B. Conditional Access controls access after authentication routing is decided. It cannot redirect a federated user to cloud authentication, which is what staged rollout does at the tenant sign-in layer.
  • D. Converting the domain to managed switches all users at once, which is exactly the large blast radius staged rollout is designed to avoid. Re-federating individuals is not how the feature works.

Memory hook: Staged rollout = move a pilot GROUP off federation to cloud auth while the domain stays federated. Temporary, per-user, pre-cutover.

Microsoft Learn: https://learn.microsoft.com/entra/identity/hybrid/connect/how-to-connect-staged-rollout

An administrator enabled Microsoft Entra Private Access and wants to begin per-app segmentation. They browse to Global Secure Access, then Applications, then Application Discovery, but the discovery table is empty. What is the most likely reason?

Correct answer: A. No users have accessed private resources through Quick Access, so there is no traffic to analyze.

Application Discovery relies on traffic flowing through Quick Access. If Quick Access is not configured, or no users have accessed applications through it, the discovery page shows an expected empty state rather than a product error.

Why the other options are wrong:

  • B. Discovery feeds the creation of enterprise applications; it does not depend on one already existing.
  • C. Application Discovery is a Private Access feature driven by Quick Access traffic, not the Internet Access profile.
  • D. The Global Secure Access client must be installed and running to generate the traffic that discovery analyzes.

Memory hook: No Quick Access traffic, no discovery data.

Microsoft Learn: https://learn.microsoft.com/entra/global-secure-access/how-to-application-discovery

An organization deploys Microsoft Entra Private Access as part of Global Secure Access to replace its legacy VPN for remote users. Which statement accurately describes what Microsoft Entra Private Access provides that a traditional VPN does not?

Correct answer: C. Private Access provides per-app Zero Trust Network Access using Conditional Access policies for each private resource

Microsoft Entra Private Access provides Zero Trust Network Access (ZTNA) at a per-application level, allowing granular Conditional Access policies to be applied to each private resource or app individually. Traditional VPNs grant access to an entire network segment once a user authenticates, which can allow lateral movement. Private Access supports per-app access for TCP and UDP applications, Quick Access for IP and FQDN ranges, and integrates deeply with Conditional Access for more granular security than a VPN provides.

Why the other options are wrong:

  • A. Private Access does not mandate FIDO2 keys. It enforces Conditional Access policies, which can require various authentication strengths, but it does not itself require FIDO2 specifically.
  • B. Universal Tenant Restrictions is a feature of Microsoft Entra Internet Access for Microsoft services, which prevents users from authenticating to unauthorized external tenants. It is not a Private Access feature.
  • D. Tunneling internet traffic to block malicious sites is the function of Microsoft Entra Internet Access (the Secure Web Gateway component), not Private Access. Private Access focuses on private, internal corporate resources.

Memory hook: VPN = opens the whole castle. Private Access = opens one specific room at a time, only if your Conditional Access badge allows it.

Microsoft Learn: https://learn.microsoft.com/en-us/entra/global-secure-access/overview-what-is-global-secure-access

Identity Governance (15 questions)

Go deeper on this topic in Microsoft Entra Identity Governance Field Guide.

You are designing a VerifiedEmployee credential and want to be able to revoke a departed employee's credential later. At issuance time, what must you configure so the credential can be found and revoked afterward, and what is the key limitation?

Correct answer: D. Index exactly one claim in the rules definition; only that claim can be searched, and only credentials issued after the index existed are revocable

Verified ID implements W3C StatusList2021 for revocation. Because Microsoft does not store credential data, the issuer must index exactly one claim (which is salted and hashed) to make credentials searchable. Only one claim can be indexed, and any credentials issued before an index existed cannot be searched or revoked.

Why the other options are wrong:

  • A. allowRevoked is a verifier-side presentation setting that decides whether to accept an already-revoked credential; it does not enable the issuer to revoke.
  • B. Only ONE claim can be indexed per credential, not all of them.
  • C. Verified ID does not store credential data; Key Vault holds the signing keys, not credential attribute values.

Memory hook: To revoke, index ONE claim up front - hashed and searchable, one only.

Microsoft Learn: https://learn.microsoft.com/entra/verified-id/how-to-issuer-revoke

A Joiner workflow includes the built-in task 'Generate Temporary Access Pass and send via email.' An administrator assumes the TAP is emailed to the new hire. Where is the Temporary Access Pass actually delivered, and what is a prerequisite for the task to work?

Correct answer: B. To the new hire's manager; requires the user's manager attribute and the manager's mail attribute to be populated.

The task 'Generate Temporary Access Pass and send via email to user's manager' generates a TAP and emails it to the new user's manager, who hands it to the employee for first sign-in and passwordless registration. Its prerequisites are a populated manager attribute on the user and a populated mail attribute on that manager. The task uses the employee's hire date as the TAP start time, so the TAP lifetime and the time-of-day on the hire date must be set so the pass is still valid on day one.

Why the other options are wrong:

  • A. The built-in task delivers the TAP by email to the manager, not by SMS to the new hire.
  • C. The TAP goes to the user's manager, not the workflow creator, and the task does require the manager and the manager's mail attributes to be populated.
  • D. The TAP is not sent to the new hire directly, precisely because the new hire has no working credential yet. An alternate-email attribute is not the delivery mechanism.

Memory hook: Generate TAP task emails the pass to the MANAGER (the new hire has no credential yet). Needs manager + manager's mail populated.

Microsoft Learn: https://learn.microsoft.com/entra/id-governance/lifecycle-workflow-tasks

You want users to automatically receive an access package assignment when their department attribute equals 'Sales' and to lose it when the attribute changes. The access package already has a request policy. Which statement about adding an attribute-based (automatic) assignment policy is correct?

Correct answer: A. An access package can have only one automatic assignment policy, and only an Identity Governance Administrator (not a catalog owner or access package manager) can create it.

An access package is limited to a single automatic assignment policy; adding more causes processing issues. Unlike request policies, catalog owners and access package managers cannot create automatic assignment policies - that requires at least the Identity Governance Administrator role.

Why the other options are wrong:

  • B. Only one automatic assignment policy is allowed per access package; configuring more leads to processing problems.
  • C. The automatic assignment policy is added on the access package's Policies tab, not on the catalog.
  • D. A request policy and an automatic assignment policy can coexist on the same access package; no conversion is needed.

Memory hook: One auto-assignment policy per package - Identity Governance Admin only.

Microsoft Learn: https://learn.microsoft.com/entra/id-governance/entitlement-management-access-package-auto-assignment-policy

A group access review runs for 10 days with Auto apply results to resource DISABLED. On day 1 a reviewer denies a user and submits all decisions. On day 3 an admin checks the group and the denied user is still a member. Why, and what must happen for the removal to occur?

Correct answer: B. Decisions apply only at the review's scheduled end date; because auto-apply is off, an admin must manually apply results after the review completes

Access changes do not take effect until the review reaches its scheduled end date, even if a reviewer completes decisions early. When auto-apply is enabled the system applies decisions shortly after the end date; when it is disabled, an administrator must manually apply the results after the review completes.

Why the other options are wrong:

  • A. Denied users can still be removed; the admin simply applies the results manually when auto-apply is off.
  • C. Reviewers can deny access in single-stage reviews; the denial was recorded, it just isn't applied yet.
  • D. Removal is not immediate on submission - it waits for the review end date, so this isn't a caching delay.

Memory hook: Early decision, late effect: changes land at the end date, and no auto-apply means you apply.

Microsoft Learn: https://learn.microsoft.com/entra/id-governance/access-reviews-faqs

In PIM you create an access review of the Security Administrator Microsoft Entra role. You want reviewers to attest only to users who can elevate into the role via just-in-time access, and you want to exclude anyone who holds the role as a standing (permanent/active) assignment. Which setting achieves this?

Correct answer: C. Assignment type = Eligible assignments only.

When creating a PIM role access review, the Assignment type scope lets you review 'eligible assignments only' (principals who can activate the role, regardless of current activation status), 'active assignments only', or 'all active and eligible assignments'. Choosing eligible assignments only reviews the just-in-time-capable users and excludes standing active assignments.

Why the other options are wrong:

  • A. 'All active and eligible' includes the active standing assignments you want to exclude.
  • B. The inactive-users scope filters by sign-in inactivity, not by eligible-versus-active assignment type.
  • D. 'Active assignments only' reviews standing/activated holders, the opposite of what is wanted.

Memory hook: Eligible = can elevate; Active = standing power.

Microsoft Learn: https://learn.microsoft.com/entra/id-governance/privileged-identity-management/pim-create-roles-and-resource-roles-review#create-access-reviews

You enable 'Require approval to activate' on the Global Administrator role in PIM but do not specify any approvers. All Global Administrators and Privileged Role Administrators currently hold eligible (not active) assignments. What is the risk?

Correct answer: C. Because no approvers are specified, active Privileged Role Administrators/Global Administrators become the default approvers - but since all of them are only eligible (none active), no one can approve and the tenant can be locked out; configure specific approvers and emergency access accounts.

When approval is required but no approvers are configured, the default approvers are the active Privileged Role Administrators/Global Administrators. If all of them are only eligible and none are active, there is no one to approve activations, which can lock you out of the tenant. Microsoft recommends configuring specific approvers and maintaining emergency access (break-glass) accounts.

Why the other options are wrong:

  • A. Requiring approval does not auto-approve on justification; a human approver (or default approver) must act.
  • B. PIM lets you enable approval without explicit approvers, which is exactly what creates the lockout risk.
  • D. PIM does not auto-activate eligible admins to approve; eligibility alone cannot approve when all are inactive.

Memory hook: Approval + no approvers + all-eligible admins = lockout; keep break-glass accounts.

Microsoft Learn: https://learn.microsoft.com/entra/id-governance/privileged-identity-management/pim-how-to-change-default-settings#role-settings

Two access packages, 'Western Territory' and 'Eastern Territory,' grant mutually exclusive sales-territory app roles, and a user should never hold both. An administrator opens the Western Territory package's Separation of duties settings and adds Eastern Territory to its Incompatible access packages list. Testing shows a user who already has Eastern Territory is blocked from requesting Western Territory, but a user who already has Western Territory can still request Eastern Territory. What is the cause and fix?

Correct answer: D. Incompatible access package relationships are unidirectional; the administrator must also open the Eastern Territory package and add Western Territory as incompatible

A separation-of-duties incompatible-access-package relationship is unidirectional. Marking Eastern Territory as incompatible on the Western Territory package only prevents users who already have Eastern Territory from requesting Western Territory. To block the reverse direction, where a user who already holds Western Territory requests Eastern Territory, you must also open the Eastern Territory package and add Western Territory to its incompatible list. Microsoft's documentation calls this out explicitly with the Western/Eastern territory example.

Why the other options are wrong:

  • A. Separation of duties supports both incompatible access packages and incompatible security groups. Referencing another access package is fully valid, so the configuration is not invalid.
  • B. The separation-of-duties check enforces at request time immediately and does not depend on an access review running first. The missing piece is the reverse incompatibility entry.
  • C. Incompatible relationships work across catalogs; the two packages do not need to share a catalog. The one-directional nature of the relationship, not a catalog mismatch, is the cause.

Memory hook: SoD incompatibility is one-way. Block both directions by adding each package as incompatible on the OTHER.

Microsoft Learn: https://learn.microsoft.com/entra/id-governance/entitlement-management-access-package-incompatible

A catalog owner is building a new access package in the Marketing catalog. They want to include a specific SharePoint Online site and a security group, but neither resource appears in the picker while they are creating the access package. Both resources exist in the tenant. What step did they miss?

Correct answer: C. The resources must first be added to the Marketing catalog; an access package can only include resources that are already in its catalog

Access packages reside in catalogs, and a catalog is a container of resources and access packages. The required order is: first add the resources (groups, applications, SharePoint sites) to the catalog, and then add those catalog resources to an access package. Resources that have not yet been added to the catalog do not appear in the access package's resource picker, which is exactly the symptom described.

Why the other options are wrong:

  • A. Adding a SharePoint site as a catalog resource does not require the catalog owner to hold the SharePoint Administrator role; they add it through the catalog as an owner of the resource. The blocker here is that the resource is not in the catalog yet, not a missing SharePoint role.
  • B. Connected organizations are identity sources for external requestors, not containers for resources. Resources are added to catalogs, not to connected organizations.
  • D. Microsoft Entra ID P2 or ID Governance is a tenant-level prerequisite for entitlement management, not a per-resource license you attach to each SharePoint site or group. Resources do not consume individual licenses to appear in an access package.

Memory hook: Resource then Catalog then Access package, in that order. If it is not in the catalog, it cannot go in the package.

Microsoft Learn: https://learn.microsoft.com/entra/id-governance/entitlement-management-catalog-create

You want a recurring group membership review that surfaces only members who haven't signed in (interactively or non-interactively) to the tenant for a long time, and you want to define that inactivity window. In the Users scope you check Inactive users (on tenant level) and set Days inactive. What is the maximum value, and what happens to very new accounts?

Correct answer: B. Up to 730 days (two years); recently created users who haven't existed for the full window are excluded from scope

When scoping a review to inactive users at the tenant level, Days inactive can be set up to 730 days (two years). Recently created users who haven't existed for at least the configured window are disregarded, ensuring a user can sign in at least once before becoming eligible for removal.

Why the other options are wrong:

  • A. 90 days is not the maximum, and new users are excluded from scope rather than force-included.
  • C. 365 days is not the maximum (730 is), and new users are excluded, not merely given a recommendation.
  • D. It is not unlimited, and inactivity is based on last sign-in; the creation date is only used to exclude very new accounts.

Memory hook: Inactive-user scope tops out at 730 days; too-new accounts get a free pass.

Microsoft Learn: https://learn.microsoft.com/entra/id-governance/create-access-review

An Identity Governance Administrator creates an access package in a catalog for an application. An internal user requests access. The policy is configured with Manager as the first approver and a fallback approver, with a 14-day request window. On day 7, neither the manager nor the fallback approver has responded. What happens to the request if alternate approvers are NOT configured?

Correct answer: B. The request is automatically denied because it was not approved within the 14-day window at expiry.

In Microsoft Entra Entitlement Management, if no approver approves or denies a request within the configured approval period, the request automatically expires and is denied. The user must submit a new request. Alternate approvers can be configured to receive the request after a specified number of days if the primary approvers have not acted, but forwarding to alternate approvers can only begin after the request reaches its half-life (day 7 in a 14-day window) and requires at least a 4-day timeout. Without alternate approvers configured, the request simply expires at day 14 without approval.

Why the other options are wrong:

  • A. There is no automatic escalation to the Identity Governance Administrator when approvers are unresponsive. The request expires unless alternate approvers are configured.
  • C. Forwarding to a second-level manager is an option only when alternate approvers are configured and the 'Second level manager as alternate approver' option is selected. Without alternate approver configuration, no forwarding occurs.
  • D. Entitlement Management does not auto-approve requests when no response is received. Approval requires an explicit approval action from a designated approver.

Memory hook: No approver response = request EXPIRES at the deadline. Auto-deny. Not auto-approve, not escalate - it just runs out of time.

Microsoft Learn: https://learn.microsoft.com/entra/id-governance/entitlement-management-access-package-create

An administrator onboards the security group 'DBA-Access' to PIM for Groups and, on the group's membership activation policy, sets 'Require approval to activate.' Eligible members are correctly prompted for approval. However, a user who is an eligible OWNER of the group activates ownership and is never prompted for approval. Assuming the configuration is otherwise correct, what explains this?

Correct answer: A. Each group in PIM for Groups has two separate policies, one for membership activation and one for ownership activation, and the approval requirement was set only on the membership policy

In PIM for Groups, every onboarded group has two independent policies: one governing activation of membership and one governing activation of ownership. Settings such as require-approval, MFA, and maximum activation duration are configured per policy. Setting 'Require approval to activate' on the membership policy does not affect ownership activation; the ownership policy must be configured separately to require approval for owners.

Why the other options are wrong:

  • B. Nothing in the scenario indicates a break-glass account was used, and PIM policy applies to eligible assignments generally. The straightforward explanation is that membership and ownership are governed by two distinct policies.
  • C. Approval requirements apply to activation of group membership or ownership regardless of what the group grants, whether third-party apps, Azure roles, or Microsoft Entra roles. The setting is not limited to Entra-role elevation scenarios.
  • D. Owners are not inherently exempt from approval. Their activation is governed by the separate ownership policy, which in this case was not configured to require approval. Configure the ownership policy and owners will also be prompted.

Memory hook: PIM for Groups equals TWO policies per group: membership and ownership. Set approval on one and the other is untouched.

Microsoft Learn: https://learn.microsoft.com/entra/id-governance/privileged-identity-management/concept-pim-for-groups

You create an access review for a group with 'Auto apply results to resource' enabled and 'If reviewers don't respond' set to 'Take recommendations'. The assigned reviewer goes on leave and makes no decisions. What happens to group members when the review ends?

Correct answer: D. Unreviewed users have the system recommendation applied automatically - users with no sign-in in 30 days are denied and removed - because auto-apply is on and the no-response action is 'Take recommendations'.

With auto-apply enabled and the no-response action set to 'Take recommendations', unreviewed users automatically get the system recommendation. Recommendations deny users inactive for 30+ days, so those users are removed. Microsoft explicitly warns this combination can revoke access broadly if reviewers fail to respond.

Why the other options are wrong:

  • A. Access reviews close at the end of the duration (or when stopped); they don't wait indefinitely for reviewers.
  • B. 'Take recommendations' applies the recommendation (deny for inactive users); it does not default to approve.
  • C. The no-response action fires precisely when auto-apply is enabled; that combination is what triggers automatic removal.

Memory hook: Auto-apply + Take recommendations = silent removals when reviewers ghost.

Microsoft Learn: https://learn.microsoft.com/entra/id-governance/create-access-review#create-a-single-stage-access-review

Your organization is standing up Microsoft Entra Verified ID to issue employee credentials. During setup you must choose the trust system that resolves decentralized identifiers (DIDs) so a wallet can look up the issuer's public keys and confirm domain ownership. Which trust system is currently supported and generally available in Microsoft Entra Verified ID?

Correct answer: B. did:web

Verified ID currently supports the did:web trust system, which is generally available. did:web is a permission-based model that anchors trust in a web domain's existing reputation: the DID document is hosted under the organization's own DNS domain, so wallets resolve the issuer's public keys and validate linked-domain ownership from there.

Why the other options are wrong:

  • A. Azure Key Vault stores the signing keys for the solution, but it is not the trust system that resolves DIDs.
  • C. did:key is a static method that isn't resolvable via a DNS domain and isn't used by Verified ID's trust system.
  • D. did:ion (ION) was the earlier trust system and is not the current generally available method that Verified ID uses.

Memory hook: Verified ID trusts the web: did:web, not did:ion.

Microsoft Learn: https://learn.microsoft.com/entra/verified-id/decentralized-identifier-overview

A security analyst monitoring Privileged Identity Management notices that a colleague was granted the Global Administrator role directly through the Microsoft Entra roles blade rather than through a PIM eligible assignment. Which PIM security alert is raised for this, and at what severity?

Correct answer: C. 'Roles are being assigned outside of Privileged Identity Management' (High severity)

PIM raises the 'Roles are being assigned outside of Privileged Identity Management' alert, at High severity, when a privileged role assignment is created directly through the roles blade, Azure IAM, or the API rather than through PIM. Microsoft rates it High because assignments made outside PIM are not properly monitored and might indicate an active attack; the in-portal mitigation removes the user from the privileged role.

Why the other options are wrong:

  • A. 'Administrators aren't using their privileged roles' is a Low-severity alert about eligible users who have not activated their roles recently. It concerns underuse, not out-of-band assignment.
  • B. 'There are too many Global Administrators' is Low severity and fires when the count of Global Administrators exceeds a threshold, which is unrelated to how a specific assignment was made.
  • D. 'Potential stale accounts in a privileged role' is Medium severity and flags privileged accounts that have not signed in for a configurable number of days, not the method by which a role was assigned.

Memory hook: Assigned outside PIM equals the HIGH-severity alert. Underuse, staleness, and too-many-GAs are all Low or Medium.

Microsoft Learn: https://learn.microsoft.com/entra/id-governance/privileged-identity-management/pim-how-to-configure-security-alerts

An access package uses a policy For users not in your directory scoped to a connected organization (partner Contoso). You want the partner's own point of contact - a Contoso employee you previously invited as a B2B guest into your tenant - to approve incoming requests from Contoso users. Which approver type do you select?

Correct answer: A. External sponsor

External sponsors are guest users from the connected organization who are already in your directory; internal sponsors are member (internal) users of your directory. For requests from external users, the partner's B2B guest contact is the external sponsor and can be designated as the approver.

Why the other options are wrong:

  • B. An internal sponsor is a member (internal) user of your own directory, not the partner's guest contact.
  • C. Manager as approver relies on the requestor's Manager attribute, which external users typically don't have populated in your tenant.
  • D. A fallback approver only receives the request when the primary approver (for example, a manager or sponsor) can't be found; it isn't the partner-contact designation.

Memory hook: External sponsor = partner's guest contact; internal sponsor = your own member user.

Microsoft Learn: https://learn.microsoft.com/entra/id-governance/entitlement-management-organization

Workload Identities and Application Management (15 questions)

Go deeper on this topic in Workload Identities and Application Management Field Guide.

A developer wants to control which in-app features a user can access and receive that assignment in the token so the app can enforce it in code. They're deciding among Azure RBAC, Microsoft Entra directory roles, and app roles. Which should they use, and why?

Correct answer: A. App roles defined in the application's registration, returned in the roles claim for the app to enforce.

Application-specific authorization is implemented with app roles: the developer defines roles in the app registration, admins assign users/groups to them, and the assignments are emitted in the token's roles claim for the app's code to evaluate. This is distinct from Azure RBAC (governs Azure Resource Manager resources) and Microsoft Entra RBAC (governs directory resources).

Why the other options are wrong:

  • B. Custom security attributes tag directory objects for filtering/governance; they aren't an in-app role model returned for authorization.
  • C. Azure RBAC controls access to Azure resources via Resource Manager, not feature-level authorization inside your app.
  • D. Directory roles manage Microsoft Entra resources (users, groups, apps); they aren't a model for in-app feature access.

Memory hook: In-app feature authz = app roles (app RBAC); Azure RBAC = Azure resources; Entra roles = directory.

Microsoft Learn: https://learn.microsoft.com/entra/identity-platform/custom-rbac-for-developers

To restrict several single-tenant service principals from authenticating outside the corporate IP ranges, an administrator adds those service principals to a security group and targets a Conditional Access for workload identities policy at the group. Testing shows the policy is not enforced for the service principals. What is the correct explanation and fix?

Correct answer: A. A Conditional Access policy targeting a group that contains a service principal is not enforced for that service principal; each service principal must be assigned directly to the policy as a workload identity

Conditional Access for workload identities does not honor group membership: although a service principal can be added to a group, a policy assigned to a group that contains a service principal is not enforced for that service principal. To enforce the policy, the service principals must be selected and assigned directly as workload identities in the policy. (The feature also only covers single-tenant service principals registered in your tenant and requires Workload Identities Premium.)

Why the other options are wrong:

  • B. Managed identities are actually out of scope for Conditional Access for workload identities. The fix is direct assignment of the single-tenant service principals, not switching to managed identities.
  • C. Owner versus member status is irrelevant. Conditional Access for workload identities simply does not evaluate group membership for service principals; direct assignment is required regardless.
  • D. Report-only versus On controls whether a policy enforces or only logs, but it does not make group-based targeting work for service principals. Even when On, group membership is not honored.

Memory hook: Workload-identity CA ignores groups. Assign each single-tenant service principal directly.

Microsoft Learn: https://learn.microsoft.com/entra/identity/conditional-access/workload-identity

You change User consent settings to 'Allow user consent for apps from verified publishers, for selected permissions.' Afterward, users can't consent to any application, even a verified-publisher app that requests only Microsoft Graph User.Read. What is the most likely cause?

Correct answer: C. No permissions have been classified as low impact, so the 'selected permissions' option currently allows no user consent.

The 'verified publishers, for selected permissions' option (microsoft-user-default-low) lets users consent only to permissions you explicitly classify as low impact under Permission classifications. If you haven't classified any permissions, the set of user-consentable permissions is empty, so users can't consent to anything, even User.Read.

Why the other options are wrong:

  • A. User.Read is a low-privilege delegated permission that does not require admin consent by default.
  • B. User consent setting changes affect only future consent operations; existing grants remain intact.
  • D. The stem specifies a verified-publisher app, so lapsed verification isn't the cause; the missing piece is permission classification.

Memory hook: 'Selected permissions' consent is empty until you populate Permission classifications: classify low-impact perms or nobody can consent.

Microsoft Learn: https://learn.microsoft.com/entra/identity/enterprise-apps/configure-user-consent

A GitHub Actions pipeline that runs on GitHub-hosted runners deploys resources to Azure. It currently authenticates using a client secret stored as a GitHub repository secret. The security team wants to eliminate the stored secret entirely while keeping the same app registration and its permissions. Which approach should they implement?

Correct answer: C. Configure a federated identity credential on the app registration that trusts GitHub's OIDC token

Workload identity federation lets you configure a federated identity credential on the app registration that trusts tokens issued by an external identity provider such as GitHub. The GitHub Actions workflow presents its OIDC token; Microsoft Entra validates it against the credential (issuer, subject, and audience must match, case-sensitively) and returns an access token. No secret is stored anywhere, and the existing app registration and its granted permissions are reused.

Why the other options are wrong:

  • A. A certificate is more secure than a secret, but storing the private key as a GitHub secret still keeps a long-lived credential in the pipeline, which is exactly what the team wants to eliminate.
  • B. Extending and rotating a client secret keeps a stored credential and its leakage/expiry risk. The requirement is to remove the stored secret entirely, which federation achieves.
  • D. A managed identity requires the workload to run on Azure infrastructure and reach the Azure Instance Metadata Service. GitHub-hosted runners run outside Azure and cannot use a managed identity directly.

Memory hook: Runner outside Azure + no secret = federated identity credential trusting GitHub's OIDC token.

Microsoft Learn: https://learn.microsoft.com/entra/workload-id/workload-identity-federation

You are documenting how apps obtain permissions in your tenant. One app is a single-page app that requests additional delegated scopes incrementally as the user opens new features; another is a daemon that uses application permissions. Which statement correctly describes the consent behavior and the resulting Microsoft Graph objects?

Correct answer: B. Delegated permissions support both static and dynamic consent and produce an oauth2PermissionGrant; application permissions are static-only and produce an appRoleAssignment.

Delegated permissions can be consented statically (a pre-configured list on the app registration) or dynamically (requested incrementally at sign-in) and, when granted, create an oauth2PermissionGrant. Application permissions can be consented only statically and only by an admin; granting them creates an appRoleAssignment.

Why the other options are wrong:

  • A. Only delegated permissions support dynamic/incremental consent; application permissions are static-only.
  • C. It is reversed: delegated permissions (scopes) surface in the scp claim, and application permissions (app roles) surface in the roles claim.
  • D. Permission classifications (low impact) apply only to delegated permissions eligible for user consent; application permissions always require admin consent.

Memory hook: Delegated = scopes/scp + oauth2PermissionGrant (static or dynamic); Application = roles + appRoleAssignment (static, admin-only).

Microsoft Learn: https://learn.microsoft.com/entra/identity-platform/permissions-consent-overview#types-of-permissions

Microsoft Entra ID Protection flags one of your service principals with a 'Suspicious Sign-ins' detection. Where do you review this, and what is an appropriate remediation?

Correct answer: D. Microsoft Entra admin center, then ID Protection, then Risky workload identities; remediate by rotating and removing the service principal's credentials (add a new certificate, remove compromised secrets) and optionally disabling the service principal.

ID Protection surfaces risky workload identities under ID Protection, then Risky workload identities (also queryable via the riskyServicePrincipals and servicePrincipalRiskDetections Graph APIs). Remediation guidance is to inventory and rotate credentials: add a new credential (certificates recommended) and remove the compromised secrets/certs. You can also confirm compromise or disable the service principal to block further sign-ins.

Why the other options are wrong:

  • A. Workload identities can't perform MFA, and service principals aren't listed in the Risky users report.
  • B. Service principals don't have user passwords and don't appear under the Users blade.
  • C. Service principal risk is a credential/identity issue, not a device you isolate in Defender for Endpoint.

Memory hook: Risky workload identities live under ID Protection. Remediate by rotating credentials, not resetting a password.

Microsoft Learn: https://learn.microsoft.com/entra/id-protection/concept-workload-identity-risk

A developer builds a custom line-of-business web app that uses OpenID Connect. Working in their own tenant, they need to add a redirect URI and generate a client secret so the app can authenticate to Microsoft Entra. Which Microsoft Entra admin center experience should the developer use to configure these settings?

Correct answer: C. App registrations

App registrations is where you manage the application object, the developer/blueprint view of an app in its home tenant. Redirect URIs, client secrets and certificates, declared API permissions, and single-tenant vs. multitenant selection are all application-object properties configured under App registrations. Enterprise applications, by contrast, is the administrator view of the service principal (the local instance), where consent, user assignment, and SSO for a provisioned app are governed.

Why the other options are wrong:

  • A. The Managed Identities experience is for Azure-managed identities, whose credentials Azure owns automatically. Managed identities have no application object, no redirect URI, and no client secret to configure.
  • B. Application Proxy is used to publish on-premises web apps for secure remote access. It is unrelated to configuring redirect URIs or secrets for a cloud OIDC app registration.
  • D. Enterprise applications manages the service principal (consent records, user/group assignment, SSO configuration for a provisioned instance). It does not expose redirect URI or client-secret configuration for the application object.

Memory hook: Redirect URIs and secrets = the blueprint = App registrations. Consent and assignment = the instance = Enterprise applications.

Microsoft Learn: https://learn.microsoft.com/entra/identity-platform/app-objects-and-service-principals

An administrator wants to add a preintegrated SaaS application (one of the thousands of gallery apps that support SSO out of the box) to the tenant. In the Microsoft Entra admin center, what is the correct path to begin?

Correct answer: C. Enterprise applications, then New application, then Browse Microsoft Entra Gallery

Preintegrated gallery SaaS apps are added via Enterprise applications, then New application, which opens 'Browse Microsoft Entra Gallery'. App registrations is for registering your own custom application identities, not for consuming gallery SaaS apps.

Why the other options are wrong:

  • A. Application proxy, then New application publishes on-premises apps for remote access, not cloud gallery SaaS apps.
  • B. App registrations, then New registration is for developing/registering a custom app identity, not for adding a gallery SaaS app.
  • D. Enterprise State Roaming is a device settings-sync feature, unrelated to adding SaaS applications.

Memory hook: Gallery SaaS lives under Enterprise applications, then New application; App registrations is for your own code.

Microsoft Learn: https://learn.microsoft.com/entra/identity/enterprise-apps/add-application-portal-setup-sso

Auditors require that each application instance's resource access be attributable to that specific resource, and that the identity and its permissions be removed automatically when the resource is deleted. Which managed identity type best meets both requirements?

Correct answer: B. A system-assigned managed identity.

A system-assigned managed identity is created as part of a single Azure resource, is unique to it (supporting per-resource attribution in audit logs), and shares the resource's lifecycle: when the resource is deleted, the identity is deleted too. Microsoft Learn specifically recommends system-assigned for audit-logging and permission-lifecycle scenarios.

Why the other options are wrong:

  • A. A shared user-assigned identity can't attribute actions to a specific resource and has an independent lifecycle, surviving resource deletion.
  • C. An app registration with certificates puts credential lifecycle back on you, defeating the managed-identity goal.
  • D. A per-resource user-assigned identity still has an independent lifecycle and must be deleted manually, so it isn't auto-removed with the resource.

Memory hook: Tie identity to the resource's birth and death, one-to-one for audit = system-assigned.

Microsoft Learn: https://learn.microsoft.com/entra/identity/managed-identities-azure-resources/overview#managed-identity-types

A risk-based Conditional Access policy is configured to block access when 'Service principal risk' is detected as high for a specific set of service principals. An administrator finds that the policy does not apply to managed identities in the tenant. What is the primary reason?

Correct answer: B. ID Protection workload identity risk and risk-based Conditional Access for workload identities targets single-tenant non-Microsoft SaaS and multi-tenant apps, not managed identities.

Microsoft Entra ID Protection detects risk on workload identities, but its scope explicitly excludes managed identities. The documentation states: 'ID Protection detects risk on single tenant, non-Microsoft SaaS, and multitenant apps. Managed Identities are not currently in scope.' Therefore, a Conditional Access policy based on service principal risk will not apply to managed identities regardless of configuration.

Why the other options are wrong:

  • A. The 'high' risk level is a valid threshold for risk-based Conditional Access policies. The issue is not the threshold setting but the fact that managed identities are outside the scope of ID Protection workload identity risk detection entirely.
  • C. Managed identities are not broadly excluded from all Conditional Access policies by default. Rather, the specific limitation is that ID Protection does not generate risk signals for managed identities, so risk-based policies have no signal to act on.
  • D. While Workload Identities Premium provides full risk detail reporting, the scope limitation on managed identities is a product capability boundary, not a licensing-only restriction.

Memory hook: ID Protection workload risk = apps and service principals only. Managed Identities are currently OUT of scope for risk detection.

Microsoft Learn: https://learn.microsoft.com/entra/id-protection/concept-workload-identity-risk

A developer needs to call the Microsoft Graph API from their registered application. The application runs as a background service with no signed-in user. Which OAuth 2.0 grant type should the developer use, and which type of permissions are required?

Correct answer: D. Client credentials flow with application permissions

When an application runs as a background service or daemon without a signed-in user, it must use the OAuth 2.0 client credentials flow. This flow allows the application to authenticate using its own identity (client ID and secret or certificate) rather than on behalf of a user. Application permissions (also called app-only permissions) must be granted via admin consent because there is no user to provide delegated consent. Delegated permissions are only appropriate when a signed-in user is present.

Why the other options are wrong:

  • A. The authorization code flow requires a signed-in user who can provide delegated consent. Background services have no interactive user, so this flow is not applicable.
  • B. The on-behalf-of flow allows an application to call a downstream API on behalf of a signed-in user. It requires a user's access token as input and applies delegated permissions, not application permissions. Background services cannot use this flow.
  • C. The device code flow is designed for devices that cannot display a browser, such as IoT devices or CLI tools, where a user signs in on a separate device. It still requires a signed-in user and uses delegated permissions.

Memory hook: No user = client credentials + app permissions. User present = auth code + delegated permissions.

Microsoft Learn: https://learn.microsoft.com/entra/identity-platform/v2-oauth2-client-creds-grant-flow

A reporting daemon is granted the Microsoft Graph Files.Read.All application permission (admin-consented). During a security review you are asked exactly what files it can read. Which answer is correct?

Correct answer: A. Any file in the tenant, because application permissions grant app-only access that is not bounded by any user's rights.

Application permissions grant app-only access using the app's own identity, independent of any user. Microsoft Graph's Files.Read.All application permission lets the app read every file in the organization. Because there is no user to bound the access, only an administrator can consent to it.

Why the other options are wrong:

  • B. App-only access needs no signed-in user; the daemon reads files with no user present.
  • C. That describes delegated access, where the app is limited to what the signed-in user can already reach.
  • D. Files.Read.All is tenant-wide, not scoped to the app's own storage.

Memory hook: Application permission = the whole tenant's data; delegated = only what the signed-in user can already reach.

Microsoft Learn: https://learn.microsoft.com/entra/identity-platform/permissions-consent-overview#types-of-permissions

An engineer holding the Application Administrator role adds the Microsoft Graph application permission User.Read.All to an app registration. The permission is added successfully, but when they try to complete the setup, the 'Grant admin consent' action is not available to them. What explains this behavior?

Correct answer: D. Application Administrator can add Microsoft Graph application permissions but cannot grant admin consent to them; a Privileged Role Administrator (or Global Administrator) is required

Application Administrator (and Cloud Application Administrator) can consent to delegated permissions and to application permissions for most APIs, but with an explicit exception: they cannot grant admin consent to Microsoft Graph app roles (application permissions). Granting those requires a Privileged Role Administrator or Global Administrator. This separates adding a permission (a lower-privilege task) from granting it (a higher-privilege task), enforcing separation of duties.

Why the other options are wrong:

  • A. Application permissions (app roles) are used by an app calling as itself with no signed-in user, so there is no user-consent path. They always require admin consent, not user sign-in consent.
  • B. Application permissions always require admin consent. The problem is not that consent is unnecessary; it is that this admin's role cannot grant it for Microsoft Graph app roles.
  • C. Cloud Application Administrator has the same exception as Application Administrator: it cannot grant consent to Microsoft Graph application permissions. It is not sufficient here.

Memory hook: Adding a Graph app permission is easy; granting it needs Privileged Role Administrator. App Admin can request, not grant.

Microsoft Learn: https://learn.microsoft.com/entra/identity/enterprise-apps/grant-admin-consent

A third-party multitenant SaaS application has a service principal in your tenant. During a security incident you must immediately stop Microsoft Entra ID from issuing any tokens for it (blocking both interactive user sign-ins and app-only access that uses application permissions) while you investigate. Which single action accomplishes this?

Correct answer: C. In Enterprise applications, open the app's Properties and set 'Enabled for users to sign-in?' to No.

Setting 'Enabled for users to sign-in?' to No on the enterprise application (service principal) stops Microsoft Entra ID from issuing any tokens for the app. Despite the user-focused label, it also restricts service principals from accessing the application using application permissions, which makes it a single, reversible kill switch.

Why the other options are wrong:

  • A. Removing assignments doesn't stop app-only access, and unless user assignment is required it won't block interactive sign-in either.
  • B. The app registration lives in the vendor's home tenant, not yours; you can't edit its account types, and that setting wouldn't block token issuance anyway.
  • D. A Conditional Access policy scoped to users does not block a service principal's app-only token requests; only workload-identity CA targets service principals.

Memory hook: 'Enabled for users to sign-in? = No' on the enterprise app is the kill switch: it kills user tokens AND app-only tokens.

Microsoft Learn: https://learn.microsoft.com/entra/identity/enterprise-apps/disable-user-sign-in-portal

An on-premises SharePoint site uses Integrated Windows Authentication (Kerberos). You publish it through application proxy and want seamless SSO so users already authenticated by Microsoft Entra ID are silently signed in to SharePoint. You select the Integrated Windows Authentication SSO mode with Kerberos Constrained Delegation (KCD). Which prerequisite must be true for the connector to obtain a Kerberos ticket on the user's behalf?

Correct answer: B. The server running the connector and the server running the app must be domain-joined to the same domain or trusting domains.

KCD-based SSO requires the connector host to be domain-joined (same domain as the app server or a trusting domain) so it can perform constrained delegation and request a Kerberos service ticket while impersonating the user. Valid SPNs must exist and the connector must be trusted for delegation to the app's SPN.

Why the other options are wrong:

  • A. IWA/Kerberos apps are precisely what KCD SSO is for; you do not convert them to SAML.
  • C. KCD delegation depends on Active Directory membership; a workgroup connector cannot request Kerberos tickets on a user's behalf.
  • D. SSO with KCD requires Microsoft Entra ID preauthentication, not Passthrough; choosing Passthrough removes the SSO options entirely.

Memory hook: KCD = Kerberos needs a domain. Connector must be domain-joined and trusted to delegate.

Microsoft Learn: https://learn.microsoft.com/entra/identity/app-proxy/how-to-configure-sso-with-kcd#prerequisites