Task 2.2: Design solutions for identity and access management

• ANothing, because the all-users policy already covers the agent

  Incorrect

  Policies that target users apply to delegated access; they don't cover an agent that accesses resources with its own identity.

• BA Conditional Access policy that targets the agent identity or its blueprint

  Correct

  In app-only access the agent identity is the token subject, so the policy must target the agent identity or agent identity blueprint.

• CA policy targeting the agent's user account

  Incorrect

  A policy for an agent's user account doesn't apply to the agent identity, and this agent doesn't use a user account.

• DA sign-in frequency control for the employees who built the agent, so their sessions are reevaluated more often

  Incorrect

  The developers' sessions have nothing to do with the agent's own token requests.

Conditional Access evaluates the token subject. In on-behalf-of (delegated) access the signed-in user is the subject and user-targeted policies apply; in application-only access, used by autonomous agents, the agent identity is the subject and policies must target the agent identity or agent identity blueprint; in agent-user access the agent's user account is the subject. A policy targeting one subject doesn't apply to the others.

• AA Conditional Access sign-in frequency of one hour for all users, so that every session is reauthenticated regularly

  Incorrect

  Sign-in frequency forces reauthentication on a schedule; it doesn't react within minutes to account disablement.

• BA Conditional Access policy that blocks legacy authentication protocols for every user

  Incorrect

  Blocking legacy protocols is good practice but doesn't revoke modern sessions faster.

• CCritical event evaluation in continuous access evaluation, which revokes sessions when an account is disabled or its password reset

  Correct

  CAE services subscribe to critical events and enforce them in near real time, without waiting for token expiry.

• DConditional Access location policies enforced in near real time through continuous access evaluation

  Correct

  CAE-capable services enforce network location changes against Conditional Access location policies in near real time.

• EA shorter Microsoft Entra password expiry period, so that departing users' passwords stop working sooner

  Incorrect

  Password expiry doesn't affect existing sessions when an account is disabled.

Continuous access evaluation lets services such as Exchange Online, SharePoint Online and Teams subscribe to critical Microsoft Entra events, such as account disablement or password change or reset, and enforce them in near real time. CAE also enforces Conditional Access location policies in near real time when the network location changes.

• APass-through authentication with three agents on premises, so passwords are validated directly against Active Directory

  Incorrect

  PTA validates each sign-in against on-premises AD, so it depends on the datacenter being reachable.

• BFederation with AD FS in the on-premises datacenter

  Incorrect

  Federation adds the most infrastructure and depends on the on-premises farm.

• CPassword hash synchronization, with seamless SSO where devices can't be Entra joined

  Correct

  PHS needs the least infrastructure, doesn't depend on on-premises servers at sign-in, and is what ID Protection uses for leaked credentials.

• DCloud-only accounts created by hand for every user

  Incorrect

  Separate cloud accounts break the hybrid identity and add work.

Password hash synchronization is the simplest way to enable cloud authentication for on-premises objects and requires the least deployment and maintenance effort. ID Protection requires PHS for the leaked credentials report, whatever the sign-in method. Pass-through authentication and federation depend on on-premises components at sign-in.

• AExclude the partner's guests from the MFA policy

  Incorrect

  Exclusion removes the MFA requirement instead of accepting the partner's MFA.

• BConvert the guests to member users in your tenant

  Incorrect

  Changing user type doesn't remove the need for MFA registration in your tenant.

• CAllow the guests to use SMS-based codes only

  Incorrect

  That lowers assurance and still makes them register in your tenant.

• DConfigure the inbound trust settings for that partner to trust MFA from its tenant

  Correct

  Inbound trust settings let your Conditional Access policies accept MFA the user already performed in the home tenant.

Cross-tenant access settings include inbound trust settings that determine whether your Conditional Access policies trust MFA, compliant device and Microsoft Entra hybrid joined device claims from an external organization. When MFA is trusted, your MFA policies still apply, but users who completed MFA in their home tenant aren't prompted again.

• AProtected actions that assign a Conditional Access authentication context to those permissions

  Correct

  Protected actions attach Conditional Access policies to specific permissions, so the stronger requirement applies when the action is performed.

• BA Conditional Access policy requiring phishing-resistant MFA for every sign-in by these admins

  Incorrect

  That raises every sign-in rather than the specific action, and doesn't step up within an existing session.

• CA PIM activation requirement for the Conditional Access Administrator role

  Incorrect

  PIM governs role activation, not each policy change after activation.

• DA custom role that removes the permission to delete policies

  Incorrect

  Removing the permission blocks the work instead of protecting it.

Protected actions in Microsoft Entra ID are permissions that have Conditional Access policies assigned through an authentication context. When a user tries to perform a protected action, such as creating or updating Conditional Access policies, they must first satisfy those policies, for example phishing-resistant MFA.

• AA full Microsoft Entra Connect Sync server

  Incorrect

  Connect Sync is the other synchronization engine, which organizations migrate from; Cloud Sync doesn't run it.

• BA lightweight provisioning agent that needs only outbound connections

  Correct

  Cloud Sync uses the Microsoft Entra provisioning agent, which connects outbound and updates automatically.

• CAn AD FS farm with web application proxies in the perimeter network

  Incorrect

  Federation servers aren't part of Cloud Sync.

• DNothing; the cloud service reads AD directly over the internet

  Incorrect

  An on-premises agent bridges AD and Entra ID.

Microsoft Entra Cloud Sync uses the Microsoft Entra provisioning agent, a lightweight on-premises agent that acts as a secure bridge between Active Directory and Microsoft Entra ID, needs only outbound connections and gets automatic updates from the cloud. Several agents can run on different servers for automatic failover.

• ADecentralized identifiers and verifiable credentials

  Correct

  Verified ID is based on DIDs and verifiable credentials standards.

• BKerberos tickets and domain trusts

  Incorrect

  Those are Active Directory constructs.

• CSAML assertions issued by AD FS

  Incorrect

  Federation tokens aren't decentralized identity.

• DShared API keys that each verifier stores and exchanges with the issuer

  Incorrect

  Shared keys aren't part of decentralized identity.

Decentralized identity in Microsoft Entra Verified ID uses decentralized identifiers and verifiable credentials, so users hold credentials in a wallet and present them to verifiers.

• ATemporary Access Pass

  Incorrect

  A Temporary Access Pass is a time-limited passcode for onboarding or recovery.

• BNumber matching

  Correct

  Number matching asks users to enter the number displayed at sign-in.

• CSelf-service password reset

  Incorrect

  SSPR lets users reset their own password.

• DPassword writeback

  Incorrect

  Writeback syncs password changes to on-premises AD.

Number matching in Microsoft Authenticator push notifications requires users to enter the number displayed on the sign-in screen, which helps prevent accidental approvals in MFA fatigue attacks.

• AMFA, passwordless MFA and phishing-resistant MFA

  Correct

  These are the three built-in authentication strengths.

• BPassword only, SMS only and email only

  Incorrect

  These aren't authentication strengths.

• CLow, medium and high sign-in risk

  Incorrect

  Those are risk levels.

• DCompliant device, Microsoft Entra hybrid joined device and approved client app

  Incorrect

  Those are other grant controls.

Conditional Access offers three built-in authentication strengths, multifactor authentication strength, passwordless MFA strength and phishing-resistant MFA strength, and you can create custom strengths.