AZ-104 Practice Question 31: SSPR Password Writeback
Microsoft Azure Administrator Associate (AZ-104) · Test 4 · question 1 of 10
Contoso synchronises its on-premises Active Directory to Microsoft Entra ID with password hash synchronisation. You enable self-service password reset for a pilot group and confirm the users have each registered two authentication methods.
Cloud-only accounts in the pilot reset their passwords without any trouble. Every synchronised user who tries is told to contact their administrator instead. What should you do?
Show answer and explanation
Answer:
Where a user's password lives decides whether SSPR can change it. Microsoft Entra ID "checks to see if the user's password is managed on-premises, such as if the Microsoft Entra tenant is using federated, pass-through authentication, or password hash synchronization." From there the rule is explicit: "If SSPR writeback is configured and the user's password is managed on-premises, the user is allowed to proceed to authenticate and reset their password. If SSPR writeback isn't deployed and the user's password is managed on-premises, the user is asked to contact their administrator to reset their password." That is precisely the message the pilot users see.
Option A addresses a different failure. Users who haven't registered enough methods "see an error page when they try to use SSPR", but the stem says both methods are registered, and the cloud-only users under the same policy succeed.
Option C makes things worse, not better. Accounts holding an Azure administrator role have the strong two-gate policy enforced and lose access to some methods; granting privileged roles to solve a password-reset problem is also indefensible on its own.
Option D swaps one on-premises-managed sign-in method for another. Federated users are in exactly the same position; their password still lives in Active Directory, so writeback is still required.
Reference: How self-service password reset works in Microsoft Entra ID