Microsoft AZ-801: Hyper-V, Virtualização e Armazenamento — Guia de estudos

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

Faz parte do Microsoft Windows Server Hybrid Administrator Associate AZ-801 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Microsoft, ou faça testes cronometrados no ExamRoll.io.

Visão Geral

O Hyper-V e o armazenamento definido por software do Windows Server formam uma plataforma coesa para cargas de trabalho seguras, isoladas e de alta disponibilidade. O domínio do assunto exige a compreensão de como as malhas protegidas (guarded fabrics) protegem as VMs de locatários (tenants) contra os administradores da malha, como o Virtualization-Based Security (VBS) fortalece o SO com isolamento baseado em hardware, como a rede do Hyper-V impõe o isolamento e como a replicação, os checkpoints e o clustering se comportam sob carga e falha. Esta seção explica o modelo de segurança para VMs blindadas (shielded VMs) e o fortalecimento de hosts (host hardening), aprofunda-se nas construções de isolamento de rede, aborda a durabilidade por meio do Hyper-V Replica e da mecânica de checkpoints e finaliza com o Storage Spaces Direct (S2D), Cluster Shared Volumes (CSV) e o design de quorum no Failover Clustering.

Virtualização segura e proteção de cargas de trabalho

As VMs blindadas (Shielded VMs) protegem os ativos dos locatários contra o acesso da malha (fabric). O Host Guardian Service (HGS) atua como a âncora de confiança (trust anchor), fornecendo dois serviços: atestação (valida a saúde do host) e proteção de chave (libera as chaves para desbloquear o TPM virtual da VM). O HGS é implantado em uma floresta ou domínio dedicado e restrito (locked-down) para minimizar o risco de comprometimento. Existem dois modos de atestação:

Atestação confiável por TPM (TPM-trusted attestation): a garantia mais forte. Os hosts Hyper-V exigem TPM 2.0, Secure Boot, imposição de política de integridade de código e inicialização medida (measured boot). O HGS verifica os logs de inicialização medida e a identidade do host antes de liberar o protetor de chave para o vTPM da VM.
Atestação confiável por administrador (Admin-trusted - Active Directory): uma garantia mais leve. Os hosts provam confiança por meio da associação a grupos do AD e de metadados de host publicados. Nenhuma evidência de inicialização medida é avaliada, tornando o processo inicial (bootstrap) mais fácil, mas menos resistente a adulterações.

As funções de malha (fabric) e de locatário (tenant) são deliberadamente separadas. Os administradores da malha gerenciam hosts, clusters, armazenamento e redes, mas são impedidos de inspecionar os discos de VMs blindadas, anexar depuradores (debuggers) ou usar o console/PowerShell Direct. Os administradores do locatário constroem a VM, possuem as credenciais do SO e criam os dados de blindagem (shielding data) — um pacote selado contendo um arquivo de resposta de instalação autônoma (unattend answer file), um certificado RDP e chaves de guardião (guardian keys) — para controlar onde a VM pode ser executada. As VMs blindadas usam o BitLocker dentro do sistema operacional convidado (guest), ancorado em um vTPM, e somente os hosts protegidos (guarded hosts) atestados pelo HGS recebem os segredos necessários para a inicialização.

O Virtualization-Based Security (VBS) eleva a fronteira de segurança para acima do kernel, criando o Virtual Secure Mode (VSM). Com o VBS, o hypervisor impõe Níveis de Confiança Virtuais (Virtual Trust Levels - VTLs), isolando componentes sensíveis no VTL1 juntamente com um kernel seguro. Os recursos incluem:

Credential Guard: Os segredos do LSASS residem em um processo isolado (LSAISO) no VSM; o SO normal (VTL0) não consegue ler a memória diretamente.
Hypervisor-Enforced Code Integrity (HVCI): somente o código de kernel que atende aos requisitos modernos de assinatura e integridade é executado; ataques de DMA são mitigados com o IOMMU. Os requisitos incluem UEFI com Secure Boot, virtualização de CPU com SLAT (Intel EPT/AMD NPT) e IOMMU (Intel VT-d/AMD-Vi). Configure através da Política de Grupo (Group Policy): ative a opção

undefined

e, em seguida, habilite o Credential Guard e o HVCI; bloqueie a configuração com o Secure Boot para impedir a reversão (rollback). Juntamente com VMs de Geração 2, Secure Boot e vTPM, o VBS/VSM proporciona um forte fortalecimento (hardening) tanto para os hosts quanto para os sistemas convidados (guests).

Isolamento de rede, replicação e checkpoints do Hyper-V

Os comutadores virtuais do Hyper-V impõem isolamento de Camada 2/L3:

Comutadores externos se vinculam a uma NIC física (ou equipe SET) para alcançar a LAN. Use adaptadores separados para o tráfego de gerenciamento e de locatário (tenant) para evitar vazamento.
Comutadores internos conectam as VMs apenas ao host; não há uplink externo.
Comutadores privados conectam as VMs apenas entre si; não existe conectividade com o host nem com a LAN. As VLANs segmentam domínios L2. Atribua uma VLAN de acesso por NIC de VM para isolamento simples ou habilite o modo tronco (trunk) para transportar múltiplas VLANs para um appliance convidado (guest) ciente de VLAN. As Port ACLs em um adaptador de rede de VM adicionam filtragem stateless de 5 tuplas (IP de origem/destino, protocolo, porta) com direções (entrada/saída/ambas) e ações (permitir/negar/medir). As Port ACLs são impostas pelo host e úteis para isolamento local e controle de egresso rudimentar, mas não substituem um firewall completo.

O Hyper-V Replica fornece replicação assíncrona por VM sem a necessidade de armazenamento compartilhado. Um servidor é o primário (enviando logs de alterações) e outro é a réplica (recebendo deltas baseados em AVHDX). Os intervalos de replicação são de 30 segundos, 5 minutos ou 15 minutos. Opções de autenticação:

Kerberos (HTTP 80): simples para servidores ingressados em domínio; o tráfego não é criptografado. Use IPsec se a criptografia em trânsito for necessária.
Baseado em certificado (HTTPS 443): criptografado com TLS, funciona em redes não confiáveis e grupos de trabalho (workgroups). Planeje as aberturas de firewall adequadamente, configure a autorização na réplica e selecione o armazenamento da réplica. Tipos de failover:
Test Failover: inicializa uma VM de teste isolada na réplica sem impactar a proteção.
Planned Failover: transição orquestrada; o primário é desligado, os logs restantes são enviados, resultando em um RPO de perda zero de dados quando há conectividade saudável. Suporta replicação reversa para restabelecer a proteção.
Unplanned Failover: invocado quando o primário está indisponível; o RPO é igual ao último log recebido. A replicação estendida pode encaminhar alterações da réplica para um site terciário, aumentando a redundância.

Os checkpoints capturam um estado point-in-time para recuperação e dev/test. Checkpoints padrão (standard) salvam a memória da VM e o estado do dispositivo, permitindo reversões instantâneas, mas podendo interromper a consistência da aplicação. Checkpoints de produção (production) usam o VSS no convidado (Windows) ou a liberação do sistema de arquivos (Linux) para criar uma imagem consistente com a aplicação sem o estado da memória; são apropriados para fluxos de trabalho de backup e pontos de restauração de longa duração. O armazenamento é implementado como discos de diferenciação AVHDX encadeados ao VHDX base. Aplicar ou excluir um checkpoint mescla a cadeia de diferenciação de volta ao seu pai online; mesclagens grandes criam pressão de E/S (I/O), portanto, mantenha uma margem de capacidade (headroom) adequada e evite árvores profundas. Para controladores de domínio e aplicações distribuídas, os checkpoints de produção mitigam a reversão de USN e problemas relacionados; os checkpoints padrão são mais adequados para trabalhos de dev/test de curta duração.

Capacidades do host, virtualização aninhada e segurança de geração de VM

VMs de Geração 2 inicializam via UEFI, suportando Secure Boot e vTPM. O Secure Boot verifica os bootloaders em relação a um banco de dados confiável (use o modelo do Windows ou do Linux apropriado). O vTPM traz a semântica do TPM 2.0 para o convidado (guest), habilitando o BitLocker, o provisionamento do Windows Hello for Business e cenários de VMs blindadas (shielded VMs). Onde convidados mais antigos exigem BIOS ou dispositivos legados, as VMs de Geração 1 permanecem disponíveis, mas não possuem Secure Boot e vTPM.

A virtualização aninhada (nested virtualization) permite executar o Hyper-V dentro de uma VM. Os requisitos incluem uma CPU compatível (Intel VT-x/EPT ou AMD-V/NPT), Windows Server 2016 ou posterior no host e no convidado, e uma VM configurada com:

Memória estática (desabilitar a Memória Dinâmica).
Extensões de virtualização expostas (

undefined

MAC address spoofing para cenários onde os hosts internos fornecem NAT ou rede em ponte (bridged). Os casos de uso incluem a execução de contêineres isolados do Hyper-V, a construção de clusters de laboratório, o teste de failover e pipelines de CI que precisam de hypervisors. O Azure suporta virtualização aninhada em séries de VM específicas; garanta que a seleção do tamanho esteja alinhada com a necessidade de extensões de virtualização.

Armazenamento definido por software, comportamento do CSV e quórum

O Storage Spaces Direct agrega unidades conectadas localmente em um pool para todo o cluster usando SMB3, RDMA e a pilha de clustering. Os requisitos do cluster incluem a edição Windows Server Datacenter, nós ingressados no domínio com NICs homogêneas, rede de alta largura de banda e baixa latência (10/25/40 GbE; RDMA via iWARP ou RoCEv2 recomendado) e hardware validado. Os domínios de falha podem representar nós, chassis e racks; configurá-los melhora o comportamento de posicionamento e reparo e mitiga falhas correlacionadas. Os tipos de resiliência incluem:

Espelho de duas vias (mín. 2 domínios de falha): orientado para o desempenho, tolera uma falha.
Espelho de três vias (mín. 3 domínios de falha): maior durabilidade, tolera duas falhas.
Paridade dupla e paridade acelerada por espelho: eficientes em capacidade com desvantagens na latência de escrita; adequados para cargas de trabalho de arquivamento ou mistas com cache de write-back. As camadas de cache vinculam mídias mais rápidas (NVMe/SSD) como cache de leitura/escrita a unidades de capacidade (SSD/HDD). O cache de write-back absorve escritas aleatórias e as aglutina; o ajuste é feito por volume. Use o ReFS para alocação acelerada, clonagem de blocos e fluxos de integridade; ele combina bem com a semântica de desempenho e reparo do S2D. Uma testemunha (disco, compartilhamento de arquivos ou nuvem) é obrigatória para o S2D de dois nós para suportar a falha de um único nó.

Os Cluster Shared Volumes (CSV) expõem um namespace consistente (C:\ClusterStorage...) a todos os nós, permitindo acesso simultâneo a volumes NTFS/ReFS via CSVFS. As operações normais usam E/S direta, onde a coordenação de metadados ocorre sobre SMB, mas as leituras/escritas atingem os caminhos de armazenamento diretamente. A E/S redirecionada é ativada sob certas condições — manutenção, falha no caminho de armazenamento, operações de snapshot/backup ou quando um volume é pausado. Existem dois modos redirecionados:

E/S redirecionada do sistema de arquivos: o tráfego atravessa o SMB até o coordenador.
E/S redirecionada de bloco: mais eficiente para cargas de trabalho com uso intensivo de blocos, quando necessário. O cache do CSV é um cache de leitura na memória do host que beneficia cargas de trabalho com predominância de leitura, como discos pais VHDX e cadeias de diferenciação. Configure o cache no nível do cluster, habilitando-o e definindo um tamanho de cache de blocos apropriado para a RAM disponível, deixando uma margem de segurança para o host e as cargas de trabalho. Monitore as taxas de acerto do cache e ajuste de forma conservadora para evitar o esgotamento da memória do sistema.

O quórum do Cluster de Failover determina a atividade do cluster. Os modos incluem:

Maioria de Nós: número ímpar de nós; sobrevive a floor((N-1)/2) falhas.
Maioria de Nós e Disco: adiciona uma testemunha de disco que participa da votação; bom quando há armazenamento compartilhado.
Maioria de Nós e Compartilhamento de Arquivos: usa uma testemunha de compartilhamento de arquivos hospedada fora do domínio de falha do cluster.
Testemunha de Nuvem: utiliza uma conta do Azure Storage para uma testemunha leve e de alta disponibilidade, ideal para implantações multi-site e de borda. Clusters modernos usam quórum dinâmico e testemunha dinâmica: os votos são ajustados em tempo real para maximizar a tolerância a falhas, e a testemunha ganha ou perde um voto automaticamente para evitar empates. Aplique pesos aos nós para excluir nós não confiáveis da votação quando necessário. Para clusters de dois nós, sempre configure uma testemunha (compartilhamento de arquivos ou nuvem) para permitir a sobrevivência à falha de um único nó.

Cenário de Problema Prático

Na Siemens, a equipe de OT/TI precisa modernizar um pequeno site de borda que hospeda três VMs do Windows Server que executam telemetria de manufatura. Eles devem isolar o tráfego entre as redes de OT e corporativa, proteger as credenciais nos hosts e alcançar resiliência no nível do site sem armazenamento compartilhado.

Construir um cluster de failover Hyper-V de dois nós com Storage Spaces Direct

Por quê: O S2D elimina a necessidade de uma SAN, fornece espelhamento entre nós para durabilidade e se integra com o Failover Clustering para failover automático. Uma testemunha de compartilhamento de arquivos ou de nuvem é adicionada para que o cluster de dois nós possa suportar a falha de um nó.

Habilitar VBS com Credential Guard e HVCI em ambos os hosts

Por quê: O VBS/VSM isola as credenciais do LSASS e impõe a integridade do código do kernel, reduzindo o risco de movimento lateral de malware em um ambiente com dispositivos de OT mistos.

Usar VMs de Geração 2 com Secure Boot e vTPM

Por quê: O UEFI Secure Boot resiste à adulteração por boot-kits; o vTPM habilita o BitLocker no sistema operacional convidado para dados em repouso. Isso se alinha ao requisito da Siemens de proteger configurações de telemetria sensíveis contra roubo em locais remotos.

Criar um comutador Hyper-V externo para cada uplink físico e segmentar com VLANs e ACLs de Porta

Por quê: As VLANs separam o tráfego de OT e corporativo na mesma malha física, enquanto as ACLs de Porta fornecem filtros granulares e impostos pelo host para impedir a comunicação leste-oeste entre as camadas sem implantar virtual appliances completos na borda.

Configurar o Hyper-V Replica do site de borda para um servidor de réplica em um datacenter central via HTTPS

Por quê: A autenticação baseada em certificado criptografa a replicação de ponta a ponta através de links WAN não confiáveis. O failover planejado suporta janelas de manutenção; o failover não planejado oferece DR quando o site de borda está offline. A replicação reversa reprotege após o failback.

Padronizar o uso apenas de checkpoints de produção

Por quê: Os checkpoints de produção geram pontos de restauração consistentes com a aplicação sem o estado da memória, apropriados para a pilha de telemetria e mais seguros ao longo do tempo do que os checkpoints padrão que capturam memória volátil.

Habilitar o cache do CSV com dimensionamento conservador

Por quê: Dashboards de telemetria com predominância de leitura se beneficiam de blocos pais em cache, melhorando a capacidade de resposta sem consumir RAM excessiva em nós de borda com recursos limitados.

Este projeto usa S2D para alta disponibilidade, VBS/vTPM/Secure Boot para confiança reforçada, VLANs e ACLs de Porta para isolamento determinístico e Hyper-V Replica para resiliência de site — equilibrando segurança, desempenho e operacionalidade em um ambiente de borda com recursos limitados.

← Atualização e Gerenciamento de Patches do Windows Server · Todos os domínios · Recuperação de Desastres e Continuidade de Negócios →

Pratique estas questões → · Prática cronometrada no ExamRoll.io →