Which Users Can Sign In to AD DS-Joined AVD Hosts?
Short answer
A Only User1 can sign in because the session hosts are joined to the on-premises AD DS domain, which does not contain cloud-only or guest users.
Question
Your on-premises network contains an Active Directory Domain Services (AD DS) domain named contoso.com. You have an Azure subscription that is linked to a Microsoft Entra tenant named contoso.onmicrosoft.com. Contoso.com syncs with contoso.onmicrosoft.com. You have a partner company that has a Microsoft Entra tenant named fabrikam.com. Contoso.onmicrosoft.com contains the resources shown in the following table. You deploy an Azure Virtual Desktop host pool named Pool1. Pool1 contains 10 session hosts that are joined to Contoso.com. You assign Group1 to the application group in Pool1. You need to identify which users will be able to sign in to the session hosts in Pool1. Which users should you identify? - 
Key Takeaways
AVD session hosts joined to an AD DS domain require users to exist in the on-premises AD DS, meaning cloud-only users in the synced tenant cannot authenticate.
For Azure Virtual Desktop session hosts domain-joined to an on-premises AD DS domain, only users synchronized from that AD DS can authenticate. This page confirms that cloud-only and guest users cannot sign in to AD DS-joined hosts.
Common mistake: Choosing User1 and User2 (Option B), assuming that any user in the Microsoft Entra tenant can sign in to a session host joined to the corresponding on-premises AD DS domain.
Expert Analysis
Why the Answer Is Correct
The session hosts in Pool1 are explicitly joined to the on-premises Active Directory Domain Services (AD DS) domaincontoso.com. To authenticate to an AD DS domain-joined machine, a user principal must exist within that on-premises directory. User1 is synchronized from contoso.com to contoso.onmicrosoft.com, meaning User1 has an account in the on-premises AD DS and can successfully authenticate to the session hosts.Why the Other Options Are Wrong
User3 is a guest user fromfabrikam.com and does not have an account in the contoso.com domain, making Options C and D incorrect. User2 is a cloud-only user within contoso.onmicrosoft.com; because it is not synchronized from the on-premises AD DS, it has no corresponding account in contoso.com and cannot authenticate to the domain-joined session hosts, making Option B incorrect. As ClintC03 noted, "The on-prem domain would know nothing of a cloud-only account".Community Comment Notes
The community correctly identifies that AD DS domain-joined hosts only recognize synced users, with belyo pointing out "user 2 cannot as its not synced". However, some users like Korro incorrectly assume that cloud-only users in the same tenant can authenticate, failing to recognize the boundary of an on-premises domain-joined machine which requires local AD DS presence.Official Reference
Exam Strategy
When evaluating AVD sign-in capabilities, always check the domain join type of the session hosts. If hosts are AD DS domain-joined, only users present in that on-premises AD DS (synced users) can sign in; cloud-only users require Microsoft Entra ID-joined or Microsoft Entra Domain Services-joined hosts.
Community Votes
62% of anonymous learners picked answer A. Votes are pick records left by other test-takers — they are not the verified answer.
Discussion 7 contributions
Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded.
From public community threads 7
-
Korro 👍 2 Answered BIt's either A or B in my opinion as: User1 -> works as the user is available in contoso.com and contoso.onmicrosoft.com due to the sync User2 -> is available in contoso.onmicrosoft.com but the Hosts are Domain joined just to contoso.com User3 -> is out in my opinion as it is only a Guest User https://learn.microsoft.com/en-us/azure/virtual-desktop/authentication https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/scenarios/azure-virtual-desktop/eslz-identity-and-access-management 2nd link would say the following setup is supported Identity scenario Session hosts User accounts Microsoft Entra ID + AD DS Joined to AD DS In Microsoft Entra ID and AD DS, synchronized Microsoft Entra ID + AD DS Joined to Microsoft Entra ID In Microsoft Entra ID and AD DS, synchronized so I put my money on B
-
sKostas 👍 2 Answered AI tried to my environment and it feeds the resources to the Remote desktop app but the user cannot connect.
-
hwoccurrence 👍 1 Answered BSince Pool1’s session hosts are joined to “contoso.com,” which is synchronized with the same “contoso.onmicrosoft.com” tenant, any user in that tenant can sign on—whether they originate on‐prem (synced) or are purely cloud‐only in the same Azure AD tenant. However, User 3 is a guest from a different tenant (“fabrikam.com”) and thus has no corresponding account in the “contoso.com” domain.
-
Roee1 👍 1 Answered AIts A acording to Chat Gpt. The hosts are domain joined to the on premises AD DS so i only recognizes the users in the on permises active directory or the users that are synced to it, and since user 2 is a cloud only user, the host will not recognize it.
-
belyo 👍 1 Answered Aaccording to this https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/scenarios/azure-virtual-desktop/eslz-identity-and-access-management#supported-identity-scenarios user 2 cannot as its not synced
Show 2 more comments
-
ClintC03 👍 1 Answered AThe on-prem domain would know nothing of a cloud-only account so it has to be A.
-
soysoliscarlos 👍 1Its A. the only user domain joined is user 1
Reader comments & corrections
No reader corrections yet — spotted an error or have a note? Share it below.
Related Analysis
Practice All AZ-140 Questions
Access 64 questions with complete answers and detailed explanations.
View Full AZ-140 Practice Test →