Microsoft Azure Administrator Associate
Última revisión: mayo de 2026
Una referencia escaneable de patrones arquitectónicos que evalúa el examen AZ-104. Lee de arriba a abajo o salta a una sección.
Administrar automáticamente la pertenencia a grupos de seguridad basándose en atributos de usuario (por ejemplo, departamento).
Configure un grupo de seguridad de Microsoft Entra ID con el tipo de pertenencia "Usuario dinámico" y defina una regla basada en atributos.
Por qué: Las reglas basadas en atributos eliminan la administración manual continua para los cambios en el ciclo de vida del usuario. Requiere Entra ID P1/P2.
Aplicar gobernanza consistente (políticas, RBAC) en múltiples suscripciones desde un único punto de gestión.
Cree un grupo de administración, coloque las suscripciones debajo de él y asigne políticas o roles RBAC en el ámbito del grupo de administración.
Por qué: Las políticas y las asignaciones de roles son heredadas por todas las suscripciones secundarias, lo que permite una gobernanza centralizada y consistente.
Evitar la implementación de recursos en regiones de Azure no autorizadas en toda una suscripción.
Asigne la Azure Policy incorporada "Allowed locations" con un efecto `Deny` en el ámbito de la suscripción.
Por qué: La política proporciona gobernanza preventiva. RBAC controla las acciones, no las ubicaciones de implementación. Los Resource Locks evitan la modificación/eliminación, no las nuevas implementaciones.
Conceder permisos para administrar VM pero no la red virtual subyacente o el acceso de usuario.
Asigne el rol incorporado "Virtual Machine Contributor" en el ámbito del grupo de recursos o de la VM.
Por qué: Este rol proporciona permisos específicos de administración de VM (iniciar, detener, reimagen) sin otorgar derechos amplios de Contributor o Owner.
Requerir MFA cuando los usuarios acceden a aplicaciones en la nube específicas (por ejemplo, el portal de Azure) desde fuera de la red corporativa.
Cree una política de Conditional Access con una "Named Location" para IPs corporativas como condición de exclusión, y requiera MFA como control de concesión.
Por qué: Excluir una ubicación de confianza es clave para omitir la MFA en la red corporativa mientras se aplica en cualquier otro lugar.
Evitar la eliminación de recursos críticos, incluso por administradores con roles Owner.
Aplique un bloqueo de recursos `CanNotDelete` o `ReadOnly` en el recurso o su grupo de recursos.
Por qué: Los bloqueos de recursos se aplican a todos los usuarios, independientemente de su rol RBAC, proporcionando la protección más sólida contra la eliminación accidental.
Corregir automáticamente los recursos no conformes existentes identificados por una Azure Policy (por ejemplo, añadir una etiqueta faltante).
Para políticas con efectos `Modify` o `DeployIfNotExists`, cree una tarea de remediación para la asignación de la política.
Por qué: Las tareas de remediación activan la acción correctiva de la política en todos los recursos no conformes existentes, automatizando el proceso de cumplimiento de un entorno.
Informar sobre los costos de Azure desglosados por departamento, proyecto o unidad de negocio.
Aplique una etiqueta consistente (por ejemplo, "CostCenter") a todos los recursos. Use Azure Cost Management para filtrar y agrupar los costos por esa etiqueta.
Por qué: Las etiquetas son el mecanismo principal para la asignación de costos personalizada y la generación de informes en diferentes grupos de recursos y suscripciones.
Conceder roles privilegiados a los administradores solo cuando sea necesario, por un tiempo limitado y con un flujo de trabajo de aprobación.
Use Microsoft Entra Privileged Identity Management (PIM). Haga que los usuarios sean elegibles para los roles y configure los requisitos de activación.
Por qué: PIM impone el acceso Just-In-Time (JIT), reduciendo la exposición de las cuentas privilegiadas permanentes y proporcionando un rastro de auditoría completo.
Conceder a socios externos acceso a recursos de Azure utilizando sus propias credenciales corporativas.
Utilice la colaboración Microsoft Entra B2B para invitar a socios como usuarios invitados a su tenant.
Por qué: B2B evita crear y administrar nuevas credenciales en su tenant; los socios utilizan su proveedor de identidad existente para la autenticación.
Minimizar los costos de almacenamiento para datos a largo plazo (por ejemplo, archivos de cumplimiento) a los que rara vez se accede pero que deben conservarse.
Utilice una política de gestión del ciclo de vida de blobs para hacer la transición automática de blobs de Hot/Cool a la capa Archive.
Por qué: La capa Archive tiene el costo de almacenamiento más bajo. Las reglas de ciclo de vida automatizan el proceso de escalonamiento según la antigüedad del blob o la última hora de acceso.
Asegurar el acceso de lectura a los datos de almacenamiento desde una región secundaria durante una interrupción de la región principal.
Configure la cuenta de almacenamiento con Read-Access Geo-Redundant Storage (RA-GRS) o RA-GZRS.
Por qué: GRS/GZRS estándar replica datos pero no permite el acceso de lectura a la secundaria hasta un failover. El prefijo "RA" es necesario para el acceso de lectura continuo.
Capacidad de revocar inmediatamente un conjunto de tokens Shared Access Signature (SAS) para un contenedor específico.
Cree tokens SAS basados en una política de acceso almacenada en el contenedor. Para revocar, modifique o elimine la política.
Por qué: Modificar la política de acceso almacenada invalida inmediatamente todos los tokens SAS asociados a ella, proporcionando un mecanismo de revocación centralizado.
Sincronizar un servidor de archivos local con un recurso compartido de archivos de Azure mientras se minimiza el uso del espacio en disco local.
Implemente Azure File Sync y habilite el cloud tiering en el punto de conexión del servidor.
Por qué: El cloud tiering mantiene solo los archivos a los que se accede con frecuencia ("hot") almacenados en caché localmente, mientras que los archivos menos utilizados se escalonan a Azure, apareciendo como stubs en el servidor local.
Restringir el acceso a la red de una cuenta de almacenamiento a subredes de VNet y direcciones IP públicas específicas.
Habilite el firewall de la cuenta de almacenamiento. Agregue reglas de red virtual para las subredes y reglas de dirección IP para las IPs públicas.
Por qué: El firewall de almacenamiento proporciona control de acceso a nivel de red directamente en el punto de conexión público de la cuenta de almacenamiento, bloqueando todo el demás tráfico.
Proteger los blobs de la eliminación accidental permitiendo la recuperación durante un período específico.
Habilite la eliminación suave de blobs (blob soft delete) en la cuenta de almacenamiento y configure el período de retención (por ejemplo, 14 días).
Por qué: La eliminación suave retiene los blobs eliminados durante el período configurado, permitiendo una simple recuperación. Esta es la primera línea de defensa contra la pérdida accidental de datos.
Cumplir los requisitos de cumplimiento para almacenar datos en un estado no borrable y no modificable (WORM) durante un período fijo.
Configure una política de retención basada en el tiempo en un contenedor de blobs y bloquee la política.
Por qué: Una política de retención basada en el tiempo bloqueada hace que los blobs sean inmutables, impidiendo la eliminación o modificación por parte de cualquier persona (incluidos los administradores) hasta que expire el período de retención.
Migrar un conjunto de datos muy grande (por ejemplo, más de 50 TB) a Azure Blob Storage cuando el ancho de banda de la red es limitado.
Utilice el dispositivo físico Azure Data Box para una transferencia sin conexión.
Por qué: Para grandes conjuntos de datos, enviar un dispositivo físico es significativamente más rápido que transferir datos a través de una conexión de red lenta o saturada.
Lograr un SLA del 99,99% para las VM y proteger una aplicación contra una falla de un único centro de datos dentro de una región.
Implemente múltiples instancias de VM en diferentes Availability Zones dentro de la misma región.
Por qué: Las Availability Zones son centros de datos físicamente separados. Los Availability Sets solo protegen contra fallas a nivel de rack dentro de un solo centro de datos (SLA del 99,95%).
Implementar y probar una nueva versión de la aplicación con tráfico de producción en vivo antes de un lanzamiento completo, con cero tiempo de inactividad.
Use un App Service deployment slot. Implemente en el slot, pruebe y luego realice un swap. Opcionalmente, use el enrutamiento de tráfico para pruebas canary.
Por qué: Los slots proporcionan un entorno de staging completo. La operación de swap es una redirección casi instantánea del tráfico, asegurando cero tiempo de inactividad.
Ejecutar un trabajo por lotes en contenedores de corta duración en un horario, con un costo mínimo y sin administración de infraestructura.
Use Azure Container Instances (ACI).
Por qué: ACI ofrece facturación por segundo y sin sobrecarga de administración de clústeres, lo que lo convierte en la opción más rentable para cargas de trabajo de contenedores esporádicas o de corta duración.
Autoescalar una carga de trabajo con picos diarios predecibles (por ejemplo, horas de oficina) mientras también maneja picos inesperados.
Configure el autoescalado de VM Scale Set con reglas basadas en programación y reglas basadas en métricas.
Por qué: La combinación de escalado proactivo (programación) y reactivo (métrica) proporciona el mejor equilibrio entre rendimiento (listo antes del pico) y eficiencia de costos (se reduce cuando está inactivo).
Almacenar imágenes de contenedor para un clúster de Azure Kubernetes Service (AKS) de forma segura en un registro privado con escaneo de vulnerabilidades.
Use el SKU Premium de Azure Container Registry (ACR) e intégrélo con AKS utilizando una managed identity.
Por qué: ACR proporciona un registro privado ubicado en Azure. El SKU Premium incluye escaneo de vulnerabilidades. Managed identity proporciona autenticación segura y sin credenciales de AKS a ACR.
Realizar una actualización de SO o aplicación en todas las instancias de VMSS sin causar tiempo de inactividad de la aplicación.
Actualice el modelo de VMSS (por ejemplo, nueva versión de imagen) y use una política de Rolling upgrade.
Por qué: La política Rolling actualiza las instancias en lotes configurables, asegurando que un subconjunto de instancias esté siempre disponible para atender el tráfico durante todo el proceso de actualización.
Implementar una aplicación multicontenedor (por ejemplo, aplicación + sidecar de logging) que debe compartir red y almacenamiento, sin un orquestador completo.
Implemente los contenedores en un único grupo de contenedores de Azure Container Instances (ACI).
Por qué: Un grupo de contenedores co-localiza múltiples contenedores, compartiendo una red localhost y volúmenes, perfecto para patrones sidecar sin la complejidad de Kubernetes.
Aumentar el tamaño del disco de SO o de datos de una VM después de haber sido implementado.
Desasigne la VM, cambie el tamaño del recurso de disco en Azure, inicie la VM y luego extienda la partición dentro del SO invitado.
Por qué: Cambiar el tamaño del disco de Azure solo asigna más espacio. El SO invitado debe ser instruido para usar ese nuevo espacio extendiendo su partición del sistema de archivos.
Permitir que un App Service acceda de forma segura a secretos de Azure Key Vault sin almacenar credenciales en la aplicación.
Habilite una managed identity asignada por el sistema en el App Service y otorgue a esa identidad permisos `Get` y `List` en los secretos de Key Vault.
Por qué: Managed identity proporciona un mecanismo de autenticación sin credenciales. La aplicación puede adquirir un token de acceso para Key Vault automáticamente, eliminando la gestión de secretos.
Organizar una implementación de infraestructura como código grande y compleja en componentes más pequeños, reutilizables y mantenibles.
Refactorice la implementación en módulos Bicep, con cada módulo representando una unidad lógica (por ejemplo, redes, cómputo), y orquéstrelos desde un archivo Bicep principal.
Por qué: Los módulos promueven la reutilización del código, mejoran la legibilidad y simplifican la gestión de implementaciones de infraestructura complejas.
Aislar las capas de aplicación (web, app, datos) dentro de una VNet, evitando la comunicación directa entre capas no adyacentes.
Use una subred separada para cada capa y aplique Network Security Groups (NSGs) a cada subred para controlar el flujo de tráfico.
Por qué: Los NSG permiten un filtrado de estado de grano fino basado en rangos de IP de origen/destino (subredes), puertos y protocolos, lo que permite la microsegmentación de la red.
Conectar dos VNets en diferentes regiones de Azure de forma privada a través de la red troncal de Microsoft.
Configure Global VNet Peering entre las dos VNets.
Por qué: Global Peering es más simple, de menor latencia y mayor ancho de banda que una conexión VPN de VNet a VNet. El tráfico permanece en la red privada de Microsoft.
VNet-A está emparejada con Hub-VNet, y Spoke-VNet también está emparejada con Hub-VNet. Las VM en VNet-A no pueden alcanzar las VM en Spoke-VNet.
La causa es que el emparejamiento de VNet no es transitivo. Para habilitar la comunicación, empareje VNet-A y Spoke-VNet directamente o use un NVA en el Hub.
Por qué: El emparejamiento no crea una cadena de margarita. Cada VNet debe estar conectada directamente para comunicarse, a menos que se configure el enrutamiento a través de una Network Virtual Appliance.
Establecer un túnel IPsec persistente y cifrado desde una red local a una VNet de Azure a través de Internet público.
Implemente un Azure VPN Gateway en la VNet y configure una conexión Site-to-Site (S2S).
Por qué: Esta es la solución estándar, segura y confiable para la conectividad híbrida entre un único sitio local y una VNet de Azure.
Un Azure Load Balancer continúa enviando tráfico a una VM de backend no saludable, causando tiempos de espera de la aplicación.
Configure una health probe en el load balancer que verifique con precisión la salud de la aplicación en las VM de backend.
Por qué: El load balancer se basa completamente en las health probes para detectar instancias no saludables. Sin una sonda configurada correctamente, no puede eliminar las VM fallidas de la rotación de tráfico.
Enrutar el tráfico HTTP/S a diferentes pools de servidores backend basándose en la ruta URL (por ejemplo, /images/* vs /api/*).
Use Azure Application Gateway con reglas de enrutamiento basadas en rutas.
Por qué: Application Gateway es un balanceador de carga de Capa 7 que inspecciona las solicitudes HTTP y puede tomar decisiones de enrutamiento basadas en rutas URL. Un Azure Load Balancer estándar es de Capa 4 y no puede.
Las VM en una VNet con un servidor DNS personalizado no pueden resolver nombres de host en una Azure Private DNS Zone.
Configure el servidor DNS personalizado para reenviar condicionalmente las consultas para la zona privada a la IP del resolvedor DNS proporcionado por Azure (168.63.129.16).
Por qué: Cuando se utiliza un servidor DNS personalizado, este omite el DNS interno de Azure. Se debe enseñar al servidor personalizado a resolver zonas específicas de Azure reenviando las solicitudes a Azure DNS.
Forzar que todo el tráfico de las VNets spoke con destino a Internet sea inspeccionado por un Azure Firewall central en la VNet hub.
Aplique una Route Table con una User-Defined Route (UDR) a las subredes spoke. La UDR es una ruta predeterminada (0.0.0.0/0) que apunta a la IP privada del firewall.
Por qué: Una UDR anula la ruta del sistema predeterminada de Azure a Internet, lo que le permite controlar y centralizar el flujo de tráfico de salida para la inspección de seguridad.
Proporcionar acceso seguro RDP/SSH a VM que no tienen direcciones IP públicas, sin configurar una VPN.
Implemente Azure Bastion en una subred dedicada (AzureBastionSubnet) en la VNet.
Por qué: Bastion proporciona un servicio de jump box gestionado, permitiendo un acceso administrativo seguro a través del portal de Azure sobre TLS, eliminando la exposición de IP pública en las VM.
Asegurar que el tráfico entre una VM y un servicio PaaS (por ejemplo, Azure SQL) permanezca en la red privada y que el servicio PaaS no sea accesible públicamente.
Cree un private endpoint para el servicio PaaS en la VNet de la VM y deshabilite el acceso a la red pública en el servicio PaaS.
Por qué: Un private endpoint le da al servicio PaaS una IP privada dentro de su VNet, mientras que deshabilitar el acceso público asegura que solo sea accesible a través de esa IP privada.
Enrutar a usuarios globales al endpoint de aplicación regional más cercano para garantizar la menor latencia posible.
Utilice Azure Traffic Manager con el método de enrutamiento "Performance".
Por qué: El método de enrutamiento Performance utiliza DNS para dirigir a los clientes al endpoint con la menor latencia de red desde su ubicación.
Enviar una notificación (correo electrónico, SMS, webhook) cuando una métrica de recurso (por ejemplo, porcentaje de CPU de VM) excede un umbral durante una duración determinada.
Cree una regla de Metric Alert en Azure Monitor y vincúlela a un Action Group que defina la acción de notificación.
Por qué: Este es el patrón estándar. La regla de alerta define la condición (qué/cuándo), y el grupo de acciones define la notificación resultante (quién/cómo).
Determinar si el tráfico entre dos VM está siendo bloqueado por una regla específica de Network Security Group (NSG).
Use la herramienta IP Flow Verify en Azure Network Watcher.
Por qué: IP Flow Verify simula un flujo de paquetes e informa explícitamente qué NSG y regla está permitiendo o denegando el tráfico, convirtiéndola en la herramienta definitiva para solucionar conflictos de NSG.
Configurar copias de seguridad programadas y basadas en políticas para VM de Azure con consistencia de aplicación y retención a largo plazo.
Cree un Recovery Services vault, defina una política de copia de seguridad (programación, retención) y habilite la copia de seguridad para las VM de destino.
Por qué: El Recovery Services vault es la entidad de gestión central para Azure Backup. Almacena los datos de copia de seguridad de forma segura y gestiona todas las operaciones de copia de seguridad y restauración.
Crear un dashboard centralizado para monitorear el rendimiento (CPU, Memoria, Disco, Red) de las VM en múltiples suscripciones.
Implemente un Log Analytics workspace central y habilite VM Insights para todas las VM de destino, apuntándolas al workspace.
Por qué: VM Insights recopila y agrega datos de rendimiento, proporcionando workbooks predefinidos y una vista consolidada de rendimiento "a escala" en todas las suscripciones.
Identificar proactivamente recursos de Azure subutilizados y oportunidades de ahorro de costos (por ejemplo, dimensionamiento correcto de VM).
Revise regularmente las recomendaciones de Cost en Azure Advisor.
Por qué: Azure Advisor analiza automáticamente el uso de recursos y proporciona recomendaciones personalizadas y accionables para el ahorro de costos sin requerir configuración adicional.
Replicar VM de Azure de una región primaria a una región secundaria para proporcionar capacidad de recuperación ante desastres.
Use Azure Site Recovery. Cree un Recovery Services vault y habilite la replicación para las VM a la región de destino.
Por qué: ASR es el servicio nativo de Azure para orquestar la replicación de VM, las pruebas de failover y el failover/failback entre regiones de Azure.
Establecer diferentes períodos de retención de datos para registros de seguridad frente a registros de rendimiento dentro de un único Log Analytics workspace para optimizar costos.
Establezca una retención predeterminada a nivel de workspace y luego configure un período de retención más largo a nivel de tabla individual (por ejemplo, para la tabla SecurityEvent).
Por qué: La retención por tabla le permite satisfacer las necesidades de cumplimiento a largo plazo para datos específicos, minimizando los costos de almacenamiento para datos de gran volumen y menos críticos.
