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

Live migration of a clustered, highly available Hyper-V virtual machine requires that every node able to host the VM can access its storage simultaneously and consistently while the VM ' s ownership moves between nodes, without dismounting or remounting a drive letter mid-migration. Cluster Shared Volumes (CSV) is the Failover Clustering feature purpose-built for exactly this: a CSV presents the same clustered disk as a consistent, simultaneously read/write-accessible namespace (under C:\ClusterStorage) to every node in the cluster at once, which is what allows a running VM to move between hosts via live migration without any storage handoff delay or downtime. A traditional clustered disk resource (without CSV) can only be owned and mounted by one node at a time, which would force a storage ownership transfer as part of any migration and break the near-zero-downtime expectation of live migration. A storage pool is a Storage Spaces construct for aggregating physical disks into a pool from which virtual disks are created; it does not, by itself, provide the concurrent multi-node access CSV provides, and using it here would still need to sit under a CSV to support live migration. DFS Replication is a file-replication technology for keeping copies of files in sync across servers, not a shared-access clustering mechanism, and mirrored volumes are a basic/dynamic-disk RAID construct unrelated to failover clustering. Cluster Shared Volumes is therefore the correct configuration.

Self-updating mode runs Cluster-Aware Updating as a highly available clustered role that is hosted directly on the cluster it is updating, which means the Cluster-Aware Updating clustered role and the Failover Clustering Tools it depends on must be installed on the cluster ' s own member nodes, which in this scenario are Node1 and Node2, since self-updating mode has no external coordinating computer and instead runs the update orchestration from within the cluster itself. Remote-updating mode works in the opposite way architecturally: it specifically requires that the computer coordinating and triggering the update run NOT be a member of the failover cluster being updated, so in this scenario the Failover Clustering Tools must instead be installed on Server1, which is an independent member server that has network connectivity to Cluster1 but is not one of its nodes, so it can safely coordinate updates against the cluster from the outside. This architectural split, tools on the cluster ' s own nodes for self-updating mode versus tools on an external, non-member computer for remote-updating mode, reflects the fundamental difference in where the update orchestration engine actually runs between the two CAU modes as documented by Microsoft, and it is what determines the correct answer for each half of this question.

The infrastructure master ' s job is to periodically compare its domain ' s phantom records (placeholder stubs created for objects, such as group members, referenced from other domains) against the full, current data held by a global catalog, and to update any phantom found to be stale, which is how cross-domain object references stay current; this comparison only produces useful updates when the infrastructure master itself is NOT a global catalog server, because a domain controller that is also a global catalog already holds a complete, up-to-date replica of every object in the forest and therefore never perceives any of its own phantoms as stale, silently skipping updates that a non-GC infrastructure master would have caught and propagated. In this forest, DC1 holds the infrastructure master role for contoso.com and is also a global catalog server, which is precisely the unsupported combination (permitted only in a single-domain forest or when every DC in the domain is a GC, neither of which applies here) that causes exactly the symptom described: cross-domain references in contoso.com failing to update for branch.contoso.com objects. Transferring the infrastructure master role for contoso.com from DC1 to DC2, which is not a global catalog server, resolves the issue with a single, minimal role transfer. Transferring the PDC emulator, schema master, or domain naming master roles would not affect phantom/cross-domain reference updates at all, and DC4 already correctly holds branch.contoso.com ' s infrastructure master role on a non-GC server.

Upgrading, or more precisely transferring, the PDC emulator FSMO role to a different domain controller has no bearing whatsoever on which replication engine SYSVOL uses within the domain. The blocking condition preventing a Windows Server 2022 domain controller from being added is strictly that Windows Server 2016 and later builds no longer ship the File Replication Service binaries at all, so as long as SYSVOL keeps replicating over FRS, no domain controller running a newer operating system can be introduced into the domain, entirely regardless of which existing domain controller happens to hold the PDC emulator role at the time. Moving the PDC emulator role does not touch SYSVOL replication technology in any way, does not migrate anything from FRS to DFS Replication, and does not remove the FRS binaries requirement that the domain promotion process checks for. Only actually migrating SYSVOL replication from FRS to DFS Replication addresses the real constraint described in the scenario, so upgrading the PDC emulator alone does not meet the goal.

Cluster role to create on Cluster2: Hyper-V Replica Broker. Replication target name to specify: The name of the Hyper-V Replica Broker.

When Hyper-V Replica is used with a clustered Hyper-V host as either the primary or the replica site, that cluster requires a Hyper-V Replica Broker role, because the broker abstracts away which specific physical node currently owns a given replicated virtual machine, keeping replication working correctly even as VMs live-migrate or fail over between nodes within the cluster. Before enabling replication, an administrator must create this Hyper-V Replica Broker role on Cluster2 and configure its replication settings, including the authentication method, the storage location for replica virtual machine files, and which primary servers are allowed to replicate to it. When subsequently configuring replication for the virtual machines on Cluster1, the destination (replica server) must be specified using the Hyper-V Replica Broker ' s own client access point name -- not the name of an individual physical node in Cluster2 -- because the broker, not any single node, is what tracks current VM ownership as virtual machines move between Cluster2 ' s nodes. Specifying an individual node name instead would break replication and failover as soon as a VM ' s ownership moved to a different node in Cluster2.

Adding or removing an application directory partition in AD DS -- including custom partitions such as the one App1 used to store its configuration data -- is an operation that must be performed against, and requires the availability of, the domain controller holding the Domain Naming Master FSMO role for the forest. This is the single operations master responsible for maintaining the list of domains and application partitions in the forest and for coordinating additions or removals of directory partitions; if that role holder is offline or unreachable, attempts to add or remove an application partition will fail, even though normal object read/write operations against other partitions (users, groups, and so on) may continue to function against any available domain controller. According to the exhibit ' s role assignments, DC3 holds the Domain Naming Master role. The Schema master (DC1) governs schema extensions, the Infrastructure master (DC2) governs cross-domain object reference updates, and the PDC emulator/RID master (DC4) govern time synchronization, password/authentication emulation, and relative ID pool allocation respectively -- none of these roles are involved in application partition add/remove operations. Because the removal of the custom application partition specifically failed, the unavailable domain controller must be the Domain Naming Master role holder, DC3.

Azure Site Recovery replication for Azure-to-Azure scenarios supports standard-security VMs (VM1, VM2) as well as trusted launch virtual machines running Windows Server, a capability that is generally available and documented specifically for Azure-to-Azure replication, which covers VM3. Confidential VMs such as VM4, however, rely on hardware-bound (vTPM/attestation-tied) OS disk encryption keys that are not part of Azure Site Recovery ' s supported replication scenarios, so a VM configured with the Confidential security type cannot currently be replicated using Azure Site Recovery. The Windows Server 2025 Datacenter: Azure Edition operating system itself is fully supported and is not the limiting factor for any of the four VMs; the security type of VM4 is what excludes it. If VM4 must still be protected for disaster recovery, an alternative such as Azure Backup for VM-level snapshots, or a guest-level replication tool that operates independently of the confidential computing attestation boundary, would need to be considered instead of Azure Site Recovery.

Azure Relay ' s Hybrid Connections feature is designed specifically to expose an on-premises application, such as App1, to the internet without opening any inbound ports on the on-premises firewall: a small Hybrid Connection Manager agent installed on-premises establishes an outbound-only connection to the Azure Relay service, and internet clients then reach the on-premises app through that relay, so Firewall1 needs no new inbound rules at all -- the connection is entirely outbound-initiated from the on-premises side. Hybrid Connections also natively supports WebSockets-based traffic, matching how internal users already connect to App1. Microsoft Application Request Routing (ARR) is an IIS extension for reverse-proxying and load-balancing HTTP(S) traffic; using it to expose App1 to the internet would still require opening an inbound port on Firewall1 for the reverse proxy to receive traffic, unless combined with something like Azure Relay, so it does not meet the " minimize inbound ports " requirement on its own. Web Application Proxy is an on-premises AD FS/pre-authentication reverse proxy role that also requires an inbound-facing listener and open firewall ports to accept traffic from the internet. Azure Application Gateway is an Azure-hosted load balancer/WAF that operates on resources already reachable from Azure (such as VMs or on-premises endpoints reachable via VPN/ExpressRoute); it does not eliminate the need for inbound connectivity to an on-premises firewall the way Azure Relay ' s outbound-only model does. Therefore, Azure Relay (Hybrid Connections) is the correct inclusion.

The Azure Migrate physical server migration support matrix explicitly lists teamed network interface cards as an unsupported source-machine configuration for agent-based, Mobility-service physical server migration, and Server1 ' s configuration table shows NIC Teaming as Enabled, which is precisely the condition the support matrix flags as a blocker. Disabling NIC teaming on Server1 directly removes that one unsupported configuration item, which is the actual root cause preventing the migration from proceeding, and doing so allows the Mobility service already installed on Server1 to establish the network connectivity Azure Migrate needs without the teaming configuration interfering. Reviewing the rest of Server1 ' s configuration confirms that the operating system disk size, the data disk size, the Windows Firewall state, and the Microsoft Defender Antivirus state are all already within Azure Migrate ' s supported limits and were never the actual blocking factor in the first place, so no additional remediation beyond disabling NIC teaming is required. Because this solution directly addresses the one configuration item the support matrix actually flags as unsupported, disabling NIC Teaming on Server1 does meet the stated goal.

Store in: An Azure Policy definition; Use: Guest configuration in Azure Policy

For a large fleet of Azure Arc-enabled, on-premises, domain-joined servers, the lowest-administrative-effort way to deliver and enforce PowerShell DSC configurations at scale is Azure Policy guest configuration (the successor to Azure Automation State Configuration, which Microsoft has scheduled for retirement and recommends migrating away from). With guest configuration, you package the DSC content and reference it directly from a guest configuration (Azure Policy) definition -- the content does not need to be published to, or managed inside, an Azure Automation account at all. Microsoft ' s own migration guidance for machine configuration confirms that DSC content is developed and published to any HTTPS-reachable location and then attached to machines purely through Azure Policy assignments, with no compilation or hosting step inside Automation. Once the guest configuration policy is assigned to the Arc-enabled machines (scoped by subscription, resource group, or individual machine), the Guest Configuration extension on each Arc agent pulls, applies, and continuously audits/remediates the configuration -- all centrally managed through Azure Policy, with no pull server, Automation account, or manual per-server DSC push required. This gives uniform rollout and governance across all 500 servers with minimal ongoing administration. Therefore, the DSC content should be referenced from an Azure Policy (guest configuration) definition, and Guest configuration in Azure Policy is the mechanism used to apply and enforce it across the Arc-enabled fleet.