Azure Policy es el mecanismo de policy-driven governance del CAF: convierte reglas de negocio ("solo regiones europeas", "todo recurso con tag de cost center", "discos siempre cifrados") en guardrails automáticos. El AZ-305 evalúa que elijas el efecto correcto y el ámbito correcto para cada requisito.
Contenido
| Mecanismo | Controla | Pregunta que responde |
|---|---|---|
| Azure RBAC | QUIÉN puede hacer QUÉ acciones | ¿Puede este usuario crear VMs en este resource group? |
| Azure Policy | QUÉ propiedades pueden tener los recursos | ¿Esta VM puede ser de la serie GS5? ¿Puede estar fuera de West Europe? |
| Resource Locks | Protección contra borrado/modificación | ¿Alguien (incluso un Owner) puede borrar este recurso? |
Clave de diseño
Policy y RBAC son complementarios e independientes: aunque tengas rol Owner, una policy con deny te bloquea. Policy se evalúa en el plano de control (ARM) — no inspecciona el plano de datos (con excepciones como policies de Key Vault y Kubernetes).
| Efecto | Qué hace | Escenario típico |
|---|---|---|
| Deny | Rechaza la creación/actualización que incumple | Bloquear regiones no permitidas, SKUs caros, IPs públicas |
| Audit | Permite pero marca como non-compliant | Fase de evaluación antes de endurecer; visibilidad sin romper |
| AuditIfNotExists | Audita si falta un recurso relacionado | VMs sin extensión de monitoreo instalada |
| DeployIfNotExists (DINE) | Despliega automáticamente el recurso faltante (remediación) | Instalar agente de Log Analytics, habilitar diagnostic settings |
| Modify | Altera propiedades/tags en creación o remediación | Añadir/heredar tags, habilitar propiedades (HTTPS only) |
| Append | Añade campos a la request (legacy, preferir Modify) | Añadir reglas de IP a storage accounts |
| Disabled | Desactiva la regla sin quitar la asignación | Pausar temporalmente una política |
Importante para el examen
Ámbito de asignación
Una initiative agrupa múltiples policy definitions bajo una sola asignación con parámetros compartidos. Diseño recomendado: asignar initiatives, no políticas sueltas — simplifica la gestión y el reporte de compliance agregado.
Initiatives integradas clave
Evaluación de compliance
Cómo funciona una remediation task
Trampa de examen
"Las VMs existentes no tienen el agente de monitoreo y la política de deny no lo soluciona" — correcto, deny solo previene. Para instalar el agente en lo existente se necesita una política DeployIfNotExists + remediation task con managed identity.
| Requisito | Efecto / diseño |
|---|---|
| Impedir crear recursos fuera de West Europe / North Europe | Deny (allowed locations) en management group |
| Saber qué storage accounts permiten acceso público, sin romper nada | Audit |
| Instalar automáticamente el agente AMA en VMs nuevas y existentes | DeployIfNotExists + remediation task |
| Heredar el tag CostCenter del resource group a cada recurso | Modify + remediation task |
| Exigir tag Environment al crear cualquier recurso | Deny si falta el tag |
| Demostrar cumplimiento con PCI DSS | Initiative de regulatory compliance PCI DSS |
| Eximir temporalmente una suscripción de una política | Policy exemption con expiración |
| Limitar VMs a SKUs aprobados para controlar costos | Deny (allowed SKUs) |
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
Una empresa exige que todas las VMs (nuevas y existentes, en 30 suscripciones) tengan instalada la extensión de Azure Monitor Agent. El equipo de gobernanza quiere mínimo esfuerzo manual. ¿Qué diseñas?
Inicia sesión para llevar tu progreso.