Free Practice Questions for the Microsoft Certified: Windows Server Hybrid Administrator Associate AZ-801 Exam (2026 Updated)

Detailed Explanation

Centrally managing performance alerts in Azure for on-premises domain controllers is done by connecting those servers to Azure Monitor: the Azure Monitor agent is installed on each domain controller (typically through Azure Arc for non-Azure servers) to collect performance counters and event data, and that data is sent to an Azure Log Analytics workspace created in Azure, which is the resource that stores the collected telemetry and against which performance-based alert rules are defined and centrally managed. Creating a Data Collector Set in Performance Monitor or modifying the Performance Monitor Users group are local, per-server administrative actions that do not send data to Azure, and an Azure SQL database, Storage Sync Service, or Azure Storage account are not the telemetry store that Azure Monitor alerting is built on.

Official Reference

Overview of Azure Monitor agent — https://learn.microsoft.com/en-us/azure/azure-monitor/agents/agents-overview

Detailed Explanation

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 sign-ins and authentication attempts that use legacy or unsigned protocols such as NTLMv1, SMBv1, and unsigned LDAP. Threat Intelligence - TAXII ingests external threat-intelligence indicator feeds rather than DC authentication telemetry, the Azure Active Directory connector reports on cloud/Microsoft Entra ID sign-in and audit events rather than on-premises AD DS domain controller traffic, and Microsoft Defender for Cloud focuses on cloud resource security posture rather than legacy-protocol detection against on-premises domain controllers.

Official Reference

Connect data from Microsoft Defender for Identity to Microsoft Sentinel — https://learn.microsoft.com/en-us/azure/sentinel/data-connectors/microsoft-defender-for-identity

Detailed Explanation

The General tab shows that App1 has no preferred owners selected, and the Failover tab shows " Allow failback: Immediately, " but failback only has an effect once a most-preferred owner is defined in the Preferred Owners list; without one, the cluster has no designated target to fail the role back to. Pausing the Server1 node, which is currently running App1 after Server2 ' s outage, and then starting Server1 again does nothing to move App1 back onto Server2 once Server2 is restarted, because pausing a node only prevents new roles from starting on it and does not trigger a role to move elsewhere. To meet the stated goal, Server2 would need to be configured as the preferred owner for App1 so that failback has a defined target to move the role back to automatically.

Official Reference

Configure failover and preferred owners settings for a clustered role — https://learn.microsoft.com/en-us/windows-server/failover-clustering/manage-clustered-role-preferred-owner

Detailed Explanation

The -ADAccountOrGroupProtector parameter of Add-BitLockerKeyProtector adds an Active Directory account or group as a key protector for a BitLocker-protected data volume (this protector type cannot be applied to an operating system volume, which matches the D: data volume shown in the exhibit). Pairing it with the -Service switch specifies that the protector is the computer ' s own service (machine) account, expressed as DOMAIN\ComputerName$, which lets that computer automatically unlock the volume without a signed-in user — the standard pattern for unattended or service-hosted data volumes. The second dropdown correctly resolves to -Service rather than -TPMandPinProtector or -TPMandPinAndStartupKeyProtector, since neither of those protector types is used together with an AD account/group protector.

Official Reference

Add-BitLockerKeyProtector (BitLocker module) — https://learn.microsoft.com/en-us/powershell/module/bitlocker/add-bitlockerkeyprotector

Detailed Explanation

Running Get-AzVMDiskEncryptionStatus against VM1 returns the current Azure Disk Encryption status for its OS and data disks in a single call, including the key vault URL/resource ID where the encryption secrets are stored, so no separate lookup of encryption sets or key vault contents is needed. Get-AzKeyVaultKey and Get-AzDiskEncryptionSet both require you to already know which key vault or disk encryption set resource to query, and Get-AzKeyVault only enumerates key vaults in the subscription without tying any of them to VM1 specifically, so they involve more administrative effort.

Official Reference

Azure Disk Encryption for Windows VMs — https://learn.microsoft.com/en-us/azure/virtual-machines/windows/disk-encryption-overview

Detailed Explanation

Ntdsutil.exe is the built-in tool used to create and manage Active Directory Domain Services snapshots, which are point-in-time, volume-shadow-copy-based captures of the AD database that can be taken without stopping the domain controller. Dsamain.exe then mounts one of those snapshots and exposes its contents as a read-only LDAP directory on a separate port, letting an administrator browse, compare, or recover objects from the earlier point in time without performing an authoritative restore. This snapshot-and-mount workflow is the standard low-impact way to inspect prior AD DS state for recovery purposes.

Official Reference

Viewing and Managing Active Directory Snapshots — https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/get-started/adac/viewing-and-managing-active-directory-snapshots-with-active-directory-administrative-center-level-200-

Detailed Explanation

Pktmon, the built-in Windows packet monitor, lets you build a capture filter that narrows collection to a specific remote IP address with -i, a specific transport protocol with -t, and, for TCP, a specific set of TCP flags such as syn, ack, fin, rst, psh, or urg appended after the protocol. Combining -i 192.168.0.100 with -t tcp and the syn flag restricts the capture to just the SYN packets exchanged with that address, which is exactly what the scenario requires, and matches the documented pktmon filter add syntax.

Official Reference

Pktmon command formatting — https://learn.microsoft.com/en-us/windows-server/networking/technologies/pktmon/pktmon-syntax

Detailed Explanation

With BGP disabled, the Site-to-Site connection relies on statically defined routes rather than dynamic route propagation, so when Subnet2 is added to Vnet1 ' s extended address space, Azure ' s side of the tunnel already knows about it (it ' s part of the connected VNet), but the on-premises routers have no route telling them that traffic destined for Subnet2 ' s range should be sent across the VPN tunnel. Server1 can reach Server2 because that traffic never leaves the Azure virtual network, but on-premises hosts have no path configured to the new subnet until the on-premises routing tables (and, if applicable, the local network gateway/VPN device configuration) are updated to include it. Adding another Site-to-Site tunnel, a private endpoint, or a user-defined route table in Subnet2 does not address the missing route on the on-premises side, which is the actual point of failure.

Official Reference

About VPN Gateway configuration settings – routing — https://learn.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-about-vpn-gateway-settings

Detailed Explanation

Windows Defender Application Control (WDAC) is the platform feature that enforces which applications are authorized to run on a Windows Server, meeting the requirement that only authorized applications can be installed or run. Because these servers are on-premises, domain-joined machines rather than Intune-managed/Microsoft Entra-joined devices, WDAC policies here are deployed and managed through Group Policy Objects rather than through Intune configuration or compliance profiles (those Intune management paths apply to cloud-managed endpoints). Microsoft Defender Application Guard and Credential Guard address different problems (isolating untrusted browsing sessions and protecting credential material, respectively) and do not enforce which applications can execute, and Microsoft Defender for Endpoint is an endpoint detection-and-response platform rather than an application-control enforcement mechanism.

Official Reference

Deploy Windows Defender Application Control (WDAC) policies by using Group Policy — https://learn.microsoft.com/en-us/windows/security/application-security/application-control/windows-defender-application-control/deployment/deploy-wdac-policies-using-group-policy

Detailed Explanation

Recovering deleted objects from the Active Directory Recycle Bin requires permission to restore objects from the Deleted Objects container, and among the four groups offered, Domain Admins is the built-in group whose members are granted this capability by default (the forest ' s Active Directory Recycle Bin feature is already enabled in this environment). Account Operators, Schema Admins, and Backup Operators do not carry the permissions needed to restore deleted objects from the Deleted Objects container by default, so Domain Admins is the appropriate group for User1 to meet this requirement while still limiting the elevated access to only what is needed for this task.

Official Reference

Restore deleted Active Directory objects — permissions required — https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/get-started/adac/introduction-to-active-directory-administrative-center-enhancements--level-100-#active-directory-recycle-bin

Detailed Explanation

Fine-grained password policies apply through Password Settings Objects (PSOs) linked to security groups, and when more than one PSO would apply to the same user through different group memberships, the PSO with the lowest precedence value wins. User1 belongs to both Group2 (targeted by PSO1, precedence 10, minimum password length 9) and Group4 (targeted by PSO2, precedence 20, minimum password length 11); since PSO1 ' s precedence value of 10 is lower than PSO2 ' s 20, PSO1 takes effect and User1 ' s effective minimum password length is 9. Admin1 belongs only to Domain Admins, which is not a target of either PSO, so no fine-grained password policy applies to Admin1 -- the effective policy falls back to the domain ' s Default Domain Policy password settings, whose configured minimum password length in this environment is 8.

Official Reference

Password Settings Object precedence for fine-grained password policies — https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/get-started/adac/introduction-to-active-directory-administrative-center-enhancements--level-100-#fine-grained-password-policy-management-with-adac

Detailed Explanation

Signing in over Remote Desktop with Network Level Authentication requires a user to hold both 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. 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 ' -- 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 ' -- that denial blocks the RDP logon right itself, so User3 cannot sign in regardless of network-access rights.

Official Reference

Logon rights used for Remote Desktop sign-in with Network Level Authentication — https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/clients/remote-desktop-allow-access

Detailed Explanation

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, so if IPsec negotiation does not occur -- as with Server4 -- 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 the connection only succeeds if IPsec authentication is actually negotiated. Server3 can successfully negotiate IPsec with Server1 (which supports and will attempt IPsec even though it only requests it) and with Server2 (which requires inbound and requests outbound IPsec, and likewise supports negotiation), so both of those connections succeed; but Server3 cannot successfully negotiate IPsec with Server4, since Server4 has no IPsec capability configured for this purpose, so that connection is blocked by Server3 ' s require setting.

Official Reference

Isolation domains and IPsec connection security rule authentication modes (Require vs. Request) — https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/appendix-l--events-to-monitor

Detailed Explanation

Using Hyper-V Replica within a clustered Hyper-V environment such as Cluster3 requires the Hyper-V Replica Broker, which is itself deployed as a clustered role on the failover cluster; without it, replication cannot follow a virtual machine if it live-migrates between cluster nodes. Enabling integration services on the virtual machines addresses guest-OS/host integration rather than replication, adding a generic Windows Server server role and configuring a (non-existent, mistyped) ' fault domain ' for the cluster do not provide the Hyper-V Replica capability the requirement calls for.

Official Reference

Set up Hyper-V Replica for a Hyper-V failover cluster — https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/manage/set-up-hyper-v-replica

Detailed Explanation

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 the cutover of the source server ' s name/identity if a fully transparent migration is required. File Server Resource Manager only provides quota, screening, and reporting capabilities and does not migrate data or permissions, Server Manager is a general administration console with no dedicated share-migration workflow, and Storage Replica performs block-level volume replication rather than a share-and-permissions-preserving migration.

Official Reference

Storage Migration Service overview — https://learn.microsoft.com/en-us/windows-server/storage/storage-migration-service/overview

Detailed Explanation

Backing up a standalone Windows Server ' s files, folders, and system state directly to an Azure Recovery Services vault 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 physical or standalone server, native Windows Server Backup does not target an Azure Recovery Services vault on its own, and Storage Replica provides block-level volume replication rather than the point-in-time backup and retention the requirement calls for.

Official Reference

About the Azure Backup MARS agent — https://learn.microsoft.com/en-us/azure/backup/backup-azure-mars-troubleshoot

Official Reference

Adprep command reference — schema extension during domain controller promotion — https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/deploy/adprep-command-reference

Detailed Explanation

Setting up Azure Site Recovery for a Hyper-V cluster that is not managed by Virtual Machine Manager follows a fixed infrastructure-preparation order. An Azure Recovery Services vault must exist first, since it is the container that every later step registers against. A Hyper-V site is then created in that vault to represent the on-premises Hyper-V environment, because a Hyper-V host or cluster must belong to a site before its hosts can be registered. The Azure Site Recovery Provider is then installed on the Hyper-V hosts and registered to that site/vault, which is what actually connects the cluster nodes to Azure Site Recovery. Only once the hosts are registered can a replication policy be created and associated with the Hyper-V site, since a policy has nothing to attach to until the site and its registered hosts exist. Installing Azure Connected Machine agents is unrelated to Hyper-V VM replication (that agent is used for Azure Arc-enabled servers) and is not part of this workflow.

Official Reference

Set up disaster recovery for Hyper-V VMs without Virtual Machine Manager — https://learn.microsoft.com/en-us/azure/site-recovery/hyper-v-prepare-on-premises-tutorial

Detailed Explanation

Migrating APP3 and APP4, which run as virtual machines on the on-premises Cluster1 Hyper-V failover cluster, to Azure uses the Azure Migrate: Server Migration workflow for Hyper-V. That workflow requires an Azure Migrate project to be created in Azure first to serve as the container for the migration effort and its discovered assets, and then the Azure Migrate appliance -- a purpose-built VM/OVA image supplied by Azure Migrate -- to be imported onto (deployed to) the Hyper-V host or cluster so it can discover the VMs and orchestrate replication into Azure. A P2S VPN, a Configure Azure Network Adapter action, the Azure File Sync agent, and the Windows Server Migration Tools do not perform Hyper-V VM discovery or replication, and a premium block blob storage account, private endpoint, or VPN gateway are not the Azure-side resource that Azure Migrate itself requires to begin a migration project.

Official Reference

Migrate Hyper-V VMs to Azure with Azure Migrate — https://learn.microsoft.com/en-us/azure/migrate/tutorial-migrate-hyper-v

Detailed Explanation

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 potential location for the protected virtual machines after a live migration and must be able to track and replicate them. Cluster2 has four nodes, so a minimum of four Azure Site Recovery Provider installations -- one per node -- is required; installing it on only one node would leave replication unable to follow a VM if it moves to any of the other three nodes.

Official Reference

Set up disaster recovery for Hyper-V VMs — Provider installation on all cluster nodes — https://learn.microsoft.com/en-us/azure/site-recovery/hyper-v-prepare-on-premises-tutorial

Detailed Explanation

Storage Migration Service inventories the data, security descriptors, and both share- and NTFS-level permissions on a source file server such as Fileserver1, transfers that data to Fileserver2, and then performs a cutover that reassigns Fileserver1 ' s identity (computer name and IP address) to Fileserver2 -- which is exactly what allows the existing \\Fileserver1\Data UNC path used by the Chicago office application to keep working unchanged after migration. The Microsoft File Server Migration Toolkit and Windows Server Migration Tools are older, largely superseded utilities that do not provide this automated inventory-transfer-cutover workflow or UNC-path preservation, and File Server Resource Manager is a quota/file-screening and reporting feature, not a migration tool.

Official Reference

Storage Migration Service overview — https://learn.microsoft.com/en-us/windows-server/storage/storage-migration-service/overview

Detailed Explanation

For an Azure App Service web app to accept traffic addressed to https://www.fabrikam.com instead of only its default *.azurewebsites.net hostname, the custom domain www.fabrikam.com must be added and bound to WebApp1 -- this is what allows the app to actually handle requests for that hostname, and a deployment slot (used for staged rollout/swap) and a private endpoint (used for private, VNet-only connectivity) do not accomplish this. Once WEB1 and WEB2 are decommissioned, client traffic must be redirected to the new app: because DNS is what resolves www.fabrikam.com to an endpoint, the DNS record for that name is updated (typically to a CNAME pointing at the app ' s default hostname, alongside the required domain-verification TXT record) so that clients are pointed at WebApp1. Azure Front Door and Azure Traffic Manager are global routing/load-balancing services intended for multi-region or multi-endpoint scenarios and are unnecessary for redirecting a single custom domain to a single web app, and adding HTTP redirect rules on WEB1/WEB2 is not viable once those servers are decommissioned.

Official Reference

Map an existing custom DNS name to Azure App Service — https://learn.microsoft.com/en-us/azure/app-service/app-service-web-tutorial-custom-domain

Detailed Explanation

A Windows Server failover cluster requires one IP address per cluster node plus one additional IP address for the cluster ' s own network name resource (the cluster access point / cluster VIP). Cluster3 will contain two physical nodes (Node1 and Node2), so the minimum requirement is one address for Node1, one for Node2, and one for the cluster core resource itself -- three addresses in total.

Official Reference

Prerequisites for Failover Clustering — network and IP address requirements — https://learn.microsoft.com/en-us/windows-server/failover-clustering/failover-clustering-hardware-requirements

CORRECTED ANSWER: Install the PES service on: dc2.europe.fabrikam.com. Generate the encryption key on: admtcomputer.fabrikam.com.

Detailed Explanation

The Active Directory Migration Tool ' s Password Export Server (PES) service must be installed on a domain controller in the source domain -- here, europe.fabrikam.com, whose only listed domain controller is dc2.europe.fabrikam.com -- because PES needs direct, local access to the source domain ' s password data in order to export it during a SID-history/account migration. The AES encryption key used to protect that exported password data, by contrast, is generated on the machine running the ADMT console in the target domain (the admt key /option:create command), which in this environment is admtcomputer.fabrikam.com in the corp.fabrikam.com domain; the resulting key file is then copied to the source-domain PES host and supplied during the PES service installation there. aadc1.corp.fabrikam.com and dc1.corp.fabrikam.com are both target-domain (corp.fabrikam.com) hosts and are not appropriate locations to install PES, since PES specifically requires source-domain placement to access europe.fabrikam.com ' s password material.

Official Reference

Migrate passwords by using the Password Migration DLL and Password Export Server — https://learn.microsoft.com/en-us/microsoft-desktop-optimization-pack/admt/migrate-passwords-with-admt-guide

Detailed Explanation

BitLocker can only be enabled on a Cluster Shared Volume after the underlying disk has already been added to the cluster and converted to a CSV, because BitLocker on a CSV disk must be enabled while the disk is taken offline to cluster I/O. The supported sequence is: first add the disk resource to the cluster, then convert it to a CSV, then place the CSV disk in maintenance mode (which takes it offline to other cluster nodes so it can be safely encrypted), then enable BitLocker on the volume while it is in maintenance mode, and finally update the volume ' s BitLockerProtectorInfo property so that Failover Clustering registers the unlock protector and can automatically unlock the volume on every node after maintenance mode ends. Performing the steps in any other order either fails outright (BitLocker cannot be enabled on a CSV that is still online to the cluster) or leaves the other cluster nodes unable to bring the volume back online after encryption.

Official Reference

Add BitLocker Drive Encryption to a cluster disk — https://learn.microsoft.com/en-us/windows-server/failover-clustering/bitlocker

Detailed Explanation

Migrating a DHCP server ' s configuration and lease/reservation data with PowerShell follows a export/remove-then-add/import pattern. On the source server, DHCP1, Export-DhcpServer captures the existing scopes, leases, reservations, and options to a migration file, and Remove-DhcpServerInDC then unauthorizes DHCP1 in Active Directory so it stops servicing clients once the replacement is online (satisfying the requirement to prevent DHCP1 from continuing to hand out addresses). On the target server, DHCP2, Add-DhcpServerInDC authorizes the new server in AD DS, and Import-DhcpServer applies the exported configuration file so DHCP2 hands out the same address ranges together with the existing leases and reservations, meeting all three stated DHCP migration requirements.

Official Reference

Migrate DHCP server data by using PowerShell — https://learn.microsoft.com/en-us/windows-server/networking/technologies/dhcp/dhcp-mdb

Detailed Explanation

Server administrators can be prevented from modifying Windows Defender Firewall rules by configuring firewall policy through a Group Policy Object and applying the ' Windows Firewall: Protect all network connections ' / firewall policy settings, which override any local, administrator-configured rules on the domain-joined servers. Adaptive network hardening in Microsoft Defender for Cloud only recommends NSG rule tightening for Azure resources and does not manage or lock down on-premises Windows Firewall configuration, an NSG in Sub1 filters traffic at the Azure virtual network boundary and has no effect on the on-premises Chicago office servers, and an Azure Firewall policy governs an Azure Firewall appliance rather than the host-based Windows Defender Firewall running on each server.

Official Reference

Windows Firewall with Advanced Security Group Policy overview — https://learn.microsoft.com/en-us/windows/security/operating-system-security/network-security/windows-firewall/best-practices-configuring