Microsoft AZ-800 Online Access

The Administering Windows Server Hybrid Core Infrastructure materials explain that Azure AD Password Protection for on-premises AD uses two components: the DC agent and the proxy service. The DC agent is installed on every domain controller because it “intercepts password set/change operations locally on the DC and evaluates them against the forbidden-password policy.” The guidance further states that to ensure consistent enforcement “the DC agent should be deployed to all DCs in the forest, since password changes may occur on any DC.” The proxy service is installed on member servers (not necessarily DCs) and “relays policy downloads and telemetry to Azure AD on behalf of DCs,” which satisfies environments where “domain controllers must not directly contact Internet endpoints.” Finally, configuration of the global and custom banned password lists is performed in Azure AD, where administrators “define tenant-wide custom banned terms; DCs obtain the policy via the proxy and cache it for local enforcement.”

Given Fabrikam’s requirement to prevent DCs from accessing the Internet, the proxy must run on non-DC servers (VM1 and VM2). To guarantee enforcement wherever a password is changed, the DC agent must be on all domain controllers. The custom banned password list is configured in the Azure AD tenant and then distributed to on-premises DCs via the proxy.

In Administering Windows Server Hybrid Core Infrastructure, Microsoft states that high availability for DHCP on Windows Server is achieved by using DHCP failover rather than the legacy split-scope (80/20) model. The guidance explains that DHCP failover “synchronizes lease data between two DHCP servers and can be configured in Load Balance or Hot Standby mode on a per-scope basis,” and that you enable it on each DHCP scope to create a partner relationship that automatically replicates scope configuration and active leases. This meets the requirement to keep address assignment available if one DHCP server is down.

The same materials further note that DHCP broadcasts do not traverse routers; therefore, when the partner server is reachable across a routed boundary (another site/subnet), you must configure the router as a DHCP relay (IP helper) to forward DHCPDISCOVER messages to the remote DHCP server(s). The text emphasizes: “When clients and DHCP servers are on different subnets, configure a relay agent on the router to forward requests to the DHCP server IP addresses.”

Applying this to Fabrikam: create DHCP failover between DHCP1 (Scope1) and DHCP2 (Scope2) (E) and configure the routers in New York and Seattle as DHCP relays that forward to both DHCP servers (B). You do not use Failover Clustering for DHCP here, and you do not create extra 25% scopes; those are split-scope practices superseded by DHCP failover.

The exam materials explain that to add a new domain controller to an existing AD DS forest in Azure, you deploy a Windows Server IaaS VM and then promote it: “To extend on-premises AD DS into Azure, provision a Windows Server VM in Azure and run AD DS to create an additional domain controller for the existing domain.” Conversely, Azure Active Directory Domain Services (Azure AD DS) provides a managed domain that is separate from and not writable by your on-premises administrators—you “do not get domain admin rights or access to DCs”—so it cannot be used to add a DC (dc3.corp.fabrikam.com) to the existing corp.fabrikam.com forest. Azure AD Application Proxy and Azure AD administrative units are unrelated to deploying DCs. Therefore, the correct implementation is to deploy an Azure virtual machine in Vnet1, install AD DS/DNS, and promote it to become DC3 in the existing domain.

In the Administering Windows Server Hybrid Core Infrastructure guidance for extending AD DS into Azure, Microsoft states that when you place a domain controller in an Azure virtual network you must run DNS on that domain controller and point the VNet to that DNS server: “Domain controllers in Azure IaaS should host the AD-integrated DNS zone, and the virtual network’s DNS server setting must reference those DC/DNS IPs so Azure VMs use AD DNS rather than the Azure-provided resolver.” The materials also emphasize that Azure’s default DNS cannot host or manage AD DS zones, so custom DNS is required for domain-joined workloads. Therefore, to meet the requirement you (1) install the DNS Server role on DC3 so it can host the corp.fabrikam.com AD-integrated zone (F), and (2) configure the DNS Servers setting on Vnet1 to the IP of DC3 (and any additional DCs), ensuring all Azure VMs in Vnet1 resolve the domain via AD DNS (D). Creating a public Azure DNS zone or a Private DNS zone with the same AD name is not appropriate for AD-integrated name resolution. This design also supports the security requirement of preventing domain controllers from relying on Internet-facing resolvers.