AZ-802 Exam Dumps - Microsoft Certified: Windows Server Hybrid Administrator Associate Questions and Answers

Disk1: NTFS only. Disk2: NTFS only.

Disk-level (NTFS) quotas are an NTFS-specific feature with no ReFS or exFAT equivalent, so a volume that must support disk quotas has to be formatted NTFS -- there is no alternative file system choice for Disk1. Data Deduplication has historically been an NTFS-only feature, and while Microsoft did extend Data Deduplication support to ReFS starting with Windows Server 2019, that ReFS Dedup capability is specifically documented and supported in the context of Storage Spaces Direct clustered volumes (mirror or parity resiliency) -- it is not a general capability available on an arbitrary standalone server ' s locally attached disk the way it is described here (a plain server with two newly added hard drives, no clustering or Storage Spaces Direct mentioned). For a standalone server like Server1 formatting a local data disk for Data Deduplication, NTFS remains the applicable and supported choice; ReFS Dedup would only become relevant if these disks were part of a Storage Spaces Direct deployment. exFAT supports neither quotas nor Data Deduplication, and plain ReFS without the Storage Spaces Direct context does not support Data Deduplication either. Therefore, both Disk1 and Disk2 should be formatted NTFS to meet their respective requirements in this standalone-server scenario.

Storage Quality of Service centralized policy management cmdlets (such as New-StorageQosPolicy, Get-StorageQosFlow, and related cmdlets) are delivered as part of the failover clustering management tooling, because Storage QoS ' s centralized model is built around a Scale-Out File Server or Hyper-V cluster -- the policies are created and managed on the storage cluster side and consumed by the compute cluster side, and the PowerShell module providing these cmdlets is installed alongside the Failover Clustering Tools RSAT feature. RSAT: Data Center Bridging LLDP Tools installs management support for DCB/LLDP configuration (relevant to RDMA/SET-teamed adapters), not Storage QoS. RSAT: Storage Replica Module for Windows PowerShell provides cmdlets for the unrelated Storage Replica block-level replication feature. RSAT: File Services Tools installs management consoles for general file server roles (such as File Server Resource Manager and DFS Management), but not the Storage QoS cmdlets, which are specifically tied to the clustering stack rather than the file services role itself. Therefore, to manage Storage QoS from Server1, the RSAT: Failover Clustering Tools feature must be installed.

The built-in Backup Operators group is a domain local security group that exists separately in every domain of a forest; membership in contoso.com ' s Backup Operators group has no effect outside that domain. The backup/restore user rights that Backup Operators grants (SeBackupPrivilege and SeRestorePrivilege) are assigned through the Default Domain Controllers Policy GPO, which links only to the Domain Controllers OU within contoso.com -- so those rights apply only to DC1, the domain controller of contoso.com. Backup Operators membership in contoso.com does not grant any rights on Server1, because Server1 is a member server, not a domain controller, and the Default Domain Controllers Policy does not apply to member servers; a member server ' s local Backup Operators group (or local security policy) would need to be configured separately for that server. It also grants no rights on DC2 or Server2 in east.contoso.com, because Backup Operators group membership and its associated GPO-derived rights are scoped entirely to the domain in which the group exists (contoso.com) and do not extend across a parent/child domain trust boundary to another domain ' s domain controllers or member servers, even within the same forest. Therefore, adding User1 to contoso.com ' s Backup Operators group allows User1 to back up only DC1 -- the sole domain controller governed by the Default Domain Controllers Policy of that same domain.

An Azure Private DNS zone such as contoso.com is only directly resolvable by resources inside a virtual network it is linked to; once Server1 is migrated out of VNet1 to the on-premises datacenter, it loses that direct resolution path and needs a route back into Azure to reach the private zone ' s records. An Azure DNS Private Resolver ' s inbound endpoint is specifically designed to provide an IP address inside the VNet that on-premises DNS infrastructure (reachable via the existing ExpressRoute circuit, ER1) can send queries to for names in the linked private zone. Since Server1 already runs the DNS Server role and already has a conditional forwarder configured for contoso.com (previously usable while Server1 was inside the VNet), the necessary follow-up action after migration is to modify that existing conditional forwarder so it points at PR1 ' s inbound endpoint IP address, letting Server1 continue resolving contoso.com entries by forwarding those specific queries over ER1 into Azure. Creating a secondary zone on Server1 would not work, since Azure Private DNS zones do not support zone transfers (AXFR/IXFR) at all. Creating an outbound endpoint on PR1, or a DNS forwarding ruleset associated with an outbound endpoint, are both mechanisms for resolving external (for example, on-premises) namespaces from within Azure -- the opposite direction of what ' s needed here, which is on-premises resolution of an Azure-hosted private zone. Therefore, modifying Server1 ' s conditional forwarder for contoso.com to target PR1 ' s inbound endpoint is the correct action.

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.

Windows Admin Center ' s gateway access control (the " allowed groups " /gateway users list) only actively restricts sign-in once it contains at least one entry; when that list is left empty -- as happens here after BUILTIN\Users was removed without anything being added in its place -- Windows Admin Center falls back to allowing any authenticated user to sign in, rather than denying everyone. This is a well-documented behavior and the reason removing the sole existing entry does not lock anyone out: with no groups configured, no restriction is actually enforced. The fix is to add a specific security group (containing only the intended administrators) to the allowed groups list, which populates it with at least one entry and causes Windows Admin Center to begin enforcing that only members of the listed group(s) can sign in. Setting Performance Profile to On only affects Windows Admin Center ' s resource-usage/monitoring behavior and has no bearing on sign-in authorization. " Require re-authentication for manage-as sessions " only affects how often a user must re-enter alternate credentials when using the manage-as feature for a connection, not who can sign in to the gateway itself. Configuring a proxy bypass list only affects how Windows Admin Center reaches external endpoints through an outbound proxy and is unrelated to gateway sign-in authorization. Therefore, adding a security group to the allowed groups is the correct action to actually enforce access restriction.

DHCP1: Export-DhcpServer, Remove-DhcpServerInDC. DHCP2: Add-DhcpServerInDC, Import-DhcpServer.

Migrating a DHCP server ' s configuration together with its existing leases and reservations by PowerShell follows an export/unauthorize-then-authorize/import pattern across the two servers. On the source server, DHCP1, Export-DhcpServer captures the existing scopes, options, leases, and reservations into a migration file, which is what allows the existing leases and reservations to actually carry over to the replacement server. Remove-DhcpServerInDC is then run on DHCP1 to unauthorize it in Active Directory, which is what prevents DHCP1 from continuing to service client requests once DHCP2 is brought online, satisfying that specific migration requirement. On the target server, DHCP2, Add-DhcpServerInDC authorizes the new server in AD DS so it is permitted to lease addresses on the network, and Import-DhcpServer then applies the configuration file exported from DHCP1, causing DHCP2 to hand out the same address ranges as DHCP1 along with the existing leases and reservations that were captured during export. Add-DhcpServerv4Scope and Remove-DhcpServerv4Scope only create or delete an individual scope ' s address range and do not export, import, or preserve any existing lease or reservation data, so neither is part of this migration sequence. Therefore, DHCP1 requires Export-DhcpServer and Remove-DhcpServerInDC, while DHCP2 requires Add-DhcpServerInDC and Import-DhcpServer.

Enforce the security policy: Microsoft Defender Application Control. Manage the policy settings: Group Policy Objects (GPOs).

Windows Defender Application Control (WDAC) is the platform feature that enforces which applications are authorized to install or run on a Windows Server, directly meeting the stated requirement that only authorized applications can be installed or run on the servers in the forest. Microsoft Defender Application Guard isolates untrusted browsing sessions in a container and Microsoft Defender Credential Guard protects credential material from theft -- neither controls which applications are permitted to execute. Microsoft Defender for Endpoint is an endpoint detection-and-response platform that detects and responds to threats rather than enforcing a whitelist of permitted applications. Because the servers described are on-premises, domain-joined machines rather than Intune-managed, Microsoft Entra-joined devices, the WDAC policy settings here must be managed through Group Policy Objects distributed via AD DS, not through Intune. Configuration profiles in Microsoft Intune and compliance policies in Microsoft Intune are both cloud-management mechanisms that apply only to devices enrolled in and managed by Intune, which these on-premises, domain-joined servers are not. Therefore, WDAC is the enforcing service and Group Policy Objects are the correct management mechanism for these on-premises servers.

A Windows Server failover cluster requires a distinct IP address for each individual cluster node ' s network adapter, plus one additional IP address for the cluster ' s own network name resource -- the cluster access point that clients and management tools use to address the cluster as a single logical entity rather than any one specific node. Cluster3 will contain two physical nodes, Node1 and Node2, so at minimum one IP address is required for Node1 ' s network adapter and one for Node2 ' s network adapter. Beyond those two node-level addresses, the cluster core resource itself (the cluster name object and its associated IP address resource) requires one more address so that the cluster can be addressed and managed as a whole and so that any highly available roles hosted on the cluster (such as the file share role planned for Cluster3) can obtain the network identity they need to fail over between nodes. Adding these together -- one for Node1, one for Node2, and one for the cluster ' s own network name -- yields a minimum of three IP addresses required for Cluster3 ' s node and cluster roles. Fewer than three would leave either a node or the cluster itself without a usable network identity, and while additional IP addresses may be consumed by highly available roles later added to the cluster, three is the baseline minimum for the node and cluster roles themselves.

Microsoft Defender for Identity is the Microsoft Sentinel data connector purpose-built to monitor on-premises Active Directory domain controllers and surface exactly the insecure-protocol activity described in the requirement, including authentication attempts and sign-ins that rely on legacy or unsigned protocols such as NTLMv1, SMBv1, and unsigned LDAP binds. It does this by analyzing domain controller network traffic and Windows Events directly on the DCs, which is exactly where this insecure-protocol usage originates. The Threat Intelligence - TAXII connector ingests external threat-intelligence indicator feeds (IP addresses, file hashes, domains) from TAXII-compliant sources and has nothing to do with monitoring authentication protocol usage on domain controllers. The Azure Active Directory (Microsoft Entra ID) connector reports on cloud sign-in and audit log events for the Entra tenant, not on legacy protocol usage against on-premises AD DS domain controllers. Microsoft Defender for Cloud focuses on cloud resource security posture management and workload protection rather than detecting legacy authentication protocol usage against on-premises domain controllers. Therefore, connecting Microsoft Defender for Identity to Microsoft Sentinel is the correct connector to identify connections to the domain controllers that use insecure protocols.