Pass the Microsoft Certified: Windows Server Hybrid Administrator Associate AZ-802 Questions and answers with ExamsMirror

DHCP1 (New York, Scope1) and DHCP2 (Seattle, Scope2) currently serve only their own local office. To make DHCP highly available across both offices, the modern, supported approach is DHCP Failover, configured per scope (option E), which replicates lease information between DHCP1 and DHCP2 in either load-balance or hot-standby mode so that either server can service either scope ' s clients if its partner becomes unavailable. However, DHCP Failover alone only helps if a client ' s DHCP broadcast can actually reach the surviving partner server across the WAN; broadcasts do not cross routed office boundaries on their own. Configuring a DHCP relay agent on the router (or another relay-capable device) in each office (option B) forwards DHCPDISCOVER broadcasts from local clients to the remote partner server whenever the local DHCP server is down, allowing failover to actually take effect for clients in either office. The legacy split-scope technique of manually carving off a percentage of the other scope ' s addresses (options A and C) is the older, pre-failover workaround and is unnecessary once DHCP Failover is used; there is also no DHCP cluster role delivered through Windows Failover Clustering (option D), since DHCP achieves high availability through Failover mode, not a clustered role.

1. Create the KDS root key in AD DS. 2. Create a group managed service account (gMSA) in Active Directory. 3. Configure the IIS application pool (on WEB1 and WEB2) to run as the gMSA via a specified user account.

The requirement is that every instance of Webapp1 (running on both WEB1 and WEB2) uses the same identity, and that identity ' s password rotates automatically every 30 days, without any administrator manually resetting it. A standalone managed service account (sMSA) is tied to a single computer and cannot be shared across WEB1 and WEB2, so it does not meet the requirement. A group managed service account (gMSA) is designed exactly for this scenario: one AD-managed identity that multiple servers can use simultaneously, with the Key Distribution Service automatically rotating its password (by default every 30 days) without needing manual intervention or downtime. Before any gMSA can be created in the forest, a one-time prerequisite must exist: the KDS root key, which the Key Distribution Service uses to generate and later recompute the gMSA ' s password material. So the correct order is to first create the KDS root key, then create the gMSA object in Active Directory, and finally configure the IIS application pool on each web server to run as that gMSA using the " specified user account " identity option (entered as domain\gMSA$ with no password required, since the password is centrally managed). Creating a system- or user-assigned managed identity in Microsoft Entra ID does not apply here, since Webapp1 runs on IIS on domain-joined VMs, not as an Azure PaaS resource.