Microsoft Azure Network Engineer Associate
Última revisión: mayo de 2026
Una referencia escaneable de patrones arquitectónicos que evalúa el examen AZ-700. Lee de arriba a abajo o salta a una sección.
Conectar recursos entre VNets en diferentes suscripciones o regiones de forma privada.
Configurar el emparejamiento de VNet (VNet peering) entre las redes virtuales.
Por qué: Mantiene el tráfico en la red troncal de Microsoft. El emparejamiento de VNet no es transitivo; se requiere un emparejamiento directo para la comunicación (A->B, B->C != A->C).
Diseñar espacios de direcciones de VNet para conectividad futura.
Asignar bloques CIDR únicos y no superpuestos a cada VNet.
Por qué: El emparejamiento de VNet requiere espacios de direcciones no superpuestos. Planificar para el crecimiento para evitar re-arquitecturas.
Calcular el tamaño de subred requerido para un número específico de hosts.
Utilizar la notación CIDR que proporcione los hosts requeridos + 5 direcciones IP reservadas para Azure.
Por qué: Azure reserva las primeras cuatro y la última dirección IP en cada subred. Una /24 (256 IPs) proporciona solo 251 IPs utilizables.
Implementar servicios como Azure Firewall, Gateway o Bastion.
Crear subredes dedicadas con nombres específicos (ej. AzureFirewallSubnet, GatewaySubnet, AzureBastionSubnet) y tamaños mínimos (/26, /27, /26 respectivamente).
Por qué: Estos servicios requieren subredes dedicadas, con nombres específicos, para inyectar sus recursos. El tamaño es crítico para la funcionalidad y el escalado futuro.
Habilitar la resolución de nombres entre redes locales y zonas DNS privadas de Azure.
Implementar Azure DNS Private Resolver. Usar un punto de conexión entrante (inbound endpoint) para consultas de local a Azure y un punto de conexión saliente (outbound endpoint) con reglas de reenvío para consultas de Azure a local.
Por qué: Proporciona una solución PaaS gestionada para DNS híbrido sin requerir VMs DNS personalizadas. El DNS local reenvía al IP del punto de conexión entrante.
Una VNet emparejada no puede resolver registros en una zona DNS privada.
Crear un enlace de red virtual desde la zona DNS privada a la VNet emparejada.
Por qué: El acceso a la zona DNS privada no es transitivo a través del emparejamiento. Cada VNet que requiera resolución debe tener un enlace explícito.
Proporcionar una IP pública estática y predecible para la salida de VMs en una subred para listas de permitidos (allow-listing).
Asociar un Azure NAT Gateway con una IP pública o un prefijo de IP pública a la subred.
Por qué: NAT Gateway anula todos los demás métodos de conectividad saliente para una subred, asegurando que todo el tráfico utilice su(s) IP(s) pública(s) estática(s).
Asegurar que una IP pública para un recurso como un Load Balancer permanezca constante.
Usar una dirección IP pública SKU Estándar con asignación estática.
Por qué: Las IPs estáticas SKU Estándar son redundantes de zona por defecto y persisten incluso cuando el recurso asociado se detiene o se elimina.
Diseñar una subred para un clúster de AKS utilizando redes Azure CNI.
Calcular las necesidades de IP como (número de nodos * pods máximos por nodo) + número de nodos. Asignar una subred que pueda acomodar esta cuenta.
Por qué: Con Azure CNI, cada pod obtiene una IP directamente de la subred, lo que requiere una asignación significativa de direcciones IP.
Enrutar todo el tráfico con destino a Internet desde una VNet de tipo spoke a través de un Azure Firewall en la VNet de tipo hub.
Crear una tabla de rutas definidas por el usuario (UDR) con una ruta para 0.0.0.0/0, tipo de próximo salto "Virtual appliance" y la IP privada del Azure Firewall.
Por qué: Esto anula la ruta del sistema predeterminada a Internet, forzando todo el tráfico a través del firewall para su inspección.
Inspeccionar el tráfico entre dos VNets de tipo spoke utilizando un Azure Firewall en el hub.
En cada spoke, crear UDRs para otros espacios de direcciones de spoke apuntando al firewall. En el firewall, crear reglas de red para permitir el tráfico.
Por qué: El enrutamiento debe configurarse en ambos spokes para enviar tráfico al firewall, que por defecto deniega el tráfico entre VNets.
Implementar un clúster NVA resistente para inspección o enrutamiento de tráfico.
Usar Azure Route Server. Las NVAs se emparejan con Route Server a través de BGP y anuncian rutas. Route Server utiliza ECMP para la distribución de carga.
Por qué: Route Server simplifica el enrutamiento dinámico con NVAs, eliminando la compleja gestión de UDRs y proporcionando conmutación por error automatizada.
Una NVA está descartando tráfico que debería estar enrutando.
Habilitar "IP forwarding" en la interfaz de red (NIC) de la NVA.
Por qué: Esta configuración a nivel de Azure es necesaria para permitir que la NIC reciba y reenvíe tráfico no destinado a su propia dirección IP.
Distribuir tráfico HTTP/S globalmente al backend de menor latencia con WAF y descarga de SSL.
Usar Azure Front Door.
Por qué: Front Door utiliza enrutamiento anycast para un rendimiento óptimo e integra WAF, enrutamiento de URL y descarga de SSL en el perímetro.
Distribuir tráfico a puntos de conexión globales basándose en DNS con conmutación por error impulsada por sondeos de salud.
Usar Azure Traffic Manager.
Por qué: Traffic Manager es un balanceador de carga basado en DNS. Usar el enrutamiento "Performance" para la menor latencia o "Priority" para la conmutación por error activa/pasiva.
Proporcionar balanceo de carga HTTP/S regional con WAF, terminación SSL y enrutamiento basado en URL/host.
Implementar Azure Application Gateway v2.
Por qué: Application Gateway es un balanceador de carga L7 regional. Usar reglas basadas en ruta para el enrutamiento de URL y oyentes multisitio para el enrutamiento basado en host.
Balancear la carga de tráfico no HTTP/S (TCP/UDP) dentro de una región.
Usar Azure Load Balancer (SKU Estándar).
Por qué: Azure Load Balancer es un balanceador de carga L4 regional. Preserva la IP de origen del cliente y es adecuado para todos los protocolos TCP/UDP.
Terminar SSL en Application Gateway pero volver a cifrar el tráfico al backend.
Configurar un oyente HTTPS. En la configuración HTTP del backend, establecer el protocolo en HTTPS y cargar el certificado raíz de confianza de los servidores backend.
Por qué: Asegura que el tráfico esté cifrado en tránsito hasta el backend, incluso con certificados autofirmados en los servidores backend.
Balancear la carga de tráfico a un oyente de grupo de disponibilidad SQL Server Always On.
Usar un Standard Load Balancer interno con la configuración "Floating IP (Direct Server Return)" habilitada en la regla de balanceo de carga.
Por qué: Floating IP es necesario para que el oyente de SQL AG funcione correctamente, ya que permite que el nodo secundario responda directamente a los clientes después de una conmutación por error.
Balancear la carga de tráfico a un clúster de NVAs que deben procesar todos los protocolos y puertos.
Usar un Standard Load Balancer interno con una regla de balanceo de carga de "HA Ports".
Por qué: La regla de HA Ports reenvía todo el tráfico TCP y UDP en todos los puertos, simplificando la configuración para NVAs que necesitan inspeccionar todos los flujos de tráfico.
Configurar la conmutación por error automática entre un origen de aplicación web primario y secundario.
Colocar ambos orígenes en el mismo grupo de orígenes de Front Door. Asignar al origen primario una prioridad de 1 y al secundario una prioridad más baja (ej. 2).
Por qué: Front Door siempre envía tráfico al origen saludable de mayor prioridad. Cuando el primario falla en los sondeos de salud, el tráfico se desplaza automáticamente a la siguiente prioridad.
Proporcionar acceso seguro RDP/SSH a VMs de Azure sin exponer puertos de gestión a Internet.
Implementar Azure Bastion (SKU Estándar para características avanzadas).
Por qué: Bastion actúa como un jump box gestionado, proporcionando acceso a través del portal de Azure sobre TLS. Elimina la necesidad de IPs públicas en las VMs para la gestión.
Acceder a un servicio Azure PaaS (ej. SQL, Storage) utilizando una dirección IP privada desde su VNet.
Crear un Private Endpoint para el recurso PaaS. Integrar con una Private DNS Zone para la resolución automática de nombres.
Por qué: Private Endpoint proyecta el servicio PaaS en su VNet con una IP privada, habilitando una conectividad verdaderamente privada. Deshabilitar el acceso a la red pública en el servicio PaaS lo impone.
Acceder a servicios Azure PaaS desde una VNet a través de la red troncal de Azure sin usar IPs públicas, pero sin gestionar una IP privada dedicada.
Habilitar un Service Endpoint para el servicio específico (ej. Microsoft.Storage) en la subred de origen.
Por qué: Service Endpoints proporcionan una ruta directa a los servicios PaaS desde una VNet, pero no utilizan una IP privada en la VNet. Es más simple pero menos flexible que los Private Endpoints.
Exponer un servicio ejecutándose en su VNet a consumidores en otras VNets (potencialmente otros inquilinos) de forma privada.
Colocar el servicio detrás de un Standard Load Balancer y crear un Private Link Service que apunte a él.
Por qué: Private Link Service es el componente del lado del proveedor. Los consumidores crean Private Endpoints en sus VNets para conectarse a su servicio de forma privada.
Simplificar las reglas de NSG para una aplicación de varias capas donde las VMs pueden escalar o cambiar IPs.
Crear Application Security Groups (ASGs) para cada capa (ej. Web, App, DB). Definir reglas de NSG utilizando ASGs como origen/destino.
Por qué: Los ASGs actúan como etiquetas de objeto de red para VMs, permitiendo crear reglas basadas en la estructura de la aplicación en lugar de direcciones IP frágiles.
El tráfico se bloquea inesperadamente cuando se aplican NSGs tanto a una NIC como a su subred.
Recordar el orden de evaluación de las reglas NSG. Entrante: primero las reglas de NIC, luego las reglas de subred. Saliente: primero las reglas de subred, luego las reglas de NIC.
Por qué: Una denegación en cualquier nivel bloqueará el tráfico. Ambas NSGs deben permitir el flujo de tráfico para que tenga éxito.
Bloquear automáticamente el tráfico hacia/desde direcciones IP y dominios maliciosos conocidos.
Habilitar el filtrado basado en inteligencia de amenazas de Azure Firewall en modo "Alert and deny".
Por qué: Esto utiliza el feed de inteligencia de amenazas de Microsoft para proporcionar protección gestionada y actualizada contra amenazas conocidas con cero configuración.
Inspeccionar tráfico HTTPS cifrado en busca de amenazas como malware.
Usar Azure Firewall Premium. Habilitar TLS Inspection en la política e implementar un certificado de CA intermedio en el que los clientes deban confiar.
Por qué: Esta es una característica premium que realiza una desencriptación "man-in-the-middle" para inspeccionar el tráfico, lo cual es crítico para una postura de seguridad de confianza cero.
Permitir acceso saliente a servicios complejos de Microsoft como Windows Update sin mantener listas de IP.
En Azure Firewall, crear una regla de aplicación utilizando FQDN Tags (ej. "WindowsUpdate", "AzureBackup").
Por qué: Microsoft gestiona los FQDNs asociados con estas etiquetas, simplificando la gestión de reglas de firewall para servicios dinámicos.
Proteger aplicaciones de cara al público de ataques DDoS volumétricos y obtener acceso a soporte de respuesta rápida.
Habilitar DDoS Network Protection (anteriormente Estándar) en la VNet.
Por qué: Proporciona ajuste adaptativo, telemetría de ataque, informes de mitigación y acceso al equipo de respuesta rápida de DDoS, de lo que carece la protección Básica gratuita.
Diagnosticar un fallo de conectividad e identificar el salto exacto donde se está descartando el tráfico.
Usar Network Watcher > Connection Troubleshoot.
Por qué: Realiza una comprobación de extremo a extremo, mostrando la ruta completa salto a salto y señalando fallos debido a NSGs, UDRs u otros problemas de red.
Verificar rápidamente si una regla NSG está permitiendo o denegando tráfico hacia/desde una VM.
Usar Network Watcher > IP Flow Verify.
Por qué: Esta es la herramienta más directa para probar una 5-tupla específica contra las reglas NSG y ver qué regla es responsable del resultado.
Registrar todo el tráfico de red permitido y denegado para cumplimiento y análisis.
Habilitar los NSG Flow Logs e ingerirlos en Traffic Analytics (a través de un Log Analytics Workspace).
Por qué: Los NSG Flow Logs proporcionan datos de tráfico en bruto. Traffic Analytics enriquece y visualiza estos datos para identificar patrones de tráfico, principales comunicantes y amenazas de seguridad.
Conectar una red local a Azure con una conexión privada y dedicada que ofrezca latencia predecible y alto ancho de banda.
Provisionar un circuito de Azure ExpressRoute.
Por qué: ExpressRoute evita completamente el internet público, proporcionando una conexión más confiable, rápida y de menor latencia que una VPN Site-to-Site.
Elegir el emparejamiento de ExpressRoute correcto para acceder a los recursos de Azure.
Usar el emparejamiento privado de Azure para conectarse a VNets. Usar el emparejamiento de Microsoft para acceder a servicios PaaS públicos y Microsoft 365.
Por qué: Los dos tipos de emparejamiento proporcionan acceso a diferentes conjuntos de recursos. El emparejamiento de Microsoft requiere IPs públicas, NAT y filtros de ruta.
Permitir que las VNets de tipo spoke accedan a redes locales a través de una VPN central o gateway de ExpressRoute en la VNet de tipo hub.
En el emparejamiento de hub a spoke, habilitar "Allow gateway transit". En el emparejamiento de spoke a hub, habilitar "Use remote gateways".
Por qué: Esta configuración de dos partes permite que los spokes utilicen el gateway del hub, centralizando la conectividad híbrida.
Configurar una VPN Site-to-Site como copia de seguridad para una conexión ExpressRoute.
Implementar tanto un ExpressRoute como un VPN gateway. Por defecto, las rutas de ExpressRoute se prefieren sobre las rutas de VPN para los mismos prefijos.
Por qué: Azure prefiere automáticamente ExpressRoute debido a un peso de ruta predeterminado más alto. Si el circuito ExpressRoute falla, BGP retirará las rutas y el tráfico conmutará por error a la VPN.
Influir en el tráfico para preferir un circuito ExpressRoute sobre otro para redundancia activa/pasiva.
Usar el prepending de AS Path de BGP. Añadir su propio ASN varias veces a los anuncios de ruta en el circuito de respaldo para que su ruta parezca más larga.
Por qué: BGP prefiere la ruta AS Path más corta. Esto convierte el circuito primario en la ruta preferida, con conmutación por error automática al respaldo si la ruta principal se retira.
Conectar dos sitios locales a través de la red troncal de Microsoft utilizando sus circuitos ExpressRoute existentes.
Habilitar ExpressRoute Global Reach.
Por qué: Global Reach enlaza dos circuitos ExpressRoute, habilitando una WAN privada sobre la red de Microsoft sin que el tráfico tenga que hacer un hairpin en una VNet de Azure.
Simplificar la gestión de una red global que conecta muchas sucursales y VNets.
Implementar Azure Virtual WAN.
Por qué: Virtual WAN proporciona un servicio hub-and-spoke gestionado con conectividad transitiva any-to-any automatizada, enrutamiento e integración con servicios de seguridad (hub seguro).
En Virtual WAN, inspeccionar todo el tráfico entre VNets, entre sucursales y con destino a Internet de forma centralizada.
Implementar un hub virtual seguro (con Azure Firewall). Configurar la intención de enrutamiento para enviar tráfico privado y de Internet a través del firewall.
Por qué: La intención de enrutamiento simplifica la ingeniería de tráfico en vWAN, programando automáticamente rutas para forzar el tráfico a través del proveedor de seguridad sin UDRs manuales.
Proporcionar una conexión VPN resistente a Azure.
Implementar un VPN Gateway en una configuración activo-activo. Esto requiere dos IPs públicas y un dispositivo local capaz de establecer dos túneles.
Por qué: Proporciona redundancia a nivel de instancia dentro de la región de Azure. Para redundancia entre zonas, utilizar SKUs redundantes de zona (AZ).
Elegir un protocolo VPN Point-to-Site para amplia compatibilidad de clientes sin software adicional.
Usar IKEv2. Para máxima compatibilidad, incluyendo dispositivos más antiguos, usar OpenVPN.
Por qué: IKEv2 es compatible de forma nativa en Windows, macOS e iOS modernos. SSTP es solo para Windows. OpenVPN requiere un cliente pero es ampliamente compatible.
Redirigir todo el tráfico con destino a Internet desde VMs de Azure a un dispositivo de seguridad local.
Desde las instalaciones, anunciar una ruta predeterminada (0.0.0.0/0) vía BGP sobre la conexión ExpressRoute o VPN.
Por qué: Este anuncio BGP anula la ruta de Internet predeterminada de Azure, forzando el tráfico de vuelta a la red local para su inspección.
