Microsoft AZ-801: Hyper-V, Virtualization and Storage — Study Guide

By Laurynas Brazys · 7 August 2026 · #microsoft #az-801 #certification #exam-prep #study-guide

Part of the Microsoft Windows Server Hybrid Administrator Associate AZ-801 — Study Guide. Practice with verified answers in the Microsoft exam hub, or take timed practice tests on ExamRoll.io.

Overview

Hyper‑V and Windows Server software‑defined storage form a cohesive platform for secure, isolated, and highly available workloads. Mastery requires understanding how guarded fabrics protect tenant VMs from fabric administrators, how Virtualization‑Based Security (VBS) hardens the OS with hardware‑rooted isolation, how Hyper‑V networking enforces isolation, and how replication, checkpoints, and clustering behave under load and failure. This section explains the security model for shielded VMs and host hardening, dives into network isolation constructs, covers durability via Hyper‑V Replica and checkpoint mechanics, and finishes with Storage Spaces Direct (S2D), Cluster Shared Volumes (CSV), and quorum design in Failover Clustering.

Secure virtualization and workload protection

Shielded VMs protect tenant assets from fabric access. Host Guardian Service (HGS) operates as the trust anchor, delivering two services: attestation (validates host health) and key protection (releases keys to unlock the VM’s virtual TPM). HGS is deployed in a dedicated, locked‑down forest or domain to minimize compromise risk. Two attestation modes exist:

TPM‑trusted attestation: strongest assurance. Hyper‑V hosts require TPM 2.0, Secure Boot, code‑integrity policy enforcement, and measured boot. HGS verifies measured boot logs and host identity before releasing the key protector to the VM’s vTPM.
Admin‑trusted (Active Directory) attestation: lighter assurance. Hosts prove trust by AD group membership and published host metadata. No measured boot evidence is evaluated, so it’s easier to bootstrap but less tamper‑resistant.

Fabric and tenant roles are deliberately separated. Fabric administrators manage hosts, clusters, storage, and networking but are prevented from inspecting shielded VM disks, attaching debuggers, or using console/PowerShell Direct. Tenant administrators build the VM, own OS credentials, and create shielding data (a sealed package containing an unattend answer file, RDP certificate, and guardian keys) to control where the VM may run. Shielded VMs use BitLocker inside the guest, anchored in a vTPM, and only guarded hosts attested by HGS receive the secrets needed to boot.

Virtualization‑Based Security (VBS) raises the security boundary above the kernel by creating Virtual Secure Mode (VSM). With VBS, the hypervisor enforces Virtual Trust Levels (VTLs), isolating sensitive components in VTL1 alongside a secure kernel. Features include:

Credential Guard: LSASS secrets live in an isolated process (LSAISO) in VSM; the normal OS (VTL0) cannot read memory directly.
Hypervisor‑Enforced Code Integrity (HVCI): only kernel code that meets modern signing and integrity requirements executes; DMA attacks are mitigated with IOMMU. Requirements include UEFI with Secure Boot, CPU virtualization with SLAT (Intel EPT/AMD NPT), and IOMMU (Intel VT‑d/AMD‑Vi). Configure through Group Policy: Turn On Virtualization Based Security, then enable Credential Guard and HVCI; lock the configuration with Secure Boot to prevent rollback. Together with Generation 2 VMs, Secure Boot, and vTPM, VBS/VSM provides strong hardening both for hosts and guests.

Hyper‑V network isolation, replication, and checkpoints

Hyper‑V virtual switches enforce Layer‑2/L3 isolation:

External switches bind to a physical NIC (or SET team) to reach the LAN. Use separate adapters for management and tenant traffic to avoid bleed‑over.
Internal switches connect VMs to the host only; no external uplink.
Private switches connect VMs to each other only; neither host nor LAN connectivity exists. VLANs segment L2 domains. Assign an access VLAN per VM NIC for simple isolation or enable trunk mode to carry multiple VLANs to a VLAN‑aware guest appliance. Port ACLs on a VM network adapter add stateless 5‑tuple filtering (source/destination IP, protocol, port) with directions (in/out/both) and actions (allow/deny/meter). Port ACLs are host‑enforced and useful for local isolation and rudimentary egress control, but they are not a substitute for a full firewall.

Hyper‑V Replica provides asynchronous per‑VM replication with no shared storage requirement. A server is the primary (sending change logs) and another is the replica (receiving AVHDX‑based deltas). Replication intervals are 30 seconds, 5 minutes, or 15 minutes. Authentication options:

Kerberos (HTTP 80): simple for domain‑joined servers; traffic is not encrypted. Use IPsec if encryption in transit is required.
Certificate‑based (HTTPS 443): TLS‑encrypted, works across untrusted networks and workgroups. Plan firewall openings accordingly, configure authorization on the replica, and select replica storage. Failover types:
Test Failover: boots an isolated test VM on the replica without impacting protection.
Planned Failover: orchestrated switchover; the primary is shut down, remaining logs are sent, yielding zero‑data‑loss RPO when healthy connectivity exists. Supports reverse replication to re‑establish protection.
Unplanned Failover: invoked when the primary is unavailable; RPO equals the last received log. Extended replication can forward changes from the replica to a tertiary site, increasing redundancy.

Checkpoints capture a point‑in‑time state for recovery and dev/test. Standard checkpoints save VM memory and device state, enabling instant rollbacks but potentially disrupting app consistency. Production checkpoints use in‑guest VSS (Windows) or file system flush (Linux) to create an application‑consistent image without memory state; they are appropriate for backup workflows and long‑lived restore points. Storage is implemented as AVHDX differencing disks chained to the base VHDX. Applying or deleting a checkpoint merges the differencing chain back into its parent online; large merges create I/O pressure, so maintain adequate headroom and avoid deep trees. For domain controllers and distributed apps, production checkpoints mitigate USN rollback and related issues; standard checkpoints are best confined to short‑lived dev/test work.

Host capabilities, nested virtualization, and VM generation security

Generation 2 VMs boot via UEFI, supporting Secure Boot and vTPM. Secure Boot verifies bootloaders against a trusted database (use the Windows or appropriate Linux template). vTPM brings TPM 2.0 semantics to the guest, enabling BitLocker, Windows Hello for Business provisioning, and shielded VM scenarios. Where older guests require BIOS or legacy devices, Generation 1 VMs remain available but lack Secure Boot and vTPM.

Nested virtualization enables Hyper‑V inside a VM. Requirements include a compatible CPU (Intel VT‑x/EPT or AMD‑V/NPT), Windows Server 2016 or later on host and guest, and a VM configured with:

Static memory (disable Dynamic Memory).
Exposed virtualization extensions (Set‑VMProcessor -ExposeVirtualizationExtensions $true).
MAC address spoofing for scenarios where inner hosts provide NAT or bridged networking. Use cases include running Hyper‑V isolated containers, building lab clusters, testing failover, and CI pipelines that need hypervisors. Azure supports nested virtualization on specific VM series; ensure size selection aligns with the need for virtualization extensions.

Software‑defined storage, CSV behavior, and quorum

Storage Spaces Direct aggregates locally attached drives into a cluster‑wide pool using SMB3, RDMA, and the clustering stack. Cluster requirements include Windows Server Datacenter edition, domain‑joined nodes with homogeneous NICs, high‑bandwidth low‑latency networking (10/25/40 GbE; RDMA via iWARP or RoCEv2 recommended), and validated hardware. Fault domains can represent nodes, chassis, and racks; configuring them improves placement and repair behavior and mitigates correlated failures. Resiliency types include:

Two‑way mirror (min 2 fault domains): performance‑oriented, tolerates one failure.
Three‑way mirror (min 3 fault domains): higher durability, tolerates two failures.
Dual parity and mirror‑accelerated parity: capacity‑efficient with trade‑offs in write latency; suitable for archival or mixed workloads with write‑back cache. Caching tiers bind faster media (NVMe/SSD) as read/write cache to capacity drives (SSD/HDD). Write‑back cache absorbs random writes and coalesces them; tuning is per‑volume. Use ReFS for accelerated allocation, block cloning, and integrity streams; it pairs well with S2D’s performance and repair semantics. A witness (disk, file share, or cloud) is mandatory for two‑node S2D to sustain a single node failure.

Cluster Shared Volumes (CSV) expose a consistent namespace (C:\ClusterStorage...) to all nodes, enabling concurrent access to NTFS/ReFS volumes via CSVFS. Normal operations use direct I/O, where metadata coordination occurs over SMB, but reads/writes hit storage paths directly. Redirected I/O engages under certain conditions—maintenance, storage path failure, snapshot/backup operations, or when a volume is paused. Two redirected modes exist:

File system redirected I/O: traffic traverses SMB to the coordinator.
Block redirected I/O: more efficient for block‑heavy workloads when necessary. CSV cache is a host memory read cache that benefits read‑dominated workloads such as VHDX parent disks and differencing chains. Configure the cache at the cluster level by enabling it and setting a block cache size appropriate for available RAM, leaving headroom for the host and workloads. Monitor cache hit ratios and adjust conservatively to avoid starving system memory.

Failover Cluster quorum determines cluster liveness. Modes include:

Node Majority: odd number of nodes; survives floor((N‑1)/2) failures.
Node and Disk Majority: adds a disk witness that participates in voting; good when shared storage is present.
Node and File Share Majority: uses a file share witness hosted outside the cluster’s failure domain.
Cloud Witness: leverages an Azure Storage account for a lightweight, highly available witness ideal for multi‑site and edge deployments. Modern clusters use dynamic quorum and dynamic witness: votes are adjusted in real time to maximize tolerance for failures, and the witness automatically gains or loses a vote to avoid ties. Apply node weights to exclude unreliable nodes from voting when needed. For two‑node clusters, always configure a witness (file share or cloud) to allow survival of a single node failure.

Practical Problem Scenario

At Siemens, the OT/IT team needs to modernize a small edge site hosting three Windows Server VMs that run manufacturing telemetry. They must isolate traffic between OT and corporate networks, protect credentials on the hosts, and achieve site‑level resiliency without shared storage.

Build a two‑node Hyper‑V failover cluster with Storage Spaces Direct

Why: S2D eliminates the need for a SAN, provides mirroring across nodes for durability, and integrates with Failover Clustering for automatic failover. A file share or cloud witness is added so the two‑node cluster can sustain one node failure.

Enable VBS with Credential Guard and HVCI on both hosts

Why: VBS/VSM isolates LSASS credentials and enforces kernel code integrity, reducing risk from malware lateral movement in an environment with mixed OT devices.

Use Generation 2 VMs with Secure Boot and vTPM

Why: UEFI Secure Boot resists boot‑kit tampering; vTPM enables BitLocker in‑guest for data at rest. This aligns with Siemens’ requirement to protect sensitive telemetry configurations from theft at remote locations.

Create an external Hyper‑V switch for each physical uplink and segment with VLANs and Port ACLs

Why: VLANs separate OT and corporate traffic on the same physical fabric, while Port ACLs provide fine‑grained, host‑enforced filters to prevent east‑west chatter between tiers without deploying full virtual appliances at the edge.

Configure Hyper‑V Replica from the edge site to a central datacenter replica server over HTTPS

Why: Certificate‑based authentication encrypts replication end‑to‑end across untrusted WAN links. Planned failover supports maintenance windows; unplanned failover offers DR when the edge site is offline. Reverse replication re‑protects after failback.

Standardize on production checkpoints only

Why: Production checkpoints yield application‑consistent restore points without memory state, appropriate for the telemetry stack and safer over time than standard checkpoints that capture volatile memory.

Enable CSV cache with conservative sizing

Why: Read‑mostly telemetry dashboards benefit from cached parent blocks, improving responsiveness without consuming excessive RAM on constrained edge nodes.

This design uses S2D for high availability, VBS/vTPM/Secure Boot for hardened trust, VLANs and Port ACLs for deterministic isolation, and Hyper‑V Replica for site resiliency—balancing security, performance, and operability in a resource‑limited edge footprint.

← Windows Server Update and Patch Management · All domains · Disaster Recovery and Business Continuity →

Practice these questions → · Timed practice on ExamRoll.io →