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

Private1 is deployed with its inbound endpoint in VNet1, and an Azure DNS Private Resolver inbound endpoint can resolve only private DNS zones that are virtual-network-linked to the same virtual network where the resolver itself sits; it cannot resolve a zone just because it exists in the same subscription, or because that zone happens to be linked to a different, unrelated virtual network. Per the private DNS zone table, Zone1.com is linked to VNet1, Zone2.com is linked to VNet2, and Zone3.com has no virtual network link at all. Because Private1 ' s inbound endpoint lives in VNet1, only Zone1.com, the zone actually linked to VNet1, can be resolved through it. Zone2.com cannot be resolved by Private1 because it is linked only to VNet2, a separate virtual network with no stated peering or additional resolver configuration connecting it to VNet1; and Zone3.com cannot be resolved by any resolver in any virtual network because it has no virtual network link whatsoever, meaning no virtual network can consult it through the normal Azure-provided DNS resolution path. Extending resolution to Zone2.com would require either a separate resolver deployed in VNet2, or peering combined with a forwarding ruleset and outbound endpoint, neither of which is described as being configured here. Therefore only Zone1.com can currently be resolved.

The Marketing OU users exist in fabrikam.com, a completely separate on-premises AD DS forest belonging to a different company than A. Datum, whose own Microsoft Entra tenant only syncs the adatum.com forest today. To give those Fabrikam users access to storage1 in A. Datum ' s tenant, their identities must also be represented in that tenant. Microsoft Entra Connect cloud sync uses lightweight, cloud-managed provisioning agents that are specifically designed to support complex or multi-forest topologies, including syncing from a partner organization ' s forest, with a much smaller on-premises footprint and configuration burden than the full Microsoft Entra Connect Sync engine, and without requiring a trust relationship between the two companies ' forests. The traditional Microsoft Entra Connect Sync engine (whether in active or staging mode) is built around a single organization ' s identity infrastructure and is a heavier deployment to extend safely across an independent partner company ' s forest; staging mode specifically only prepares a secondary sync server to take over, and does not by itself address the cross-company sync problem. AD FS provides federation and SSO but does not create Microsoft Entra ID objects for Fabrikam ' s users. Microsoft Entra Connect cloud sync is therefore the correct, purpose-built option.

Storage Migration Service is designed to migrate a file share such as Share1 to a new server (Server2) while carrying over both the share-level and NTFS folder/file permissions, and it can also perform a cutover of the source server ' s name and IP address if a fully transparent migration is later required. This directly satisfies the requirement to migrate Share1 to Server2 including all the share and folder permissions. File Server Resource Manager (FSRM) only provides quota, file-screening, and storage-reporting capabilities and has no mechanism to migrate data, shares, or permissions between servers. Server Manager is a general-purpose administration console with no dedicated share-migration workflow -- it can be used to create shares manually but cannot transfer existing permissions programmatically. Storage Replica performs block-level volume replication intended for disaster recovery and stretch-cluster scenarios rather than a one-time, permission-preserving share migration to a specific destination server. Therefore, Storage Migration Service is the correct tool to migrate Share1 to Server2 while preserving its share and folder permissions.

BitLocker: C, D, E, and F. Auto-unlock: D, E, and F only.

BitLocker Drive Encryption can be enabled on every volume shown in Server4 ' s disk configuration -- the NTFS-formatted operating system volume (C:), the NTFS data volume (D:), and the two ReFS-formatted data volumes (E: and F:). BitLocker has no file-system restriction that excludes ReFS: Microsoft ' s ReFS documentation and BitLocker ' s own volume support explicitly confirm that ReFS-formatted volumes, including already-encrypted ones that are later expanded, are fully supported, so E: and F: are just as eligible for BitLocker as the NTFS volumes. BitLocker auto-unlock, however, is a feature limited to fixed data volumes: it lets a data volume unlock automatically at startup using a key protected by the already-unlocked operating system volume, and it is not applicable to the OS volume itself, since the OS volume instead relies on the TPM (or a startup key/PIN) to unlock during boot -- there is no separate outer volume for it to depend on. Because C: is the operating system volume, auto-unlock cannot be configured on it, leaving D:, E:, and F: as the volumes eligible for auto-unlock. Therefore, BitLocker can be turned on for all four volumes (C, D, E, and F), while auto-unlock is available only on the three data volumes (D, E, and F).

The Azure Site Recovery Provider must be installed and registered on every Hyper-V host that is a node of the cluster being protected, because each node is a location the protected virtual machines could reside on after a live migration, and each node must independently be able to track and replicate the VMs it is currently hosting. Cluster2 has four nodes according to the Hyper-V failover clusters table (Cluster1 has six nodes and eighteen virtual machines, Cluster2 has four nodes and twelve virtual machines, and Cluster3 has two nodes and six virtual machines), so a minimum of four Provider installations -- one per node -- is required; installing the Provider on only one, two, or three of the nodes would leave replication unable to follow a protected VM if it live-migrated to whichever node lacks the Provider, breaking continuous replication for that VM the moment it moved. Therefore, four is the minimum number of Azure Site Recovery Provider installations required to fully protect all of Cluster2 ' s virtual machines regardless of which node currently hosts them.

Using Hyper-V Replica within a clustered Hyper-V environment such as Cluster3 requires deploying the Hyper-V Replica Broker, which itself runs as a clustered role on the failover cluster; without the Broker, replication cannot follow a protected virtual machine if it live-migrates between Cluster3 ' s nodes, since there would be no single, cluster-aware endpoint tracking which node currently owns each VM ' s replication state. Adding a failover cluster role is exactly how the Hyper-V Replica Broker is deployed onto Cluster3, satisfying the requirement to use Hyper-V Replica to protect Cluster3 ' s virtual machines. Enabling integration services on the virtual machines addresses guest-OS-to-host integration (time synchronization, heartbeat, and similar) rather than providing any replication capability. Adding a generic Windows Server server role does not, by itself, install or configure the Hyper-V Replica Broker -- the Broker must specifically be added as a clustered role through Failover Cluster Manager. Configuring a fault domain for the cluster is not a real Windows Server failover clustering concept and does not provide Hyper-V Replica capability. Therefore, adding a failover cluster role (the Hyper-V Replica Broker) is the correct solution for Cluster3.

Restoring deleted objects from the Active Directory Recycle Bin requires permission to view and restore objects inside the forest ' s Deleted Objects container, and by default that container ' s access control list denies access to everyone except the SYSTEM account and members of Domain Admins (and Enterprise Admins at the forest root) -- no delegation to any other built-in group exists out of the box. Among the four groups offered, only Domain Admins carries this permission by default, since Account Operators (which can manage most user, group, and computer objects but has no special access to the hidden Deleted Objects container), Schema Admins (which governs schema modifications, not object restoration), and Backup Operators (which can back up and restore files and the system state, but not perform an online Active Directory Recycle Bin object restore through the Active Directory Administrative Center) all lack the needed access. The case study ' s general instruction to use the principle of least privilege where possible does not change this outcome here, since none of the three lower-privileged alternatives actually has the required capability by default -- Domain Admins is not merely the most convenient choice but the only one of the four that functionally works. Therefore, User1 must be added to Domain Admins to be able to recover objects from the Active Directory Recycle Bin.

Backing up a standalone Windows Server ' s files, folders, and system state directly to an Azure Recovery Services vault -- exactly what the requirement calls for on Server4 -- is done using the Microsoft Azure Recovery Services (MARS) agent, so installing that agent on Server4 is the necessary first step. Microsoft Azure Backup Server (MABS) is used for application-aware and Hyper-V virtual machine backups rather than direct file/system-state backup of a single standalone server, and while it can also protect servers, it is not the lightweight, direct-to-vault mechanism appropriate for a single standalone server like Server4 and represents unnecessary additional infrastructure. Native Windows Server Backup does not target an Azure Recovery Services vault on its own without additional agent installation, and Storage Replica provides block-level volume replication between servers rather than the point-in-time backup and long-term retention the requirement calls for. Therefore, installing the MARS agent on Server4 is the correct first step to meet this technical requirement.

Promoting a new domain controller that runs a newer operating system version than any existing domain controller in the forest -- here, DC4 running Windows Server 2022 into a forest whose functional level is still Windows Server 2012 R2 -- requires the Active Directory schema to first be extended to support that OS version ' s schema additions (the adprep /forestprep and /domainprep operations, which modern promotion tools such as Install-ADDSDomainController run automatically when needed). Extending the schema requires connectivity to the domain controller holding the Schema Master FSMO role, since schema changes can only be made by contacting that specific role holder; if the Schema Master is offline, the schema extension step fails and the promotion cannot proceed. According to the domain controllers table, DC1 holds both the RID master and the schema master roles. DC2 holds the PDC emulator and infrastructure master roles, and DC3 holds the domain naming master role -- neither of those role sets is relevant to a schema extension. Therefore, DC1, as the Schema Master, must be online for DC4 ' s promotion (and its associated schema extension) to succeed.

User1: 9. Admin1: 8.

Fine-grained password policies delivered through Password Settings Objects (PSOs) take precedence over the domain-wide Default Domain Policy for any user they apply to. When more than one PSO would apply to the same user only through different group memberships (as opposed to one being linked directly to the user), the PSO with the lowest numeric precedence value wins. User1 is a member of both Group2 (targeted directly by PSO1, precedence 10, minimum password length 9) and Group4 (targeted directly by PSO2, precedence 20, minimum password length 11); since PSO1 ' s precedence value of 10 is lower than PSO2 ' s 20, PSO1 governs, giving User1 an effective minimum password length of 9. Admin1 is a member only of Domain Admins, which is not targeted by either PSO, so no fine-grained password policy applies. Admin1 is also in OU1, which has GPO1 linked to it with a minimum password length of 10, but Account Policy settings such as password policy configured in an OU-linked GPO never affect the effective password policy of domain user accounts -- only a GPO linked at the domain root can supply a fallback domain-wide default, and PSOs otherwise take precedence over that default. With no applicable PSO, Admin1 ' s effective policy falls back to the Default Domain Policy, whose minimum password length in this environment is 8.