Browse Certification Practice Tests by Exam Family

Microsoft AZ-802: Deploy and Manage AD DS in Hybrid Environments

Try 10 focused Microsoft AZ-802 questions on Deploy and Manage AD DS in Hybrid Environments, with explanations, then continue with IT Mastery.

Open the matching IT Mastery practice page for timed mocks, topic drills, progress tracking, explanations, and full practice.

Try Microsoft AZ-802 on Web View full Microsoft AZ-802 practice page

Topic snapshot

FieldDetail
Exam routeMicrosoft AZ-802
Topic areaDeploy and Manage AD DS in Hybrid Environments
Blueprint weight16.5%
Page purposeFocused sample questions before returning to mixed practice

How to use this topic drill

Use this page to isolate Deploy and Manage AD DS in Hybrid Environments for Microsoft AZ-802. Work through the 10 questions first, then review the explanations and return to mixed practice in IT Mastery.

PassWhat to doWhat to record
First attemptAnswer without checking the explanation first.The fact, rule, calculation, or judgment point that controlled your answer.
ReviewRead the explanation even when you were correct.Why the best answer is stronger than the closest distractor.
RepairRepeat only missed or uncertain items after a short break.The pattern behind misses, not the answer letter.
TransferReturn to mixed practice once the topic feels stable.Whether the same skill holds up when the topic is no longer obvious.

Blueprint context: 16.5% of the practice outline. A focused topic score can overstate readiness if you recognize the pattern too quickly, so use it as repair work before timed mixed sets.

Sample questions

These questions are original IT Mastery practice items aligned to this topic area. They are designed for self-assessment and are not official exam questions.

Question 1

Topic: Deploy and Manage AD DS in Hybrid Environments

An IIS application pool on WEB1 and WEB2 is configured to run as the gMSA CONTOSO\gmsa-IIS$. The SPN HTTP/hr.contoso.com is already registered to the gMSA. The app works on WEB1 but fails to start on WEB2; Test-ADServiceAccount gmsa-IIS returns False on WEB2 with a managed password retrieval permission error. What should you configure?

Options:

  • A. Add gmsa-IIS$ to local Administrators.

  • B. Register HTTP/hr.contoso.com on WEB2$.

  • C. Convert the gMSA to a standalone MSA.

  • D. Authorize WEB2$ to retrieve the gMSA password.

Best answer: D

Explanation: Group managed service accounts use AD DS to manage the password, but each host must be authorized to retrieve that password. Because the SPN is already registered to the gMSA and the failure occurs only on WEB2, the clue is not duplicate SPN registration or delegation. The failed Test-ADServiceAccount result and managed password retrieval error point to the gMSA’s allowed principals configuration. Add the WEB2 computer account, or preferably a security group containing the approved web servers, to the gMSA’s password retrieval authorization and refresh the server’s membership as needed. Local admin membership does not grant AD permission to retrieve a gMSA password.

  • SPN on server fails because the HTTP SPN should be on the service account that accepts Kerberos tickets, not the computer account in this case.
  • Local Administrators fails because local rights do not authorize managed password retrieval from AD DS.
  • Standalone MSA fails because an sMSA is intended for one computer and does not fit the two-server IIS requirement.

Question 2

Topic: Deploy and Manage AD DS in Hybrid Environments

A hybrid administrator reviews Microsoft Entra Connect Health after several cloud apps stop showing users from the Sales department. On-premises AD DS still contains the Sales users.

Exhibit: Connect Health summary

SignalEvidence
Sync healthExport to Microsoft Entra ID stopped
Alert detailstopped-deletion-threshold-exceeded
Pending export8,200 deletes to Microsoft Entra ID
Recent changeOU=Sales removed from sync scope

What is the most likely root cause?

Options:

  • A. An AD FS token-signing certificate expired

  • B. AD DS replication failed for the Sales OU

  • C. A sync scope change staged unintended deletions

  • D. Password hash synchronization stopped running

Best answer: C

Explanation: Microsoft Entra Connect Health evidence points to a synchronization export protection issue, not an authentication outage. The key signals are the large number of pending deletes, the stopped-deletion-threshold-exceeded alert, and the recent removal of OU=Sales from the sync scope. Microsoft Entra Connect Sync stages deletes when in-scope objects become out of scope, even if the objects still exist in on-premises AD DS. The deletion threshold prevents accidental mass deletion from being exported to Microsoft Entra ID. The next investigation should validate the sync rule or OU filtering change before disabling the threshold or forcing export.

  • Replication failure does not fit because the users still exist on-premises and the evidence shows staged cloud deletes.
  • Password hash sync would affect credential synchronization, not generate thousands of pending object deletions.
  • AD FS certificate expiry would cause federated authentication failures, not a Connect Health deletion-threshold alert.

Question 3

Topic: Deploy and Manage AD DS in Hybrid Environments

A company hosts a legacy Windows service on two domain-joined Windows Server VMs in Azure behind a load balancer. The VMs use AD DS over a site-to-site VPN. The service currently runs under one domain user account with a password stored in the service configuration. You need automatic password management and the same service identity on both nodes. Which design is the best fit?

Options:

  • A. Create one standalone managed service account for each VM.

  • B. Create a gMSA and allow a server group to retrieve its password.

  • C. Use Windows LAPS to rotate a shared local service account.

  • D. Create a Microsoft Entra app registration for the Windows service.

Best answer: B

Explanation: A group managed service account (gMSA) is designed for domain-joined workloads that need safer credential handling across multiple servers, such as a load-balanced Windows service. AD DS manages the gMSA password and only authorized computer accounts can retrieve it, typically by granting access to a security group containing the service hosts. The service is then configured to run as the gMSA account, using the trailing $ account name and no manually stored password. A standalone managed service account is limited to one computer, so it does not fit a two-node service using the same identity.

  • Standalone MSA fails because it is intended for a single computer, not a shared identity across load-balanced servers.
  • Windows LAPS manages local administrator passwords; it does not provide a domain service identity for an application workload.
  • App registration is useful for Microsoft Entra-integrated applications, but it does not replace an AD DS service logon identity for a Windows service.

Question 4

Topic: Deploy and Manage AD DS in Hybrid Environments

A company is moving legacy Windows Server application VMs to Azure. The applications require domain join, Kerberos authentication, and LDAP queries for user accounts already synchronized to Microsoft Entra ID. The security team requires a private design and does not want administrators to deploy or patch domain controllers in Azure. Which design is the best fit?

Options:

  • A. Use Microsoft Entra Domain Services in the app network

  • B. Join the servers directly to Microsoft Entra ID

  • C. Deploy writable AD DS domain controllers on Azure VMs

  • D. Use Microsoft Entra Connect Cloud Sync only

Best answer: A

Explanation: Microsoft Entra Domain Services is the best fit when Azure workloads need traditional managed domain services but the organization does not want to deploy or operate domain controllers. It provides a managed domain with domain join, Kerberos/NTLM authentication, LDAP, and Group Policy support for workloads in a virtual network. For synchronized hybrid users, identity data comes from Microsoft Entra ID, and the workload VMs use the managed domain’s DNS endpoints. Keeping the service in a private Azure network also aligns with the secure connectivity constraint.

Direct Microsoft Entra ID join does not provide the same LDAP/domain-join behavior for legacy server workloads. Deploying AD DS on Azure VMs would meet the protocol needs but violates the no-domain-controller constraint.

  • Direct Entra join fails because it does not replace AD DS-style LDAP and managed domain join for legacy Windows Server workloads.
  • Azure VM domain controllers provide AD DS but require administrators to deploy, secure, patch, and recover domain controllers.
  • Cloud Sync only synchronizes identities but does not provide Kerberos, LDAP, or domain-join services.

Question 5

Topic: Deploy and Manage AD DS in Hybrid Environments

A company uses Microsoft Entra Connect Sync on a server in the Hub AD DS site. Password changes made in a Branch site are not reaching the Hub site, but users can still sign in locally at the branch.

Exhibit:

repadmin /showrepl HUB-DC01
  Source DSA: BRANCH-DC02
  Last error: 8524 - DNS lookup failure

Test-NetConnection BRANCH-DC02 -Port 135: Succeeded
Site link HUB-BRANCH schedule: Open now
DCDIAG /test:dns on BRANCH-DC02:
  Missing _ldap._tcp.dc._msdcs.contoso.com SRV record

Which action is the best design fit to restore AD DS replication?

Options:

  • A. Install another Microsoft Entra Connect Sync server.

  • B. Transfer the PDC emulator role to HUB-DC01.

  • C. Repair DC DNS registration for the _msdcs records.

  • D. Extend the HUB-BRANCH site link schedule.

Best answer: C

Explanation: AD DS replication depends on domain controller DNS records, especially SRV records under _msdcs, to locate replication partners. In this scenario, the key clue is 8524 - DNS lookup failure; the port test shows basic network connectivity is working, and the site link schedule is currently open. The missing _ldap._tcp.dc._msdcs.contoso.com SRV record means the hub DC cannot reliably locate the branch DC as a directory service endpoint. The appropriate fix is to repair AD-integrated DNS registration and replication for the relevant zone, then force or wait for DC registration, such as by restarting Netlogon or running DNS registration commands as appropriate. Changing FSMO roles or adding sync servers does not address the AD DS replication locator failure.

  • FSMO transfer does not fix a missing DC locator SRV record or a DNS-based replication failure.
  • Schedule extension is unnecessary because the site link is already open when the failure occurs.
  • Additional sync server would not help because the upstream AD DS replication path remains broken.

Question 6

Topic: Deploy and Manage AD DS in Hybrid Environments

After a merger, Fabrikam wants users from any domain in the Contoso forest to access file shares in the Fabrikam forest. DNS name resolution succeeds in both directions. Users from sales.contoso.com can access \\fs1.fabrikam.local\data, but users from corp.contoso.com receive access denied.

Exhibit: Trust validation

Trust partner: sales.contoso.com
Trust type: External
Direction: Bidirectional
Transitive: No
Selective authentication: Disabled

What is the best root cause?

Options:

  • A. AD DS replication failed between forests.

  • B. The trust should be a bidirectional forest trust.

  • C. Conditional DNS forwarders are missing.

  • D. Selective authentication is blocking access.

Best answer: B

Explanation: The evidence points to a trust-scope problem, not name resolution or replication. An external trust is a nontransitive trust between two domains. It can allow access between sales.contoso.com and fabrikam.local, but it does not extend to other domains in the Contoso forest such as corp.contoso.com. For cross-forest access after a merger, when users from multiple domains in one forest need access to resources in another forest, a forest trust between the forest root domains is the appropriate configuration. The trust direction must also align with the access requirement; in this scenario, bidirectional access is stated in the exhibit and requirement.

  • DNS forwarding is not the issue because the scenario states that name resolution already succeeds in both directions.
  • Selective authentication is not blocking access because it is disabled in the displayed trust configuration.
  • Inter-forest replication is not expected for separate AD DS forests; trusts do not create AD DS replication between forests.

Question 7

Topic: Deploy and Manage AD DS in Hybrid Environments

A manufacturing site runs an application that performs LDAP updates against AD DS during production. The site has an RODC deployed because the WAN link to the hub datacenter is unreliable. During a WAN outage, users with cached credentials can sign in, but the application fails all directory write operations and password changes cannot be processed locally. What is the most likely root cause?

Options:

  • A. The site needs a writable domain controller

  • B. The RODC is missing the global catalog role

  • C. The application requires Microsoft Entra Connect Sync

  • D. The site needs Microsoft Entra Domain Services

Best answer: A

Explanation: The deployment pattern does not match the site requirement. An RODC is appropriate for branch offices with limited physical security or mostly read/authentication needs, especially when cached credentials are enough during WAN outages. It is not appropriate when the site must continue performing AD DS write operations while disconnected. Directory writes, password changes, and similar update operations require a writable domain controller. For an isolated or WAN-unreliable site that must perform local AD DS writes, deploy a writable domain controller and secure it appropriately, rather than relying on an RODC.

  • Global catalog helps with forest-wide lookups and logon in multi-domain forests, but it does not make an RODC writable.
  • Microsoft Entra Domain Services provides managed domain services in Azure, not an offline write-capable DC for this on-premises site.
  • Microsoft Entra Connect Sync synchronizes identities with Microsoft Entra ID; it does not enable local AD DS writes on an RODC.

Question 8

Topic: Deploy and Manage AD DS in Hybrid Environments

A company is reviewing AD DS deployment for a branch office. During WAN outages, branch users cannot authenticate to domain resources unless they already have cached sign-in data. A security assessment also warns that the branch server closet is shared with contractors, so theft of a writable domain controller would create unacceptable credential exposure. Which deployment action best addresses the symptom and the warning?

Options:

  • A. Deploy a writable domain controller in the branch

  • B. Increase cached interactive logons on branch computers

  • C. Deploy an RODC with a scoped Password Replication Policy

  • D. Deploy Microsoft Entra Domain Services for the branch

Best answer: C

Explanation: A read-only domain controller (RODC) is designed for branch offices where physical security is weaker or WAN connectivity is unreliable. It can service local authentication and directory lookup requests, but it does not hold writable copies of AD DS data. Its Password Replication Policy controls which user or computer credentials may be cached locally, reducing the impact if the server is stolen. For this scenario, the key evidence is the combination of intermittent WAN authentication problems and unacceptable exposure from placing a writable domain controller in an insecure location. A writable DC improves local authentication but increases risk; cached logon changes do not provide full domain-controller capability.

  • Writable DC risk fails because it would place a full writable copy of AD DS credentials in a physically insecure branch.
  • Managed domain mismatch fails because Microsoft Entra Domain Services is not a branch-office replacement for deploying an on-premises AD DS domain controller.
  • Cached logons only fails because it does not provide local domain authentication for resources during WAN outages.

Question 9

Topic: Deploy and Manage AD DS in Hybrid Environments

A company moved an IIS application to a domain-joined Windows Server VM in Azure. The app pool runs as CONTOSO\gmsaWeb$, and SQL access uses Kerberos constrained delegation. Users receive 401 errors when browsing https://app.contoso.com. You need to restore authentication while preserving least privilege.

Exhibit:

setspn -Q HTTP/app.contoso.com
  CN=svcOldWeb,OU=Service Accounts,DC=contoso,DC=com

Get-ADServiceAccount gmsaWeb -Properties ServicePrincipalNames
  ServicePrincipalNames: { }

IIS-gMSA-Hosts members:
  WEB01$

Options:

  • A. Add gmsaWeb$ to Domain Admins

  • B. Enable unconstrained delegation for WEB01

  • C. Move the HTTP SPN to gmsaWeb$

  • D. Add WEB01$ to IIS-gMSA-Hosts

Best answer: C

Explanation: Kerberos service authentication depends on the SPN being registered to the security principal that runs the service. In this scenario, the IIS app pool runs as the gMSA, and the host is already allowed to retrieve the gMSA password. The blocking clue is that HTTP/app.contoso.com still belongs to svcOldWeb, while gmsaWeb$ has no HTTP SPN. Registering the HTTP SPN on the gMSA, after removing it from the old account, aligns the service identity with Kerberos tickets and keeps the existing constrained delegation model intact. The issue is not fixed by broadening privileges or changing to less secure delegation.

  • Privilege escalation fails because Domain Admins membership does not correct a mismatched SPN and violates least privilege.
  • Unconstrained delegation is unnecessary and weaker than the existing constrained delegation design.
  • Host membership is already satisfied because WEB01$ is listed in the gMSA host group.

Question 10

Topic: Deploy and Manage AD DS in Hybrid Environments

A company uses AD DS with Microsoft Entra Connect Sync and federates the contoso.com domain with AD FS. The identity team wants to pilot cloud authentication for 50 users before changing the whole domain. The pilot must be group-based, reversible, and provide seamless sign-in from domain-joined Windows devices. Which design is the best fit?

Options:

  • A. Create a new AD FS relying party trust for the pilot group only.

  • B. Deploy Microsoft Entra Domain Services and join the pilot devices to the managed domain.

  • C. Enable password hash sync, enable staged rollout for PHS and Seamless SSO, and add a pilot group.

  • D. Convert contoso.com from federated to managed, then add the pilot users to a group.

Best answer: C

Explanation: Microsoft Entra staged rollout is designed for gradual migration from federated authentication to cloud authentication. In this scenario, the domain can remain federated while selected users are targeted through a pilot group for password hash sync authentication. Enabling Seamless SSO supports silent sign-in from domain-joined Windows devices when the network and browser configuration support it. This lets administrators validate the new authentication path and remove users from the staged rollout group if rollback is needed.

Converting the entire domain to managed authentication is a later cutover step, not a pilot design. Microsoft Entra Domain Services and AD FS trust changes do not provide the staged, group-targeted cloud authentication migration required here.

  • Whole-domain conversion fails because it changes authentication for all users instead of piloting selected users.
  • Managed domain deployment fails because Microsoft Entra Domain Services is not used to migrate federated sign-in to cloud authentication.
  • AD FS trust changes fail because staged rollout is configured in Microsoft Entra ID, not by creating a separate AD FS relying party for pilot users.

Continue with full practice

Use the Microsoft AZ-802 Practice Test page for the full IT Mastery practice bank, mixed-topic practice, timed mock exams, explanations, and web/mobile app access.

Try Microsoft AZ-802 on Web View Microsoft AZ-802 Practice Test

Free review resource

Read the Microsoft AZ-802 Cheat Sheet for compact concept review before returning to timed practice.

Revised on Monday, May 25, 2026