La gobernanza es la columna vertebral del AZ-305: cómo organizar management groups, cuántas suscripciones crear, dónde aplicar políticas y RBAC, y cómo el Cloud Adoption Framework estructura todo en Azure Landing Zones. Las preguntas suelen darte una estructura organizacional y pedirte el diseño de jerarquía correcto.
Contenido
La jerarquía de Azure: Tenant → Management Groups (hasta 6 niveles) → Suscripciones → Resource Groups → Recursos. RBAC y Azure Policy asignados en un nivel se heredan hacia abajo. El diseño correcto minimiza asignaciones duplicadas.
Reglas clave de management groups
Principio de diseño
Agrupar suscripciones por requisitos de gobernanza comunes, no por estructura organizacional ni geografía. Si Prod y Dev necesitan políticas distintas → management groups separados. Si dos departamentos necesitan exactamente las mismas políticas → pueden compartir management group.
La suscripción es la unidad de facturación, límites de servicio (quotas), y aislamiento administrativo. Razones legítimas para separar suscripciones:
| Driver | Por qué separa suscripciones |
|---|---|
| Límites de plataforma (quotas) | Quotas (vCPUs, VNets, storage accounts) son por suscripción — un workload masivo puede agotar la quota de otros. |
| Aislamiento de ambientes | Prod vs Dev/Test: políticas distintas, RBAC distinto, ofertas de precio Dev/Test. |
| Separación de facturación | Chargeback por unidad de negocio o cliente — la suscripción es la línea natural de la factura. |
| Límite de seguridad/blast radius | Compromiso o error en una suscripción no afecta los recursos de otra. |
| Requisitos regulatorios | Workloads PCI/HIPAA aislados con sus propias políticas y auditoría. |
Anti-patrón
Una suscripción por aplicación pequeña → explosión administrativa. Una sola suscripción para toda la empresa → choque de quotas y RBAC sin granularidad. El examen premia el equilibrio: suscripciones por ambiente + workload significativo, gobernadas por management groups.
Una landing zone es un entorno pre-configurado (identidad, red, gobernanza, monitoreo) donde aterrizan los workloads. La arquitectura conceptual del CAF define una jerarquía de management groups estándar que el examen espera que reconozcas.
Jerarquía CAF de referencia
Principios de diseño de landing zones
Implementación
| Requisito | Diseño |
|---|---|
| Aplicar una política a 40 suscripciones sin repetir asignaciones | Asignarla en un management group ancestro |
| Prod y Dev con guardrails distintos | Management groups separados (Prod / Non-Prod) |
| Workload masivo amenaza quotas de otros equipos | Suscripción dedicada para ese workload |
| Chargeback de costos por unidad de negocio | Suscripciones por BU + tags de cost center |
| Evitar borrado accidental de recursos críticos | Resource lock CanNotDelete |
| Heredar tag de cost center del resource group | Azure Policy con efecto modify |
| Entorno estándar repetible para nuevos equipos | Landing zone con Bicep/Terraform (acelerador CAF) |
| Experimentos sin riesgo para corp | Management group Sandbox sin conectividad y políticas relajadas |
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
Una multinacional tiene 60 suscripciones: 25 de producción, 20 de desarrollo, 10 de plataforma compartida (red, identidad) y 5 de sandbox. Necesitan: políticas estrictas en producción, políticas relajadas en sandbox, y que el equipo central administre solo las de plataforma. ¿Cuál es el diseño de jerarquía correcto?
Inicia sesión para llevar tu progreso.