El diseño de gobernanza y cumplimiento en AZ-305 va mucho más allá de la memorización: exige la capacidad de juzgar qué herramienta corresponde a cada situación. El diseño de jerarquías de Management Group, la selección del efecto correcto en Azure Policy, la gobernanza de costos, las estrategias de etiquetado y la infraestructura como código (IaC) son conceptos profundamente entrelazados que aparecen juntos en las preguntas del examen. Este artículo analiza 37 preguntas reales del examen y extrae los patrones más frecuentes y los criterios de decisión más importantes.
---
Management Groups y diseño de jerarquía de suscripciones
Un Management Group es un contenedor que agrupa el entorno de Azure desde una perspectiva de gobernanza. La jerarquía se estructura de la siguiente manera:
Las políticas y los roles asignados en un nivel superior se heredan automáticamente por todos los niveles inferiores. Si aplicas la política "Permitir solo Korea Central" al Production Management Group, las tres suscripciones que están por debajo de él quedarán gobernadas por esa política. El Development Management Group, que es un nodo hermano (sibling), no se verá afectado.
Cuando aparezca una pregunta sobre jerarquía de Management Groups en el examen, lo primero que debes verificar es: "¿Es la suscripción destino un descendiente del nodo de asignación de la política?" Aunque dos suscripciones pertenezcan al mismo tenant, si están en ramas diferentes del árbol de Management Groups, las políticas no se propagarán entre ellas.
Los selectores de recursos no amplían el alcance de una política; sirven para filtrar qué recursos, dentro del alcance ya definido, se evalúan. El alcance de asignación de Azure Policy se limita a tres niveles: Management Group, Suscripción o Grupo de recursos. No es posible asignar una política a un recurso individual ni a un tenant de Entra ID como unidad.
---
Azure Policy e iniciativas
Azure Policy es un sistema que aplica reglas de forma automática. Si RBAC controla "quién puede hacer qué", Policy controla "dónde, cómo y bajo qué condiciones se pueden realizar las implementaciones".
Los cinco efectos de Policy
| Efecto | Comportamiento | Caso de uso principal | |--------|---------------|----------------------| | Deny | Rechaza inmediatamente la solicitud de implementación a nivel de ARM | Bloquear regiones o tipos de recursos no autorizados | | Audit | Registra el incumplimiento sin bloquearlo | Evaluar el alcance del impacto al inicio del despliegue de una política | | Append | Agrega nuevos valores junto a los existentes (sin sobrescribir) | Agregar etiquetas simples preservando los valores actuales | | Modify | Agrega o modifica propiedades y etiquetas existentes + soporte de remediación | Corregir etiquetas automáticamente, heredar etiquetas del grupo de recursos | | DeployIfNotExists | Implementa automáticamente un recurso relacionado cuando falta una configuración | Habilitar TDE automáticamente, instalar agentes automáticamente |
Modify y Append son fáciles de confundir. Cuando veas "modificar etiquetas de recursos existentes y aplicarlo retroactivamente", elige siempre Modify. Append no puede sobrescribir valores existentes y no admite tareas de remediación.
Las políticas con DeployIfNotExists deben incluir . Esto otorga a la Managed Identity el rol de RBAC necesario para modificar el recurso destino. La entidad que ejecuta la remediación es la System-assigned Managed Identity vinculada a la asignación de la política, no una cuenta de usuario. Para tareas con privilegios mínimos, como cambios de etiquetas, basta con asignar solo el rol Tag Contributor.
Una iniciativa agrupa varias políticas en un solo paquete. Si combinas una "política de restricción de regiones" y una "política de restricción de tamaño de VM" en una iniciativa, con asignar esa iniciativa una sola vez a una suscripción ambas políticas se aplican de forma simultánea.
Las evaluaciones de políticas se ejecutan automáticamente cada 24 horas por defecto. Para una evaluación inmediata, usa a través de la REST API o ejecuta . Para notificaciones instantáneas ante eventos de incumplimiento, combina Azure Event Grid con Logic Apps.
!Los 5 efectos de Azure Policy
Gobernanza de costos y Cost Management
Si necesitas rastrear costos por proyecto en 20 o más suscripciones sin reestructurar el layout de suscripciones, etiqueta todos los recursos con claves como , y , y luego filtra los costos por valor de etiqueta en Microsoft Cost Management.
La funcionalidad de presupuesto (Budget) en Cost Management envía alertas automáticas por correo electrónico o mediante Action Groups cuando los costos reales o proyectados alcanzan un umbral configurado. Puedes definir hasta cinco umbrales. Azure Advisor ofrece recomendaciones de ahorro de costos, pero no proporciona alertas por exceso de presupuesto.
Para cargas de trabajo que operan 24/7, considera las Reserved Instances. Con un compromiso de uno o tres años, puedes ahorrar hasta un 72% en comparación con los precios de pago por uso en VMs, SQL Database, App Service y otros servicios, sin afectar la disponibilidad ni el SLA. Las Spot VMs pueden reducir los costos hasta un 90%, pero Azure puede interrumpirlas en cualquier momento, por lo que no son adecuadas para cargas de trabajo de producción siempre activas.
---
Estrategia de etiquetado y bloqueos de recursos
Las etiquetas funcionan como notas adhesivas aplicadas a los recursos. Se asocian pares clave-valor como o para transportar metadatos. Un comportamiento importante a tener en cuenta: las etiquetas no se heredan automáticamente de niveles superiores a inferiores. Etiquetar un grupo de recursos no etiqueta automáticamente los recursos dentro de él.
Para forzar etiquetas obligatorias en todos los recursos, usa tanto el efecto Deny (bloquear nuevas implementaciones sin la etiqueta) como el efecto Modify (corregir retroactivamente los recursos existentes). La política integrada "Inherit a tag from the resource group" también usa el efecto Modify para propagar etiquetas automáticamente.
Los Resource Locks protegen los recursos de producción de eliminaciones o modificaciones accidentales.
Bloqueo Delete: solo impide la eliminación; los cambios de configuración siguen siendo posibles. Bloqueo ReadOnly: bloquea todas las operaciones de escritura: ni modificaciones ni eliminaciones son posibles.
Los Resource Locks son independientes de RBAC. Incluso un usuario con permisos de Owner no puede eliminar ni modificar un recurso bloqueado. Si necesitas impedir una acción específica sobre un recurso (por ejemplo, bloquear la asignación de una IP pública) incluso para los Contributors, usa Azure Policy Deny en lugar de un bloqueo.
---
Tablas comparativas de servicios
Guía de selección del efecto de Policy
| Escenario | Efecto elegido | Razón | |-----------|---------------|-------| | Bloquear implementaciones en regiones no autorizadas | Deny | Control preventivo a nivel de ARM | | Identificar recursos no conformes sin bloquear | Audit | Solo detección, sin aplicación | | Heredar etiquetas del grupo de recursos a recursos hijos | Modify | Modifica propiedades existentes + remediación | | Aplicar retroactivamente etiquetas faltantes a recursos existentes | Modify | Admite tareas de remediación | | Auto-instalar agente de diagnóstico al crear una VM | DeployIfNotExists | Implementa automáticamente el recurso/configuración faltante | | Habilitar TDE automáticamente en SQL Database | DeployIfNotExists | Implementa la configuración faltante + remediación | | Bloquear la implementación de recursos sin etiquetas | Deny | Control preventivo |
Comparativa de herramientas de gobernanza
| Herramienta | Función principal | Limitación | |-------------|------------------|-----------| | Azure Policy | Evaluar y aplicar cumplimiento (control de condiciones) | No puede asignar roles ni implementar plantillas ARM | | Azure RBAC | Controlar permisos de operación de usuarios y grupos | No puede restringir condiciones de implementación (región, SKU) | | Azure Blueprints | Paquete de Policy + roles + ARM + RG | No se puede compartir entre tenants | | Resource Lock | Bloquear eliminación y modificación (incluidos los Owners) | No puede detectar incumplimiento ni auto-remediar | | Cost Management | Seguimiento de costos, presupuestos y alertas | No puede controlar la implementación de recursos |
---
Puntos de decisión que confunden con frecuencia en el examen
Escenario 1: Se configuró una política de ubicación para el grupo de recursos, pero los recursos siguen implementándose en otras regiones
La política de ubicación del grupo de recursos solo controla en qué región se crea el propio grupo de recursos. Servicios como App Service o SQL Database pueden implementarse en una región diferente a la de su grupo de recursos. Debes agregar una política Deny separada con alcance a nivel de suscripción que tenga como objetivo la ubicación del recurso. La política integrada "Allowed locations" controla simultáneamente tanto la ubicación del grupo de recursos como la de los recursos individuales.
Escenario 2: Calcular el número mínimo de definiciones y asignaciones en Blueprints
N tenants + definiciones mínimas → N definiciones (Blueprints no puede cruzar límites de tenant) M suscripciones + asignaciones mínimas → M asignaciones (cada asignación se aplica 1:1 por suscripción)
Dentro de un solo tenant, una definición puede tener múltiples asignaciones apuntando a distintas suscripciones. Si hay diferentes tenants, debes crear una definición separada por cada tenant.
Escenario 3: Control preventivo vs. detección reactiva
Cuando veas "impedir la implementación en sí", elige Azure Policy Deny. El panel de cumplimiento de Microsoft Defender for Cloud es una herramienta reactiva: muestra las infracciones después de que la implementación ya ocurrió. Para detener algo antes de que se implemente (preventivo), Azure Policy D