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

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.

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.

Server1 can communicate with: Server2, Server3, and Server4. Server3 can communicate with: Server1 and Server2 only.

Server4 has no isolation connection security rule configured at all, so it never attempts or performs IPsec authentication with any peer. Server1 ' s rule only requests IPsec in both directions rather than requiring it, meaning that if IPsec negotiation does not occur -- as with Server4, which has no IPsec capability configured -- the connection still falls back to succeed in the clear; Server1 can therefore reach Server2, Server3, and Server4. Server3 ' s rule requires IPsec in both directions, meaning a connection only succeeds if IPsec authentication is actually negotiated. Server3 can successfully negotiate IPsec with Server1 (whose " request " setting means it will still respond to and complete an IPsec negotiation when the peer requires it) and with Server2 (which requires inbound and requests outbound IPsec, and likewise supports negotiation), so both of those connections succeed. Server3 cannot successfully negotiate IPsec with Server4, since Server4 has no IPsec capability configured at all, and Server3 ' s " require " setting blocks any connection that cannot be authenticated via IPsec. Therefore, Server1 can communicate with Server2, Server3, and Server4, while Server3 can communicate with only Server1 and Server2.

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.

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.

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.

Signing in over Remote Desktop requires a user to hold the " Allow log on through Remote Desktop Services " right and the " Access this computer from the network " right, and to be excluded from any matching Deny counterpart, since an explicit Deny always overrides an Allow granted through any other group membership. User1 is a member of Group2 (granted the Remote Desktop Services logon right) but is also a member of Group4, which is explicitly denied " Access this computer from the network " on Server4 -- that network-access denial blocks the RDP connection outright regardless of the Everyone-based network-access Allow or the RDS logon right, so User1 is denied. User2 belongs only to Group2: Group2 grants the RDS logon right, User2 is covered by the Everyone-based network-access Allow, and User2 is not a member of either Group3 or Group4, so neither Deny applies and User2 can sign in successfully. User3 is a member of Group3, which is explicitly denied " Allow log on through Remote Desktop Services " on Server4 -- that denial blocks the RDP logon right itself, so User3 cannot sign in regardless of network-access rights (and User3 is also in Group4, which independently denies network access as well). Therefore, only User2 can successfully sign in to Server4 using Remote Desktop.

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.

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.