Microsoft Azure Network Engineer Associate
Última revisão: maio de 2026
Uma referência rápida dos padrões arquiteturais que o exame AZ-700 avalia. Leia de cima a baixo ou pule para uma seção.
Conectar recursos entre VNets em diferentes assinaturas ou regiões de forma privada.
Configurar o emparelhamento de VNet entre as redes virtuais.
Por quê: Mantém o tráfego no backbone da Microsoft. O emparelhamento de VNet é não-transitivo; o emparelhamento direto é necessário para a comunicação (A->B, B->C != A->C).
Projetar espaços de endereço de VNet para conectividade futura.
Atribuir blocos CIDR exclusivos e não sobrepostos a cada VNet.
Por quê: O emparelhamento de VNet requer espaços de endereço não sobrepostos. Planeje o crescimento para evitar a re-arquitetura.
Calcular o tamanho de sub-rede necessário para um número específico de hosts.
Usar notação CIDR que fornece os hosts necessários + 5 endereços IP reservados para o Azure.
Por quê: O Azure reserva os quatro primeiros e o último endereço IP em cada sub-rede. Uma /24 (256 IPs) fornece apenas 251 IPs utilizáveis.
Implantar serviços como Azure Firewall, Gateway ou Bastion.
Criar sub-redes dedicadas com nomes específicos (por exemplo, AzureFirewallSubnet, GatewaySubnet, AzureBastionSubnet) e tamanhos mínimos (/26, /27, /26 respectivamente).
Por quê: Esses serviços exigem sub-redes dedicadas e com nomes específicos para injetar seus recursos. O dimensionamento é crítico para a funcionalidade e escalabilidade futura.
Habilitar a resolução de nomes entre redes locais e zonas DNS Privado do Azure.
Implantar o Azure DNS Private Resolver. Usar um endpoint de entrada para consultas de on-prem para Azure e um endpoint de saída com regras de encaminhamento para consultas de Azure para on-prem.
Por quê: Fornece uma solução PaaS gerenciada para DNS híbrido sem exigir VMs DNS personalizadas. O DNS local encaminha para o IP do endpoint de entrada.
Uma VNet emparelhada não consegue resolver registros em uma zona DNS Privado.
Criar um link de rede virtual da zona DNS Privado para a VNet emparelhada.
Por quê: O acesso à zona DNS Privado não é transitivo através do emparelhamento. Cada VNet que requer resolução deve ter um link explícito.
Fornecer um IP público de saída estático e previsível para VMs em uma sub-rede para allow-listing.
Associar um Azure NAT Gateway com um IP Público ou Prefixo de IP Público à sub-rede.
Por quê: O NAT Gateway substitui todos os outros métodos de conectividade de saída para uma sub-rede, garantindo que todo o tráfego use seu(s) IP(s) público(s) estático(s).
Garantir que um IP público para um recurso como um Load Balancer permaneça constante.
Usar um endereço IP Público de SKU Standard com alocação estática.
Por quê: IPs estáticos de SKU Standard são redundantes por zona por padrão e persistem mesmo quando o recurso associado é parado ou excluído.
Projetar uma sub-rede para um cluster AKS usando rede Azure CNI.
Calcular as necessidades de IP como (número de nós * pods máximos por nó) + número de nós. Alocar uma sub-rede que possa acomodar essa contagem.
Por quê: Com o Azure CNI, cada pod recebe um IP diretamente da sub-rede, exigindo alocação significativa de endereços IP.
Direcionar todo o tráfego com destino à internet de uma VNet spoke através de um Azure Firewall na VNet hub.
Criar uma tabela de Rota Definida pelo Usuário (UDR) com uma rota para 0.0.0.0/0, tipo de próximo salto "Virtual appliance", e o IP privado do Azure Firewall.
Por quê: Isso substitui a rota de sistema padrão para a internet, forçando todo o tráfego através do firewall para inspeção.
Inspecionar o tráfego entre duas VNets spoke usando um Azure Firewall no hub.
Em cada spoke, criar UDRs para outros espaços de endereço spoke apontando para o firewall. No firewall, criar regras de rede para permitir o tráfego.
Por quê: O roteamento deve ser configurado em ambos os spokes para enviar tráfego para o firewall, que por padrão nega o tráfego inter-VNet.
Implantar um cluster NVA resiliente para inspeção ou roteamento de tráfego.
Usar o Azure Route Server. As NVAs se emparelham com o Route Server via BGP e anunciam rotas. O Route Server usa ECMP para distribuição de carga.
Por quê: O Route Server simplifica o roteamento dinâmico com NVAs, eliminando o gerenciamento complexo de UDRs e fornecendo failover automatizado.
Uma NVA está descartando o tráfego que deveria estar roteando.
Habilitar "IP forwarding" na interface de rede (NIC) da NVA.
Por quê: Essa configuração no nível do Azure é necessária para permitir que a NIC receba e encaminhe tráfego não destinado ao seu próprio endereço IP.
Distribuir tráfego HTTP/S globalmente para o backend de menor latência com WAF e descarregamento de SSL.
Usar o Azure Front Door.
Por quê: O Front Door usa roteamento anycast para desempenho ideal e integra WAF, roteamento de URL e descarregamento de SSL na borda.
Distribuir tráfego para endpoints globais baseados em DNS com failover impulsionado por sondas de saúde.
Usar o Azure Traffic Manager.
Por quê: O Traffic Manager é um balanceador de carga baseado em DNS. Usar roteamento "Performance" para menor latência ou "Priority" para failover ativo/passivo.
Fornecer balanceamento de carga HTTP/S regional com WAF, terminação SSL e roteamento baseado em URL/host.
Implantar o Azure Application Gateway v2.
Por quê: O Application Gateway é um balanceador de carga L7 regional. Usar regras baseadas em caminho para roteamento de URL e listeners multi-site para roteamento baseado em host.
Balancear a carga de tráfego não HTTP/S (TCP/UDP) dentro de uma região.
Usar o Azure Load Balancer (SKU Standard).
Por quê: O Azure Load Balancer é um balanceador de carga L4 regional. Ele preserva o IP de origem do cliente e é adequado para todos os protocolos TCP/UDP.
Terminar SSL no Application Gateway, mas re-criptografar o tráfego para o backend.
Configurar um listener HTTPS. Nas configurações HTTP de backend, definir o protocolo para HTTPS e carregar o certificado raiz confiável dos servidores de backend.
Por quê: Garante que o tráfego seja criptografado em trânsito até o backend, mesmo com certificados autoassinados nos servidores de backend.
Balancear a carga de tráfego para um listener de Grupo de Disponibilidade SQL Server Always On.
Usar um Load Balancer Standard interno com a configuração "Floating IP (Direct Server Return)" habilitada na regra de balanceamento de carga.
Por quê: O IP Flutuante é necessário para que o listener do SQL AG funcione corretamente, pois permite que o nó secundário responda diretamente aos clientes após um failover.
Balancear a carga de tráfego para um cluster de NVAs que deve processar todos os protocolos e portas.
Usar um Load Balancer Standard interno com uma regra de balanceamento de carga "HA Ports".
Por quê: A regra HA Ports encaminha todo o tráfego TCP e UDP em todas as portas, simplificando a configuração para NVAs que precisam inspecionar todos os fluxos de tráfego.
Configurar o failover automático entre uma origem de aplicativo web primária e secundária.
Colocar ambas as origens no mesmo grupo de origem do Front Door. Atribuir à origem primária uma prioridade de 1 e à secundária uma prioridade mais baixa (por exemplo, 2).
Por quê: O Front Door sempre envia tráfego para a origem saudável de maior prioridade. Quando a origem primária falha nas sondas de saúde, o tráfego muda automaticamente para a próxima prioridade.
Fornecer acesso RDP/SSH seguro a VMs do Azure sem expor portas de gerenciamento à internet.
Implantar o Azure Bastion (SKU Standard para recursos avançados).
Por quê: O Bastion atua como um jump box gerenciado, fornecendo acesso via portal do Azure sobre TLS. Ele elimina a necessidade de IPs públicos em VMs para gerenciamento.
Acessar um serviço PaaS do Azure (por exemplo, SQL, Storage) usando um endereço IP privado de dentro da sua VNet.
Criar um Private Endpoint para o recurso PaaS. Integrar com uma Private DNS Zone para resolução automática de nomes.
Por quê: O Private Endpoint projeta o serviço PaaS na sua VNet com um IP privado, habilitando conectividade verdadeiramente privada. Desabilitar o acesso à rede pública no serviço PaaS impõe isso.
Acessar serviços PaaS do Azure de uma VNet sobre o backbone do Azure sem usar IPs públicos, mas sem gerenciar um IP privado dedicado.
Habilitar um Service Endpoint para o serviço específico (por exemplo, Microsoft.Storage) na sub-rede de origem.
Por quê: Service Endpoints fornecem uma rota direta para serviços PaaS de uma VNet, mas não usam um IP privado na VNet. É mais simples, mas menos flexível que os Private Endpoints.
Expor um serviço em execução na sua VNet a consumidores em outras VNets (potencialmente outros tenants) de forma privada.
Colocar o serviço atrás de um Standard Load Balancer e criar um Private Link Service apontando para ele.
Por quê: O Private Link Service é o componente do lado do provedor. Os consumidores criam Private Endpoints em suas VNets para se conectar ao seu serviço de forma privada.
Simplificar regras de NSG para uma aplicação multi-camadas onde as VMs podem escalar ou mudar de IPs.
Criar Grupos de Segurança de Aplicação (ASGs) para cada camada (por exemplo, Web, App, DB). Definir regras de NSG usando ASGs como origem/destino.
Por quê: ASGs atuam como tags de objeto de rede para VMs, permitindo criar regras baseadas na estrutura da aplicação em vez de endereços IP frágeis.
O tráfego é bloqueado inesperadamente quando os NSGs são aplicados tanto a uma NIC quanto à sua sub-rede.
Lembrar a ordem de avaliação das regras do NSG. Entrada: regras da NIC primeiro, depois regras da Sub-rede. Saída: regras da Sub-rede primeiro, depois regras da NIC.
Por quê: Uma negação em qualquer nível bloqueará o tráfego. Ambos os NSGs devem permitir o fluxo de tráfego para que ele seja bem-sucedido.
Bloquear automaticamente o tráfego de/para endereços IP e domínios maliciosos conhecidos.
Habilitar a filtragem baseada em inteligência de ameaças do Azure Firewall no modo "Alertar e negar".
Por quê: Isso usa o feed de inteligência de ameaças da Microsoft para fornecer proteção gerenciada e atualizada contra ameaças conhecidas com zero configuração.
Inspecionar tráfego HTTPS criptografado em busca de ameaças como malware.
Usar o Azure Firewall Premium. Habilitar a Inspeção TLS na política e implantar um certificado CA intermediário que os clientes devem confiar.
Por quê: Este é um recurso premium que realiza uma descriptografia man-in-the-middle para inspecionar o tráfego, o que é crítico para uma postura de segurança de confiança zero.
Permitir acesso de saída a serviços Microsoft complexos como Windows Update sem manter listas de IP.
No Azure Firewall, criar uma Regra de Aplicação usando FQDN Tags (por exemplo, "WindowsUpdate", "AzureBackup").
Por quê: A Microsoft gerencia os FQDNs associados a essas tags, simplificando o gerenciamento de regras de firewall para serviços dinâmicos.
Proteger aplicações voltadas para o público contra ataques DDoS volumétricos e obter acesso a suporte de resposta rápida.
Habilitar o DDoS Network Protection (anteriormente Standard) na VNet.
Por quê: Fornece ajuste adaptativo, telemetria de ataque, relatórios de mitigação e acesso à equipe de Resposta Rápida a DDoS, o que a proteção Básica gratuita não possui.
Diagnosticar uma falha de conectividade e identificar o salto exato onde o tráfego está sendo descartado.
Usar o Network Watcher > Solução de Problemas de Conexão.
Por quê: Ele realiza uma verificação de ponta a ponta, mostrando o caminho completo salto a salto e identificando falhas devido a NSGs, UDRs ou outros problemas de rede.
Verificar rapidamente se uma regra de NSG está permitindo ou negando tráfego de/para uma VM.
Usar o Network Watcher > Verificação de Fluxo IP.
Por quê: Esta é a ferramenta mais direta para testar um 5-tuple específico contra regras de NSG e ver qual regra é responsável pelo resultado.
Registrar todo o tráfego de rede permitido e negado para conformidade e análise.
Habilitar Logs de Fluxo NSG e ingeri-los no Traffic Analytics (via um Log Analytics Workspace).
Por quê: Os Logs de Fluxo NSG fornecem dados de tráfego brutos. O Traffic Analytics enriquece e visualiza esses dados para identificar padrões de tráfego, principais comunicadores e ameaças de segurança.
Conectar uma rede local ao Azure com uma conexão privada e dedicada, oferecendo latência previsível e alta largura de banda.
Provisionar um circuito Azure ExpressRoute.
Por quê: O ExpressRoute ignora completamente a internet pública, proporcionando uma conexão mais confiável, rápida e de menor latência do que uma VPN Site-to-Site.
Escolher o emparelhamento ExpressRoute correto para acessar recursos do Azure.
Usar o emparelhamento privado do Azure para conectar-se a VNets. Usar o emparelhamento Microsoft para acessar serviços PaaS públicos e Microsoft 365.
Por quê: Os dois tipos de emparelhamento fornecem acesso a diferentes conjuntos de recursos. O emparelhamento Microsoft requer IPs públicos, NAT e filtros de rota.
Permitir que as VNets spoke acessem redes locais via um gateway VPN central ou ExpressRoute na VNet hub.
No emparelhamento hub-to-spoke, habilitar "Allow gateway transit". No emparelhamento spoke-to-hub, habilitar "Use remote gateways".
Por quê: Esta configuração de duas partes permite que os spokes usem o gateway do hub, centralizando a conectividade híbrida.
Configurar uma VPN Site-to-Site como backup para uma conexão ExpressRoute.
Implantar tanto um ExpressRoute quanto um gateway VPN. Por padrão, os caminhos do ExpressRoute são preferidos em relação aos caminhos da VPN para os mesmos prefixos.
Por quê: O Azure automaticamente prefere o ExpressRoute devido a um peso de rota padrão maior. Se o circuito ExpressRoute falhar, o BGP retirará as rotas e o tráfego fará failover para a VPN.
Influenciar o tráfego para preferir um circuito ExpressRoute em relação a outro para redundância ativa/passiva.
Usar o BGP AS Path prepending. Adicionar seu próprio ASN várias vezes aos anúncios de rota no circuito de backup para fazer seu caminho parecer mais longo.
Por quê: O BGP prefere o AS Path mais curto. Isso torna o circuito primário o caminho preferencial, com failover automático para o backup se o caminho primário for retirado.
Conectar dois sites locais através da rede de backbone da Microsoft usando seus circuitos ExpressRoute existentes.
Habilitar o ExpressRoute Global Reach.
Por quê: O Global Reach conecta dois circuitos ExpressRoute juntos, habilitando uma WAN privada sobre a rede Microsoft sem que o tráfego precise fazer hairpin em uma VNet do Azure.
Simplificar o gerenciamento de uma rede global conectando muitos escritórios de filial e VNets.
Implantar o Azure Virtual WAN.
Por quê: O Virtual WAN fornece um serviço hub-and-spoke gerenciado com conectividade transitiva any-to-any automatizada, roteamento e integração com serviços de segurança (hub seguro).
No Virtual WAN, inspecionar todo o tráfego inter-VNet, inter-filial e com destino à internet de forma centralizada.
Implantar um hub virtual seguro (com Azure Firewall). Configurar a intenção de roteamento para enviar tráfego privado e da internet através do firewall.
Por quê: A intenção de roteamento simplifica a engenharia de tráfego no vWAN, programando automaticamente rotas para forçar o tráfego através do provedor de segurança sem UDRs manuais.
Fornecer uma conexão VPN resiliente para o Azure.
Implantar um VPN Gateway em uma configuração ativo-ativo. Isso requer dois IPs públicos e um dispositivo local capaz de estabelecer dois túneis.
Por quê: Fornece redundância em nível de instância dentro da região do Azure. Para redundância entre zonas, usar SKUs redundantes por zona (AZ).
Escolher um protocolo VPN Point-to-Site para ampla compatibilidade de cliente sem software extra.
Usar IKEv2. Para máxima compatibilidade, incluindo dispositivos mais antigos, usar OpenVPN.
Por quê: IKEv2 é nativamente suportado em Windows, macOS e iOS modernos. SSTP é apenas para Windows. OpenVPN requer um cliente, mas é amplamente suportado.
Redirecionar todo o tráfego com destino à internet de VMs do Azure para um appliance de segurança local.
Do ambiente local, anunciar uma rota padrão (0.0.0.0/0) via BGP sobre a conexão ExpressRoute ou VPN.
Por quê: Este anúncio BGP substitui a rota de internet padrão do Azure, forçando o tráfego de volta para a rede local para inspeção.
