Implement and manage Microsoft Entra identity and access practice questions

Set the 'Admin consent requests' setting to 'Allow'

Why wrong: Setting 'Admin consent requests' to 'Allow' controls whether users can submit requests for applications that require administrator approval. It does not govern the ability to create new app registrations; users can still register apps unless the registration permission is explicitly disabled. Therefore, this setting would not prevent users from self-registering applications.

Enable the 'Admin consent workflow'

Why wrong: Enabling the 'Admin consent workflow' establishes a review and approval process for apps that require admin consent, allowing users to request access instead of being blocked. This workflow is separate from app lifecycle management and its activation does not modify the directory-level permission that controls user app registration. Since the scenario focuses on registration, not consent, this action would not stop users from registering applications.

Set 'Users can consent to apps accessing company data' to 'No'

Why wrong: The 'Users can consent to apps accessing company data' setting governs whether users can grant permissions to applications that request access to organizational data on their behalf. Disabling this option prevents users from consenting to an app's requested permissions, but it does not stop users from registering their own applications. App registration and consent are distinct operations, so this setting is irrelevant to the stated requirement.

Password Hash Synchronization (PHS)

Why wrong: Password Hash Synchronization (PHS) is the correct choice because Azure AD Connect computes a one-way hash of each on-premises Active Directory password (using MD4 as an intermediate, then SHA-256 with a per-user salt) and synchronizes it to Entra ID, allowing users to sign in with the same password across cloud services. PHS requires no additional on-premises servers or proxies, provides a resilient fallback authentication path if federation or Pass-through Authentication is unavailable, and enables security features such as Entra Identity Protection and leaked-credential detection.

Active Directory Federation Services (AD FS)

Why wrong: Active Directory Federation Services (AD FS) is overkill for a basic requirement to use the same password on-premises and in the cloud, because it requires deploying a federation server farm, a Web Application Proxy, signing certificates, and claims-based trust relationships between Entra ID and on-premises Active Directory. AD FS authenticates users on-premises and issues security tokens, but it adds significant administrative overhead, security attack surface, high-availability demands, and long-term certificate management that provide no benefit when the organization simply needs password parity. Modern federated sign-in is only warranted for specific needs such as smartcard authentication, certain conditional access policies, or third-party identity provider integration.

Install Azure AD Connect with default settings

Why wrong: Installing Azure AD Connect with default settings is the right tool but the wrong action, because simply running the wizard does not guarantee that Password Hash Synchronization is explicitly configured as the sign-on method. The Express installation may enable PHS by default, but if the directory already has an existing federation or Pass-through Authentication configuration, the wizard might preserve that behavior instead of setting PHS. The question asks which feature to enable, not which tool to install, so you must specifically select Password Hash Synchronization on the 'Sign-On method' page during configuration for the intended outcome to be met.

The user's device is not marked as compliant

Why wrong: The scenario explicitly establishes that the user's device is already marked as compliant. A compliant device satisfies the device condition in the Conditional Access policy, so it would not trigger a repeated MFA prompt. Non-compliance would typically block access or require enrollment, not cause periodic re-authentication, making this explanation inconsistent with the stated facts.

The user has per-user MFA enabled

Why wrong: Per-user MFA is a legacy per-account setting that forces MFA at every initial sign-in, but it does not impose a recurring re-authentication interval within an active session. In this scenario, the user is being prompted repeatedly for MFA after already authenticating, which is the hallmark of a session-level control rather than a static per-user flag. If per-user MFA alone were the cause, the prompt would occur once at each sign-in, not periodically during the session.

The policy includes a location condition that is not met

Why wrong: A location condition in Conditional Access evaluates the user's IP address or named location at initial access and can block or allow sign-in, but it does not trigger recurring MFA prompts after a session is established. If the location condition were not met, the user would likely be denied access or prompted once, not repeatedly challenged for MFA. Location-based policies evaluate at request time, but they do not impose a periodic re-authentication cadence like a session control does.

MFA registration policy

Why wrong: This policy enforces MFA registration, not password change.

Sign-in risk policy

Why wrong: Sign-in risk policy usually triggers MFA or block, not password change.

Session risk policy

Why wrong: Not a standard risk policy.

A presentation request policy

Why wrong: A presentation request policy governs the verification flow, not the issuance flow. In Microsoft Entra Verified ID, a presentation request policy specifies which verifiable credentials the relying party will accept, the requested claims, and the authentication requirements when a user presents their credential wallet for verification. It does not define the schema, claims, or display rules of a credential to be issued, so creating one would fail to produce an issuance capability.

A distributed ledger network

Why wrong: The distributed ledger is an inherent part of Microsoft's infrastructure rather than something you deploy. Verified ID uses the ION (Identity Overlay Network), a Sidetree-based protocol anchored on the Bitcoin blockchain, which automatically stores the public DIDs and did-documents. When you enable Verified ID in your tenant, Microsoft creates and registers your organization's DID on this existing network; therefore, specifying or creating a distributed ledger network is not a required configuration step and is actually not even exposed as an option in the Microsoft Entra admin center.

A decentralized identifier (DID) for the organization

Why wrong: A decentralized identifier (DID) for your organization is a byproduct of the Verified ID provisioning process, not a separate manual step. When you first set up Verified ID in the Microsoft Entra admin center, the system automatically generates your tenant's DID and registers it on the ION network along with the corresponding did-document. You do not have to create the DID ahead of time; attempting to do so would be redundant and could cause confusion about the intended trust anchor. This automatic creation is a key reason why a DID is not the artifact you explicitly create to enable issuance.

Enable password writeback

Why wrong: Enabling password writeback is wrong because it only allows users to reset or change their on-premises passwords from Microsoft Entra ID (via SSPR). It does not participate in the synchronization of the account disable/enable status, so a disabled on-prem account would still be marked as enabled in the cloud until a sync cycle occurs. Password writeback also cannot shorten the sync interval, so the 5-minute requirement remains unmet.

Configure Azure AD Connect to sync the 'userAccountControl' attribute

Why wrong: While Entra Connect Sync does synchronize the userAccountControl attribute—and it is the source of the Microsoft Entra ID accountEnabled flag—the default synchronization cycle runs every 30 minutes. Configuring this attribute alone does not change the sync frequency, so a disabled account could remain active in the cloud for up to 30 minutes, exceeding the required 5-minute window. Additionally, there is no built-in mechanism in Entra Connect Sync to force per-attribute sub-30-minute synchronization without manual intervention.

Configure Microsoft Entra Connect Sync to use filtered synchronization

Why wrong: Configuring Microsoft Entra Connect Sync to use filtered (scoped) synchronization is not a valid solution because scoping only controls which OUs or objects are imported to the metaverse; it has no effect on the synchronization schedule. The classic sync engine still runs on its default 30-minute cycle, so even filtered objects will not see account disables within the 5-minute SLA. Filtering could even make the problem worse if the disabled account's OU is accidentally excluded from the sync scope.

Create a separate SSPR policy for the HR department using PowerShell

Why wrong: SSPR configuration is managed through Microsoft Entra ID authentication methods and password reset settings, which are tenant-wide objects. There is no PowerShell cmdlet that can scope self-service password reset policy to a specific security group or department. Even with Microsoft Graph PowerShell, authentication method policies and SSPR settings apply to all users; PowerShell cannot create a separate policy for a subset.

Use Microsoft Entra ID Governance to create an access package that requires two methods

Why wrong: Access packages in Entra ID Governance govern entitlement to resources like groups, apps, or SharePoint sites, not authentication requirements for password reset. They can include policies for who can request and approval workflows, but they do not alter the SSPR authentication method requirements. The number of methods required for SSPR is a tenant-wide setting, not something an access package can enforce.

Assign the HR users to a group and configure the SSPR policy for that group in the Entra admin center

Why wrong: SSPR settings such as the number of methods required and which methods are allowed are configured under the 'Authentication methods' and 'Password reset' blades in the Entra admin center, and those configurations apply to the entire tenant. Although groups can be used to target some policies like Conditional Access, SSPR does not support group-based scoping. The admin center only allows a single tenant-wide policy; there is no group selector.

Session policy

Why wrong: Session policies in Defender for Cloud Apps are evaluated in real time as a user accesses a cloud app, using Conditional Access App Control to allow, block, or restrict specific actions during that session. They are not designed to react after the fact to a detected anomaly, so they cannot suspend a user account once suspicious activity has already occurred. Suspension is a governance action, not a session-level access control.

File policy

Why wrong: File policies are scoped strictly to file objects, scanning cloud storage for malware, sharing violations, or sensitive data exposure via the content inspection engine. They evaluate attributes like file name, extension, owner, or external collaborators, not behavioral patterns of user activity. Consequently, they cannot raise an alert about a user's anomalous behavior and therefore cannot trigger a user suspension action.

App discovery policy

Why wrong: App discovery policies analyze network traffic to identify shadow IT, unsanctioned cloud apps, or risky app usage by examining firewall and proxy logs. Their purpose is to classify applications and assess their risk score, not to inspect individual user activities within already-sanctioned apps. Because they do not process user activity anomalies, they have no mechanism to suspend a user when suspicious behavior is detected.

Create a Conditional Access policy requiring approval for external users

Why wrong: Conditional Access policies enforce access decisions at sign-in time based on conditions such as user, device, location, or risk, but they have no 'approval' grant or control action. The available grant controls are limited to Block, Grant access (optionally requiring MFA, compliant device, hybrid Azure AD join, or terms of use), and session controls. Requiring a manual approval step for external users is outside the scope of Conditional Access; that capability belongs to an Entitlement Management access package approval workflow, not a Conditional Access policy.

Enable guest self-service sign-up via user flows

Why wrong: Guest self-service sign-up via user flows lets external users register themselves for applications through a customizable portal experience without any pre-existing invitation. While user flows can collect attributes and assign them to an app, they do not include an approval step for inviting a specific user; they are designed to grant access automatically based on the flow's configuration. Enabling this would lower control over who gains access, which is the opposite of the approval requirement described in the question.

Enable Identity Protection for guest users

Why wrong: Identity Protection is an Entra ID service that detects risks such as impossible travel, leaked credentials, or anonymous IP addresses and can apply policies to block access or require MFA at sign-in. It does not include any approval workflow for user invitations, nor does it review or approve external users' requests to be added to tenant resources. Even though Identity Protection can cover guest users for risk-based policies, that capability is unrelated to controlling whether an external user is approved and invited.

SMS sign-in

Why wrong: SMS sign-in is not a primary authentication method in Microsoft Entra ID; SMS is used only to deliver one-time passcodes for multifactor authentication or self-service password reset. Conditional Access authentication strength does not list SMS as a method because it lacks cryptographic proof of possession and is susceptible to SIM-swap attacks. Therefore, SMS sign-in is not a valid authentication method.

Hardware OATH token

Why wrong: Hardware OATH tokens generate time-based one-time passwords and are registered as a secondary verification factor for MFA, not as a primary identity credential. In Conditional Access, an OATH token can only be required as a second factor after the user has already signed in with a primary method such as a password. Because the token does not identify the user on its own, it is not a valid authentication method.

FIDO2 security key

Why wrong: FIDO2 security keys are a passwordless authentication option, but Conditional Access does not expose them as a separate authentication strength method; they are grouped under the broader 'Passwordless' or phishing-resistant authentication strength. In Microsoft Entra ID, authentication strength bundles FIDO2 with Windows Hello for Business and certificate-based authentication rather than offering a distinct 'FIDO2' grant control. For this question, the valid methods are Password and Certificate-based authentication, so FIDO2 is incorrect.

Set up Microsoft Entra Connect Sync for the application

Why wrong: Incorrect. Microsoft Entra Connect Sync is for synchronizing on-premises directories; it is not required for provisioning to a cloud SaaS app.

Migrate from Azure AD Connect to Azure AD Connect cloud sync

Why wrong: Incorrect. Migrating to cloud sync is unrelated; it's a different synchronization method, not needed for SaaS app provisioning.

Install and configure a provisioning agent in your on-premises environment

Why wrong: Incorrect. A provisioning agent is used for on-premises applications, not for cloud-based third-party SaaS apps.

Require Microsoft Authenticator

Why wrong: Requiring Microsoft Authenticator is an identity-based grant control that enforces multi-factor authentication, not device compliance. In Conditional Access, it ensures the user proves possession of the registered authenticator app but does not verify the device's health, patch level, encryption, or any Intune compliance status. A jailbroken phone or a compromised PC could still satisfy this control as long as the second factor succeeds.

Require session persistence

Why wrong: Requiring session persistence is a session control that dictates how long a sign-in token remains valid or whether the browser session is persistent, typically configured via sign-in frequency and persistent browser session settings. It does not evaluate the device's configuration, enrollment, or compliance posture, so it only affects the lifetime of an authenticated session. Thus, it is not a valid method for enforcing device compliance.

Require approved client app

Why wrong: Requiring an approved client app is an app-level grant control that verifies the client application being used (e.g., Outlook) is approved and may participate in app protection policies, but it does not assess the health of the underlying device. Intune app protection policies manage data access within the app, while device compliance checks are separate controls based on MDM or hybrid join state. A device could run the approved app while leaking other security policies.

Users are blocked if they are not using a compliant device

Why wrong: This policy contains no explicit Block access control in its grant controls, and the OR operator means that failing to use a compliant device is not automatically disqualifying. If a user provides multi-factor authentication, they satisfy one of the OR branches and can be granted access even though the device is non-compliant. A block outcome would require the policy to include the 'Block access' grant control or an access denial due to all grant options being unmet—which is not the case here.

Users must provide MFA and use a compliant device

Why wrong: The JSON grant controls use an OR operator, not AND, so multiple controls are not simultaneously required. Under AND semantics, both MFA and a compliant device must be met; under OR, either alone is sufficient. Therefore, a user on a compliant device could pass without performing MFA, and an MFA-verified user on a non-compliant device could also pass, making the 'must provide MFA and use a compliant device' description incorrect.

Users only need to provide MFA regardless of device

Why wrong: This description incorrectly treats MFA as the sole path to access, but the OR operator introduces an independent compliant-device branch. A user on an Intune-compliant device can bypass MFA entirely, because the 'require compliant device' control is sufficient to satisfy the policy. Thus, access is not granted 'regardless of device'; the device state directly matters as one of the alternative conditions.

Only users in a specific security group can create Microsoft 365 Groups

Why wrong: The directory setting GroupCreationAllowedGroupId is used to limit Microsoft 365 Group creation to members of a specific security group. In this scenario, that setting is empty, so no such restriction is active. Therefore, group creation is not limited to a specified security group; all users can create groups.

A naming policy is enforced for new groups

Why wrong: A naming policy for Microsoft 365 Groups requires a PrefixSuffixNamingRequirement (such as a fixed prefix or suffix) and optionally blocked words. The reported setting shows PrefixSuffixNamingRequirement is empty, meaning no group name pattern is enforced. Thus, new groups are not subject to a naming policy, making this option incorrect.

Groups must have a classification label

Why wrong: Classification labels for Microsoft 365 Groups rely on the DefaultClassification directory setting to assign a default label when none is chosen. With DefaultClassification empty, groups are created without an automatic classification, and the policy does not require users to select one. Consequently, requiring a classification label is not in effect.

An existing application registration is updated

Why wrong: Because the command's verb is `create`, not `update`, the CLI posts a new object to the Graph `applications` endpoint; there is no reference such as `--app-id` or `--object-id` that could select an existing registration for modification. `az ad app update` is the separate, explicit command that mutates an already-registered app, and it would be used with an identifier of the existing application. Here, the sole operation is a POST, so the result cannot be an updated existing registration.

The application is configured with single-tenant sign-in audience

Why wrong: The sign-in audience is determined by the `--sign-in-audience` parameter, and the value shown in the exhibit is `AzureADMultipleOrgs`, which indicates a multi-tenant application that accepts work or school accounts from any Azure AD tenant. A single-tenant configuration would require the value `AzureADMyOrg`, restricting sign-in to users from the home tenant only. Since the exhibit explicitly uses the multi-tenant audience, this option misrepresents the app's tenancy.

An admin consent is granted for the Microsoft Graph permissions

Why wrong: Declaring permissions through `--required-resource-accesses` only creates the permission entries in the app registration; it does not grant admin consent. Admin consent requires a separate step, such as using the Azure portal's 'Grant admin consent' button, calling the `adminconsent` endpoint, or running `az ad app permission admin-consent`. Until that step is taken, the required permissions remain in an unconsented, pre-authorization state even though they are listed on the application.

Microsoft Entra B2B collaboration

Why wrong: Microsoft Entra B2B collaboration is a subset of External identities focused on inviting external business partners to collaborate on your enterprise apps. While it can be configured to accept social identity providers, its purpose is partner access and collaboration, not a general social-sign-in solution. Therefore, it does not match the described scenario as well as External identities.

Managed identities

Why wrong: Managed identities are service principals that Azure resources, such as virtual machines and Azure Functions, use to authenticate to Microsoft Entra-protected APIs and resources. They are machine identities, not user identities, and they cannot be used by end users to sign in with Google or Facebook. This makes them irrelevant to the question.

Microsoft Entra Identity Protection

Why wrong: Microsoft Entra Identity Protection is a risk-detection and automated-response service that analyzes sign-ins and users for threats like impossible travel, leaked credentials, and anomalous behavior. It operates on existing Microsoft Entra identities and does not provide identity federation or connect external social identity providers. Therefore, it is not the feature that supports social identity provider sign-in.

Modify the Conditional Access policy to require MFA for all apps

Why wrong: Modifying the Conditional Access policy to require MFA for all apps would expand the scope of MFA enforcement to every application, so a user would be challenged each time they access an app that does not have an existing session. This increases the number of MFA prompts rather than reducing them, because it does not alter session lifetime or sign-in frequency.

Change the per-user MFA state to Disabled

Why wrong: Changing the per-user MFA state to Disabled is the legacy control that turns off MFA enforcement for that account, leaving it protected only by the password. While this would eliminate MFA prompts, it is a severe security regression and is not a valid solution. Additionally, if MFA is enforced via Conditional Access, this setting has no effect, so prompts would not necessarily stop.

Adjust Identity Protection user risk policy

Why wrong: Adjusting the Identity Protection user risk policy only changes the thresholds for automatically responding to suspicious sign-in attempts, such as blocking access or requiring MFA when risk is high. It does not govern session lifetime or sign-in frequency, so it would not reduce MFA prompts for legitimate user activity. Therefore, it is an unrelated control that cannot solve the problem.

Deploy app protection policies (MAM) for Outlook

Why wrong: Deploying app protection policies (MAM) for Outlook is incorrect because MAM policies operate at the application data layer, not at the device compliance layer. They apply to Outlook both on enrolled devices and unmanaged bring-your-own devices, controlling actions like copy/paste, save-as, and restricting access to corporate data within the app. However, MAM does not evaluate the device's overall compliance status—such as OS patch level, encryption, or threat detection—and it does not block sign-in from a non-compliant device to other applications. It can complement Conditional Access but cannot substitute for the 'Require device to be marked as compliant' control.

Enable Microsoft Entra device registration

Why wrong: Enabling Microsoft Entra device registration is not sufficient because device registration merely creates a device identity in Entra ID and enables capabilities like single sign-on and conditional access. A registered device can be non-compliant—for example, if it is jailbroken, missing updates, or not enrolled in Intune—but registration alone does not evaluate or enforce compliance. While device registration is a necessary prerequisite for Intune enrollment and for the compliance state to be reported to Entra ID, access control still requires a Conditional Access policy that checks and acts on that compliance state.

Create a device compliance policy in Intune

Why wrong: Creating a device compliance policy in Intune is incorrect as the final enforcement step because a compliance policy only defines the requirements and produces a compliance status (compliant/non-compliant) for enrolled devices. It does not itself block access to cloud apps or resources; it merely marks the device with a health state. That compliance status is meaningless for access control unless a Conditional Access policy is configured to consume it, such as by adding the 'Require device to be marked as compliant' grant. So, while a compliance policy is necessary to establish what compliance means, it is not an enforcement point.

Microsoft Identity Manager

Why wrong: Microsoft Identity Manager (MIM) is an on-premises identity management product focused on managing identities, groups, and access workflows within your local Active Directory environment. It lacks the built-in cloud synchronization engine required to automatically provision and sync your on-premises identities to Microsoft Entra ID. While MIM can integrate with sync solutions, it is not the tool Microsoft provides for hybrid directory synchronization.

Microsoft Entra Cloud Sync

Why wrong: Microsoft Entra Cloud Sync is a lightweight agent-based sync solution designed for specific cases such as consolidating multiple disconnected AD forests, not for standard hybrid identity deployments. It does not offer the full set of hybrid capabilities you get with the primary sync engine, including complete device sync, seamless single sign-on, and integrated health monitoring. For a typical hybrid identity implementation, Microsoft Entra Connect is the more appropriate and feature-complete choice.

Microsoft Entra Connect Sync

Why wrong: Microsoft Entra Connect Sync is not a separate product; it is the synchronization engine that runs as a core component inside Microsoft Entra Connect. Using this name often reflects the older Azure AD Connect terminology, but the deployable product that you install and configure for hybrid identity is Microsoft Entra Connect itself. Choosing 'Connect Sync' as an answer would be incorrect because it is merely a component, not the comprehensive tool that includes installation, configuration, and authentication options.

Create a security group for Sales, then assign a custom role to the group

Why wrong: Role assignment to a group applies to all group members, but the scope is not limited to Sales users only.

Create a custom role with password reset permissions and assign it to helpdesk

Why wrong: Without scope, it would apply to all users.

Add helpdesk users to the Global Administrator role

Why wrong: Global Administrator is too broad and not recommended.