Microsoft AZ-104: Rede Virtual do Azure — Guia de estudos

By Laurynas Brazys · 6 August 2026 · #microsoft #az-104 #certification #exam-prep #study-guide

Faz parte do Microsoft Azure Administrator Associate AZ-104 — 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 Azure Virtual Networking estabelece a malha de data center definida por software para cargas de trabalho IaaS e PaaS. Você projeta um plano de endereçamento com CIDR, divide sub-redes alinhadas aos limites de confiança, protege os fluxos leste-oeste e norte-sul com Network Security Groups (NSGs) e Azure Firewall, conecta ambientes usando VNet peering, VPN Gateway ou ExpressRoute, molda o tráfego com rotas definidas pelo usuário e fornece resolução de nomes confiável com o Azure DNS. Configurar essas construções corretamente permite designs hub-and-spoke escaláveis, acesso seguro a PaaS por meio de Private Endpoints e um roteamento previsível que atende aos requisitos de conformidade e desempenho.

Endereçamento, Segmentação e Política (VNets, Sub-redes, NSGs, ASGs, UDR)

Uma rede virtual define um ou mais espaços de endereço RFC1918 que não se sobrepõem, usando a notação CIDR (por exemplo, 10.0.0.0/16). Você pode adicionar prefixos de endereço adicionais posteriormente, se não houver conflitos com redes emparelhadas (peers). As sub-redes segmentam a VNet em blocos roteáveis (por exemplo, 10.0.1.0/24 para web, 10.0.2.0/24 para app). Reserve uma GatewaySubnet dedicada para gateways de VPN/ExpressRoute; aloque um espaço generoso (pelo menos /27) para evitar futuros limites de escalabilidade. A alocação de IP é dinâmica por padrão; você pode definir IPs privados estáticos em NICs quando necessário.

As rotas de sistema padrão permitem o tráfego intra-VNet e enviam 0.0.0.0/0 para a internet (sujeito à presença de um IP público). As rotas definidas pelo usuário (UDR) substituem esses padrões no nível da sub-rede. Crie uma tabela de rotas e associe-a a uma sub-rede; as entradas incluem:

Próximo salto (Next hop): Virtual appliance (o IP de um NVA na mesma VNet), Virtual network gateway (para direcionar para o ambiente on-premises via VPN/ExpressRoute), Internet (para forçar a saída para a internet) ou None (blackhole).
Tunelamento forçado (Forced tunneling): Envie 0.0.0.0/0 para um virtual network gateway para forçar todo o tráfego de saída para o ambiente on-premises, ou para um NVA/Azure Firewall para controle de saída centralizado. Se estiver usando BGP com um gateway que anuncia uma rota padrão, considere desabilitar a propagação de rota do gateway em sub-redes específicas para evitar a seleção de caminho não intencional.

NSGs aplicam políticas stateful de L3–L4 em NICs ou sub-redes; ambos os escopos podem ser usados simultaneamente e o tráfego deve ser permitido por todos os NSGs aplicáveis. As regras são avaliadas por prioridade (100–4096; números mais baixos primeiro) e direção (entrada/saída). As regras padrão incluem:

Entrada (Inbound): AllowVnetInBound (65000), AllowLoadBalancerInBound (65001), DenyAllInBound (65500)
Saída (Outbound): AllowVnetOutBound (65000), AllowInternetOutBound (65001), DenyAllOutBound (65500) Substitua os padrões com regras personalizadas de maior precedência (menor número). Use service tags (por exemplo, Internet, AzureLoadBalancer, Storage) para simplificar a manutenção, e IP Groups para listas de endereços reutilizáveis.

Application Security Groups (ASGs) desacoplam o endereçamento IP da política. Atribua NICs a ASGs que representam funções (por exemplo, Web, App, DB) e referencie esses ASGs nas regras do NSG. Isso permite alterações na política sem mexer em IPs ou sub-redes e auxilia na segmentação consistente baseada em função dentro de uma VNet.

Opções de Conectividade: Peering, VPN Gateway e ExpressRoute

O VNet peering conecta VNets pela rede de backbone da Microsoft com baixa latência e alta largura de banda. O peering local ocorre dentro de uma região; o peering global abrange várias regiões. O peering não é transitivo e exige espaços de endereço que não se sobreponham. Flags principais:

Allow virtual network access (Permitir acesso à rede virtual) habilita a conectividade roteada entre os peers.
Allow forwarded traffic (Permitir tráfego encaminhado) permite que o tráfego encaminhado por NVAs atravesse o peering.
Use remote gateways (Usar gateways remotos) permite que uma VNet use um gateway de VPN/ER em um “hub” com peering. O hub deve ter a opção Allow gateway transit (Permitir trânsito de gateway) habilitada. Uma VNet pode usar gateways remotos de apenas um peer. As VNets com peering não recebem automaticamente as rotas de cliente P2S; os usuários finais devem instalar configurações de cliente VPN atualizadas que incluam as rotas para os novos spokes.

O Azure VPN Gateway fornece túneis IPSec/IKE:

Site-to-site (S2S) conecta dispositivos VPN on-premises ao Azure; use VPN baseada em rota (route-based) (IKEv2) para a maioria dos cenários, especialmente com BGP e múltiplos túneis.
Point-to-site (P2S) permite que clientes individuais (Windows, macOS, Linux) se conectem usando OpenVPN, IKEv2 ou SSTP. A configuração do cliente contém rotas estáticas para os prefixos do Azure; faça o download novamente quando os espaços de endereço mudarem ou quando você adicionar spokes alcançáveis atrás de um hub.
VNet-to-VNet usa S2S dentro de regiões/tenants do Azure, exigindo endereços que não se sobreponham. É útil quando o peering não é possível (por exemplo, entre tenants com limites administrativos).
SKUs: Prefira VpnGw1–VpnGw5 (e as variantes AZ para redundância de zona). O SKU Basic é legado e carece de recursos (sem IKEv2/BGP). O tipo “route-based” (baseado em rota) suporta P2S, BGP e ativo-ativo. O tipo “policy-based” (baseado em política) é limitado (apenas S2S, sem BGP).
O BGP anuncia prefixos dinamicamente, suporta trânsito através de múltiplos túneis e simplifica o failover de rotas. As regras de VPN NAT podem traduzir prefixos on-prem/Azure sobrepostos quando isso for inevitável.

O ExpressRoute oferece conectividade privada, com garantia de SLA, por meio do circuito de um parceiro até a borda da rede da Microsoft:

Um circuito é provisionado pelo provedor (largura de banda, medição, SKU) e vinculado à sua assinatura por meio de uma chave de serviço (service key). A redundância é nativa: cada circuito expõe conexões duplas primária/secundária; seu roteador deve estabelecer sessões BGP duplas para alta disponibilidade (HA).
Tipos de peering:
- O Private peering transporta tráfego privado RFC1918 para VNets por meio de um gateway de rede virtual do ExpressRoute (ErGw1AZ–ErGw3AZ). Suporta BGP, failover rápido e, opcionalmente, o FastPath para aceleração do plano de dados.
- O Microsoft peering expõe serviços públicos da Microsoft (por exemplo, Storage, SQL, Microsoft 365) por meio de IPs públicos com filtros de rota (route filters). Use para endpoints voltados para a internet, mantendo-se fora da internet pública. O Microsoft 365 requer uma análise adicional.
Use o ExpressRoute Global Reach para interconectar sites on-prem por meio do backbone da Microsoft. Para tunelamento forçado (forced tunneling), anuncie uma rota padrão sobre o private peering ou combine com UDRs/Azure Firewall para uma saída seletiva.

Coexistência: Uma VNet pode ter gateways de VPN e de ExpressRoute usando a mesma GatewaySubnet; use o trânsito de gateway e UDRs para controlar os fluxos. O ExpressRoute é preferível para o tráfego corporativo de estado estável; a VPN serve como backup ou para o alcance de filiais/pequenos escritórios.

Resolução de Nomes e Acesso Seguro a PaaS (Azure DNS, Endpoints)

O Azure DNS hospeda zonas públicas para que seus registros voltados para a internet residam na plataforma de DNS global do Azure com alta disponibilidade. Para resolução dentro da VNet, as Azure DNS Private Zones fornecem um serviço de nomes com split-horizon. Vincule VNets a uma zona privada para habilitar a resolução; opcionalmente, habilite o registro automático (auto-registration) para que os registros A de VMs se registrem e atualizem automaticamente após alterações no IP da NIC. Para resolução de nomes híbrida e encaminhamento condicional entre o Azure e o ambiente on-premises, implante um Azure DNS Private Resolver com endpoints de entrada/saída (inbound/outbound) e conjuntos de regras que encaminham domínios selecionados (por exemplo, corp.contoso.com para o DNS on-prem, ou privatelink.* de volta para o Azure).

Os Service Endpoints estendem a identidade da sua VNet para serviços selecionados do Azure (por exemplo, Storage, SQL) pela rede de backbone da Microsoft, mantendo o IP público do serviço. No firewall do PaaS, restrinja o acesso a uma VNet/sub-rede específica. Eles são fáceis de habilitar por sub-rede e por serviço, não exigem alterações de DNS e funcionam bem para cenários simples, apenas no Azure. No entanto, o recurso ainda possui um IP público e não pode ser endereçado privadamente a partir do ambiente on-prem sem passar pelo endpoint público.

Os Private Endpoints colocam uma NIC com um IP privado da sua sub-rede no recurso PaaS por meio do Private Link. O tráfego permanece na rede privada, permitindo um controle refinado contra a exfiltração de dados e o acesso a partir do ambiente on-prem via VPN/ExpressRoute. A configuração correta de DNS é essencial: substitua o FQDN público do recurso para que ele resolva para seu FQDN privatelink, que aponta para o seu IP privado. Use zonas de DNS Privado do Azure (Azure Private DNS zones) (por exemplo, privatelink.blob.core.windows.net) vinculadas às VNets. Escolha os Private Endpoints quando precisar de endereçamento verdadeiramente privado, acesso entre ambientes (cross-premises) e controles de saída rigorosos.

Azure Firewall e Governança Centralizada de Saída/Entrada (Egress/Ingress)

O Azure Firewall é um firewall stateful e nativo da nuvem que escala elasticamente e fornece política central para designs hub-and-spoke. Implante-o em uma AzureFirewallSubnet dedicada. Para cenários de túnel forçado, adicione a AzureFirewallManagementSubnet para que o tráfego de gerenciamento use a internet enquanto o tráfego de dados segue sua rota padrão.

Os tipos de coleção de regras são aplicados nesta ordem e pela prioridade da coleção de regras:

Regras de DNAT traduzem IPs/portas públicos de entrada no firewall para endereços privados (por exemplo, mapear o IP público do firewall:443 para uma VM web). Combine com NSGs na sub-rede de destino para impor o menor privilégio.
Regras de rede filtram o tráfego L3–L4 (IPs de origem/destino, protocolos, portas). Use para protocolos não-HTTP(S) e para controlar fluxos de saída/intra-spoke.
Regras de aplicativo controlam a saída HTTP/S por FQDN ou tags de FQDN (por exemplo, WindowsUpdate). O SKU Premium adiciona inspeção de TLS e IDPS para filtragem profunda de HTTP(S). A inteligência contra ameaças (Threat intelligence) pode ser definida como Alertar (Alert) ou Negar (Deny) para agir sobre IPs/domínios maliciosos conhecidos. Combine o Azure Firewall com UDRs (0.0.0.0/0 para o firewall como dispositivo virtual) para centralizar a saída (egress); permita o tráfego encaminhado no emparelhamento para os spokes. Envie logs para o Log Analytics para auditoria e análise, e use hierarquias de políticas/Azure Firewall Manager para padronizar em escala.

Cenário de Problema Prático

A Adobe precisa modernizar uma rede híbrida: um hub seguro no Azure deve fornecer saída centralizada para a internet, conectividade on-prem com alta disponibilidade, acesso privado ao Storage e SQL, e resolução de nomes previsível entre o Azure e os data centers. Desenvolvedores remotos também precisam de acesso P2S a todos os spokes.

Projetar o espaço de endereço e a segmentação

Crie a VNet do Hub 10.0.0.0/16 com as sub-redes: AzureFirewallSubnet 10.0.0.0/26, GatewaySubnet 10.0.0.64/27, SharedServices 10.0.1.0/24. Crie VNets Spoke para Apps 10.1.0.0/16 e Dados 10.2.0.0/16.
Justificativa: CIDRs não sobrepostos permitem o emparelhamento (peering) e o crescimento futuro; sub-redes dedicadas atendem aos requisitos da plataforma e simplificam o escopo de UDRs/NSGs.

Estabelecer a conectividade hub-and-spoke

Faça o emparelhamento (peer) Hub↔Apps e Hub↔Dados com as opções “Permitir acesso à rede virtual” (Allow virtual network access) e “Permitir tráfego encaminhado” (Allow forwarded traffic). No hub, defina “Permitir trânsito de gateway” (Allow gateway transit); nos spokes, defina “Usar gateways remotos” (Use remote gateways).
Justificativa: Centraliza os fluxos norte-sul através do gateway/firewall do hub, permitindo ao mesmo tempo o tráfego leste-oeste através do hub, evitando a complexidade de uma topologia em malha (mesh).

Fornecer conectividade on-prem privada e redundante

Contrate um circuito ExpressRoute (Emparelhamento Privado) através de um provedor; configure sessões BGP duplas. Implante um gateway de rede virtual ExpressRoute (ErGw2AZ) na GatewaySubnet do hub e vincule o circuito.
Justificativa: Conectividade privada com suporte de SLA, com redundância integrada e um gateway com redundância de zona, atende às necessidades empresariais de alta disponibilidade (HA) e desempenho.

Centralizar a saída (egress) e proteger as cargas de trabalho

Implante o Azure Firewall Standard na AzureFirewallSubnet. Crie uma UDR em cada sub-rede spoke: 0.0.0.0/0 com próximo salto (next hop) do tipo Dispositivo virtual (Virtual appliance) → IP privado do firewall. Adicione NSGs aos spokes permitindo apenas as portas necessárias para o firewall e o tráfego intra-VNet.
Justificativa: O Azure Firewall + UDRs impõem uma política de saída consistente, registro de logs e inteligência contra ameaças; os NSGs fornecem microssegmentação no nível da sub-rede/NIC.

Proteger PaaS com acesso verdadeiramente privado

Crie Private Endpoints para o Storage e o SQL no spoke de Dados. Vincule as zonas de DNS Privado do Azure (privatelink.blob.core.windows.net, privatelink.database.windows.net) ao Hub e aos Spokes. Desabilite o acesso da rede pública nos recursos PaaS.
Justificativa: Os Private Endpoints eliminam a exposição pública e permitem o acesso do ambiente on-prem via ExpressRoute; o DNS Privado do Azure garante a resolução de nomes correta.

Implementar resolução de nomes híbrida e encaminhamento condicional

Implante o Azure DNS Private Resolver no hub com endpoints de entrada e saída. Crie regras para encaminhar consultas de corp.adobe.com para o DNS on-prem e resolver as zonas privatelink dentro do Azure.
Justificativa: Fornece DNS determinístico e de horizonte dividido (split-horizon) entre o Azure e o ambiente on-prem, sem a necessidade de VMs de DNS personalizadas.

Habilitar o acesso de desenvolvedores remotos a todos os spokes

Configure uma VPN P2S no VPN Gateway do hub em coexistência com o ExpressRoute. Distribua o perfil do cliente VPN. Após adicionar novos spokes, baixe novamente o pacote do cliente para que as rotas para 10.1.0.0/16 e 10.2.0.0/16 sejam incluídas.
Justificativa: O P2S baseado no hub simplifica as operações e, com as rotas do cliente atualizadas e o trânsito de gateway do emparelhamento, oferece aos usuários alcançabilidade a todos os spokes.

Reforçar a segurança com ASGs e NSGs

Atribua NICs a ASGs (Web, App, DB) e implemente regras de NSG permitindo Web→App (TCP 443), App→DB (TCP 1433) por ASG, negando todo o resto. Mantenha as regras padrão quando apropriado.
Justificativa: A política baseada em função (role-based) escala sem gerenciamento de IPs e impõe o princípio do menor privilégio.

Esta arquitetura atende aos requisitos da Adobe com redundância do ExpressRoute, governança centralizada do Azure Firewall, acesso privado a PaaS e DNS coerente, garantindo ao mesmo tempo que usuários remotos e sistemas on-prem possam alcançar com segurança todas as cargas de trabalho através do hub.

← Máquinas Virtuais do Azure e Computação · Todos os domínios · Balanceamento de Carga do Azure e Gerenciamento de Tráfego →

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