Microsoft AZ-900: Arquitectura e infraestructura global de Azure — Guía de estudio

By Laurynas Brazys · 22 July 2026 · #microsoft #az-900 #certification #exam-prep #study-guide

Forma parte de la Microsoft Azure AZ-900 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Microsoft, o realiza tests cronometrados en ExamRoll.io.

La arquitectura global de Azure está diseñada para ofrecer servicios en la nube resilientes, de alto rendimiento y conformes a escala. Comprender la disposición física de las geografías, regiones y zonas de disponibilidad, junto con la jerarquía lógica de los grupos de administración, suscripciones, grupos de recursos y recursos, es la base de un diseño y una gobernanza fiables. El plano de control proporcionado por Azure Resource Manager, combinado con plantillas declarativas, permite despliegues consistentes y repetibles que se alinean con las políticas organizativas y los requisitos de seguridad. Las decisiones de diseño en este dominio influyen directamente en los objetivos de disponibilidad, las obligaciones de residencia de datos y la experiencia del usuario en todo el mundo. Seleccionar el modelo de redundancia adecuado, calcular los SLA compuestos y elegir servicios de enrutamiento global como Azure Front Door, Traffic Manager y Azure CDN son fundamentales para cumplir los objetivos de continuidad del negocio, cumplimiento y rendimiento.

Geografías, Regiones, Zonas de Disponibilidad y Pares de Regiones

Las geografías de Azure son conjuntos definidos de regiones que preservan la residencia de los datos y los límites de cumplimiento. Algunos ejemplos son Estados Unidos, Europa, Reino Unido, Australia y Canadá, así como nubes soberanas con modelos de cumplimiento y conectividad distintos. Las cargas de trabajo que deben permanecer dentro de una jurisdicción determinada deben desplegarse en regiones que pertenezcan a la geografía objetivo para garantizar la alineación regulatoria y la residencia de los datos. Una región es un conjunto de centros de datos desplegados dentro de un perímetro definido por la latencia y conectados a través de una red dedicada de baja latencia. No todos los servicios o características están disponibles en todas las regiones, por lo que la capacidad y la disponibilidad de las características deben validarse en una fase temprana de la planificación. Las regiones que admiten Zonas de Disponibilidad proporcionan tres o más zonas de centros de datos físicamente separadas con energía, refrigeración y redes independientes. Los servicios con redundancia de zona (ZRS) y la arquitectura distribuida entre zonas protegen contra fallos a nivel de centro de datos, manteniendo al mismo tiempo un acceso de baja latencia dentro de la región. Cada región de Azure se empareja con otra región dentro de la misma geografía para formar un par de regiones (por ejemplo, North Europe con West Europe, East US con West US). Los pares de regiones permiten una recuperación priorizada durante interrupciones generalizadas, actualizaciones de plataforma escalonadas y la replicación de datos para ciertos servicios. Las opciones con redundancia geográfica de Azure Storage (GRS/GZRS) replican los datos de forma asíncrona en la región emparejada; cuando se requiere acceso de lectura al secundario, utilice RA-GRS o RA-GZRS para permitir lecturas desde el punto de conexión secundario durante una interrupción o una conmutación por error planificada. Para cargas de trabajo de misión crítica que requieren tanto alta disponibilidad dentro de la región como recuperación ante desastres entre regiones, combine la redundancia de zona con la replicación de pares de regiones. Equilibrar la latencia, la resiliencia y el cumplimiento conduce a un patrón común: desplegar cargas de trabajo activas en varias zonas de una región primaria y protegerse contra desastres regionales replicando datos y proporcionando rutas de conmutación por error a la región emparejada. Valide los runbooks de conmutación por error y el comportamiento del enrutamiento de DNS o front-end con regularidad para garantizar que se cumplen los objetivos de recuperación.

• Geografía
  • Ámbito: Límite multirregional
  • Beneficio clave: Residencia de datos y cumplimiento
  • Uso típico: Alineación regulatoria (p. ej., datos de la UE)
• Región
  • Ámbito: Área metropolitana única
  • Beneficio clave: Acceso de baja latencia a los servicios
  • Uso típico: Ubicación de despliegue principal
• Zona de Disponibilidad
  • Ámbito: Centros de datos distintos dentro de una región
  • Beneficio clave: Aislamiento de fallos a nivel de centro de datos
  • Uso típico: Alta disponibilidad dentro de la región
• Par de Regiones
  • Ámbito: Dos regiones en la misma geografía
  • Beneficio clave: Recuperación y actualizaciones coordinadas
  • Uso típico: Recuperación ante desastres entre regiones

Organización y gobernanza de recursos: Grupos de administración, suscripciones, grupos de recursos y recursos

La jerarquía de administración de Azure permite el control de políticas, acceso y costos a escala. Los grupos de administración se sitúan por encima de las suscripciones y le permiten aplicar Azure Policy y el control de acceso basado en roles (RBAC) de forma centralizada, con una herencia que se extiende en cascada a los grupos de administración y suscripciones secundarios. Esta es la estructura adecuada para segmentar por divisiones de la empresa, niveles de entorno (producción, no producción) o límites regulatorios, manteniendo al mismo tiempo barreras de protección uniformes. Las suscripciones son el límite administrativo, de facturación y de cuota. Son muy adecuadas para aislar el costo y el acceso para unidades de negocio, entornos o aplicaciones. Utilice un diseño de suscripción coherente para separar la producción de la no producción y para aplicar límites y presupuestos. Para organizaciones con múltiples divisiones y administración descentralizada, asigne a cada división una o más suscripciones y colóquelas bajo grupos de administración específicos de la división para una herencia limpia de políticas y RBAC. Los grupos de recursos son contenedores lógicos para recursos que comparten un ciclo de vida. Permiten implementaciones atómicas, etiquetado coherente y operaciones de ciclo de vida como la eliminación o el bloqueo. Agrupe los recursos que se implementan, actualizan y retiran juntos, como una capa web y sus componentes de monitoreo. Utilice etiquetas para impulsar la refacturación/visibilidad de costos (chargeback/showback), la propiedad, el entorno y los atributos de cumplimiento en todos los recursos y grupos. Los bloqueos (ReadOnly, CanNotDelete) añaden protección contra la eliminación accidental en el ámbito del recurso o del grupo. Los recursos son las instancias de servicio implementadas (VMs, planes de App Service, cuentas de almacenamiento). Los ámbitos de RBAC (grupo de administración, suscripción, grupo de recursos, recurso) permiten conceder acceso con privilegios mínimos precisamente donde se necesita. Para implementaciones de múltiples divisiones, mantenga un único inquilino de Microsoft Entra ID a menos que exista un requisito estricto de cumplimiento o autonomía para tener múltiples inquilinos; las suscripciones y los grupos de administración suelen proporcionar una separación suficiente con mucha menos carga administrativa.

• Grupo de administración
  • Propósito principal: Gobernanza a nivel de organización
  • Controles aplicados: RBAC, Policy, Blueprints (a través de Policy + plantillas)
  • Patrones comunes: Segmentación por división/regulación
• Suscripción
  • Propósito principal: Límite de facturación y cuota
  • Controles aplicados: Presupuestos, RBAC, Policy
  • Patrones comunes: Aislamiento por unidad de negocio o por entorno
• Grupo de recursos
  • Propósito principal: Límite de ciclo de vida
  • Controles aplicados: Bloqueos, Etiquetas, RBAC
  • Patrones comunes: Por aplicación o unidad de carga de trabajo
• Recurso
  • Propósito principal: Instancia de servicio
  • Controles aplicados: RBAC a nivel de instancia, Etiquetas
  • Patrones comunes: Componentes de servicio individuales

Azure Resource Manager y plantillas

Azure Resource Manager (ARM) es el plano de control para implementar, actualizar y eliminar recursos de Azure a través de una API y un modelo basado en roles coherentes. ARM proporciona operaciones idempotentes, gestión de dependencias, etiquetado y aplicación de políticas en el momento de la implementación, lo que permite que la gobernanza de la plataforma se integre en cada cambio. Las plantillas ARM declarativas describen el estado deseado de su entorno en JSON y admiten parámetros, variables, condiciones y plantillas vinculadas modulares. Permiten implementaciones repetibles y versionadas en todos los entornos y suscripciones. Para una experiencia de creación simplificada, Bicep ofrece una sintaxis concisa que transpila a plantillas ARM, conservando el mismo motor de implementación y beneficios. Almacene las plantillas en un control de código fuente, empaquételas como especificaciones de plantilla para compartirlas e intégrelas en canalizaciones de CI/CD para garantizar cambios de infraestructura auditables y sin desviaciones. Los valores sensibles como contraseñas de administrador o cadenas de conexión nunca deben incrustarse en las plantillas. Utilice parámetros secureString/secureObject con referencias a Key Vault para que ARM recupere los secretos en el momento de la implementación sin exponerlos en los registros. Combine plantillas con identidades administradas para eliminar credenciales codificadas en la automatización. Este enfoque reduce el riesgo mientras preserva la automatización completa para implementaciones a gran escala y en múltiples suscripciones.

• Implementaciones idempotentes
  • Soporte en ARM/Plantilla: Sí
  • Resultado: Cambios seguros y repetibles
• Aplicación de políticas en la implementación
  • Soporte en ARM/Plantilla: Sí
  • Resultado: Barreras de protección integradas en las canalizaciones
• Composición modular
  • Soporte en ARM/Plantilla: Módulos vinculados / Módulos de Bicep
  • Resultado: Reutilización y estandarización
• Manejo de secretos
  • Soporte en ARM/Plantilla: Referencias a Key Vault
  • Resultado: Sin secretos en el código o en los registros

Disponibilidad, SLA, SLA compuestos y ciclo de vida del servicio

Azure publica acuerdos de nivel de servicio (SLA) con respaldo financiero para los servicios con disponibilidad general (GA). Para las máquinas virtuales, la disponibilidad depende de la topología de la implementación: una única VM con almacenamiento Premium SSD tiene un SLA del 99.9 %; dos o más VM en un conjunto de disponibilidad tienen un SLA del 99.95 %; y dos o más VM implementadas en varias zonas de disponibilidad alcanzan un SLA del 99.99 %. Los servicios de plataforma (por ejemplo, Azure SQL Database o App Service) tienen sus propios SLA, que pueden variar según el nivel o la opción de redundancia. Alinee la arquitectura con el SLA objetivo seleccionando el modelo de redundancia y los niveles de servicio adecuados. Cuando una solución depende de múltiples servicios, el SLA compuesto es el producto de los SLA individuales si todos los componentes son necesarios para que la aplicación funcione. Por ejemplo, si una aplicación web (99.95 %) depende de una base de datos (99.99 %), la disponibilidad compuesta es de aproximadamente 0.9995 × 0.9999 = 99.94 %. Aumentar la redundancia en cualquier capa —como implementar en varias zonas, agregar múltiples instancias detrás de un balanceador de carga o usar almacenes de datos con redundancia geográfica— mejora la disponibilidad efectiva. Por el contrario, agregar dependencias en serie reduce el SLA compuesto y debe justificarse con un claro valor funcional. El estado del ciclo de vida del servicio afecta a las garantías de confiabilidad. Las características en versión preliminar pública (public preview) se ofrecen para recopilar comentarios y pueden estar limitadas a ciertas regiones o tener carencias de funcionalidades; normalmente no cuentan con un SLA y no se recomiendan para rutas críticas de producción. Las características GA (disponibilidad general) están listas para producción y están cubiertas por un SLA. Se debe hacer un seguimiento de las hojas de ruta y los calendarios de despliegue por región para evitar la dependencia involuntaria de características en versión preliminar en los diseños de producción, especialmente en entornos sensibles al cumplimiento normativo. Los objetivos de recuperación ante desastres, como RPO y RTO, complementan los SLA y guían las decisiones de diseño como la replicación entre zonas o entre regiones, la frecuencia de las copias de seguridad y la orquestación de la conmutación por error (failover). Valide los procedimientos de conmutación por error con regularidad para garantizar que el rendimiento de recuperación medido se alinee con los objetivos del negocio y que las dependencias de DNS, certificados e identidad también se recuperen como se espera.

• VM única (Premium SSD)
  • SLA indicativo: 99.9 %
  • Notas: Usar para cargas de trabajo no críticas o aplicaciones tolerantes
• 2+ VM en un conjunto de disponibilidad
  • SLA indicativo: 99.95 %
  • Notas: Protege contra fallos de rack/dominio de error
• 2+ VM en varias zonas de disponibilidad
  • SLA indicativo: 99.99 %
  • Notas: Protege contra fallos a nivel de centro de datos
• Característica en versión preliminar pública
  • SLA indicativo: Sin SLA financiero
  • Notas: Evaluar; evitar en rutas críticas
• Característica GA (dependiente del nivel de servicio)
  • SLA indicativo: Con respaldo de SLA
  • Notas: Consultar los SLA específicos del nivel y la región

Enrutamiento global y entrega de contenido: Azure Front Door, Traffic Manager y Azure CDN

La experiencia de usuario global depende del enrutamiento inteligente, la proximidad al contenido y la conmutación por error (failover) rápida. Azure Front Door es un proxy inverso global de capa 7 con anycast que incluye Web Application Firewall (WAF), terminación de TLS, enrutamiento basado en URL/ruta, afinidad de sesión y sondeos de estado desde el borde. Acelera el contenido dinámico mediante split-TCP y optimizaciones de protocolo, y proporciona una conmutación por error casi instantánea entre los orígenes. Front Door es ideal para aplicaciones web y API multirregión activas-activas o activas-pasivas donde se necesita tanto rendimiento como seguridad centralizada en el borde. Azure Traffic Manager es un servicio de distribución de tráfico basado en DNS que dirige a los clientes al mejor punto de conexión mediante directivas como prioridad, ponderado, rendimiento (latencia), geográfico, subred o multivalor. Debido a que opera a nivel de DNS, admite puntos de conexión que no son HTTP (p. ej., servicios TCP) y escenarios híbridos, pero la velocidad de conmutación por error está limitada por el TTL del DNS y el almacenamiento en caché del cliente. Traffic Manager no actúa como proxy para el tráfico ni acelera el contenido; simplemente responde a las consultas DNS con el punto de conexión elegido. Azure CDN almacena en caché el contenido estático en puntos de presencia de borde para reducir la latencia y descargar a los orígenes. Es muy adecuado para activos estáticos grandes como imágenes, videos, scripts y descargas. Aunque la CDN reduce los viajes de ida y vuelta para el contenido almacenable en caché, no es un balanceador de carga global consciente del estado para orígenes dinámicos; combínelo con Front Door o Traffic Manager para la conmutación por error de múltiples orígenes o para la lógica de enrutamiento dinámico. Muchas arquitecturas colocan una CDN para el almacenamiento en caché de activos estáticos y Front Door para el tráfico dinámico y la seguridad frente a la misma aplicación.

• Azure Front Door (Std/Prm)
  • Capa/Mecanismo: Proxy anycast de capa 7
  • Casos de uso principales: Balanceo de carga global, seguridad en el borde, aceleración
  • Métodos de enrutamiento: Prioridad, ponderado; reglas basadas en ruta/host
  • Sondeos de estado: Sondeos desde POP de borde
  • Velocidad de conmutación por error: Segundos (casi instantáneo)
  • Aceleración dinámica: Sí
  • Almacenamiento en caché estático: Sí (basado en reglas)
  • WAF disponible: Sí (integrado)
  • Patrón típico: Front Door frente a aplicaciones web/API multirregión
• Azure Traffic Manager
  • Capa/Mecanismo: Directiva basada en DNS
  • Casos de uso principales: Enrutamiento DNS entre regiones; puntos de conexión no HTTP
  • Métodos de enrutamiento: Prioridad, ponderado, rendimiento, geográfico, subred, multivalor
  • Sondeos de estado: Sondeos de puntos de conexión globales
  • Velocidad de conmutación por error: Limitado por TTL (decenas de segundos a minutos)
  • Aceleración dinámica: No
  • Almacenamiento en caché estático: No
  • WAF disponible: N/A
  • Patrón típico: Direccionamiento DNS para servicios HTTP y no HTTP
• Azure CDN
  • Capa/Mecanismo: Red de almacenamiento en caché de borde
  • Casos de uso principales: Descarga de contenido estático y reducción de latencia
  • Métodos de enrutamiento: N/A (reglas de caché)
  • Sondeos de estado: N/A (conmutación por error de grupo de origen opcional)
  • Velocidad de conmutación por error: N/A (basado en caché)
  • Aceleración dinámica: No (más allá de la caché)
  • Almacenamiento en caché estático: Sí
  • WAF disponible: A través de Front Door Premium o un WAF separado
  • Patrón típico: CDN para activos + Front Door/Traffic Manager para orígenes

Problema práctico: Diseño de una plataforma web de alto rendimiento global, compatible y con alta disponibilidad para IronPeak Manufacturing

Escenario: IronPeak Manufacturing opera en Europa y Norteamérica y está consolidando los portales de clientes y socios en Azure. La plataforma debe cumplir con una disponibilidad del 99.99 % para la capa web, mantener los datos de los clientes de la UE dentro de la UE, proporcionar una conmutación por error (failover) rápida entre regiones y ofrecer tiempos de carga de página rápidos en todo el mundo. El equipo desea implementaciones totalmente automatizadas sin secretos en texto plano en el código o en los registros.

Desafío: Lograr alta disponibilidad dentro de la región y recuperación ante desastres entre regiones con residencia de datos en la UE, aceleración global y conmutación por error para tráfico dinámico, e implementaciones repetibles y seguras entre suscripciones.

Enfoque recomendado:

1. Seleccionar la geografía de Europa e implementar la carga de trabajo principal en una región con Availability Zones (por ejemplo, West Europe) utilizando dos o más instancias de VM scale set o instancias de App Service distribuidas entre las zonas.
2. Habilitar la recuperación ante desastres entre regiones hacia la región emparejada (North Europe) utilizando la replicación nativa de los servicios: usar RA-GZRS para Storage y la georreplicación para bases de datos donde esté disponible; configurar runbooks de conmutación por error automatizada.
3. Utilizar Azure Front Door Standard/Premium como punto de entrada de la aplicación para la terminación global de HTTPS, WAF, sondeos de estado en el borde (edge), conmutación por error basada en prioridad entre West Europe (primaria) y North Europe (secundaria), y reglas para el enrutamiento basado en rutas.
4. Almacenar en caché los activos estáticos (imágenes, scripts, descargas) utilizando Azure CDN integrado con los mismos orígenes para reducir la latencia y descargar tráfico; validar las reglas de caché y los TTL.
5. Definir grupos de administración para las divisiones de la UE y NA; colocar las suscripciones de producción y no producción bajo cada uno, aplicando Azure Policy para la residencia de datos, el etiquetado y las ubicaciones permitidas.
6. Implementar plantillas ARM/Bicep almacenadas en el control de código fuente y publicadas como especificaciones de plantilla; parametrizar regiones, SKUs y escalado; hacer referencia a secretos de Azure Key Vault utilizando identidades administradas para las implementaciones.
7. Establecer SLAs y probar la disponibilidad compuesta: dos instancias distribuidas por zona detrás de Front Door apuntan a un 99.99 % para la capa de aplicación; validar trimestralmente los simulacros de conmutación por error de extremo a extremo, DNS, certificados y dependencias de identidad.
8. Instrumentar la plataforma con Application Insights y Azure Monitor; configurar los sondeos de estado y las alertas de Front Door; ajustar las políticas de autoescalado y almacenamiento en caché basándose en la telemetría.

Justificación de Azure: Este diseño mantiene los datos de la UE dentro de la geografía de Europa, a la vez que proporciona aislamiento de fallos dentro de la región mediante Availability Zones y recuperación ante desastres entre regiones hacia la región emparejada. Azure Front Door ofrece aceleración global y conmutación por error consciente del estado para el tráfico dinámico, mientras que Azure CDN descarga el contenido estático para mejorar el rendimiento. Las plantillas ARM/Bicep con referencias a Key Vault proporcionan implementaciones repetibles y seguras en todas las suscripciones y regiones. Las topologías elegidas se alinean con los SLAs publicados para cumplir el objetivo del 99.99 % para la capa web, y las políticas a nivel de grupo de administración y suscripción imponen la gobernanza con una sobrecarga operativa mínima.

← Conceptos de la nube · Todos los dominios · Cómputo y servicios de aplicaciones →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →

Explorar Microsoft →