AZ-104
Deep Dive
Azure Policy permite evaluar y controlar el cumplimiento de recursos a escala. Es una de las secciones más frecuentes en el AZ-104: efectos, ámbito, iniciativas y la diferencia entre audit y deny son preguntas garantizadas.
Contenido
Azure Policy es un servicio de gobernanza que permite crear, asignar y gestionar polÃticas que controlan o auditan la configuración de recursos en Azure. A diferencia de RBAC (que controla quién puede hacer qué), Policy controla qué configuraciones están permitidas independientemente de quién ejecute la acción.
RBAC
Quién puede hacer qué. Controla acciones de usuarios y servicios.
Policy
Qué configuración está permitida. Controla el estado de los recursos.
Locks
Qué operaciones de gestión están bloqueadas sobre un recurso especÃfico.
Casos de uso tÃpicos
Una definición de policy es un documento JSON que describe las condiciones bajo las cuales se aplica y el efecto resultante. Tiene dos partes clave: policyRule (condición + efecto) y parameters (valores configurables).
| Campo | Descripción | Ejemplo |
|---|---|---|
| displayName | Nombre legible de la policy | "Require tags on resources" |
| description | Explicación detallada del propósito | "All resources must have a CostCenter tag" |
| mode | Alcance: All (todos) o Indexed (solo con tags y location) | "All" |
| parameters | Valores parametrizables en la asignación | { "tagName": { "type": "String" } } |
| policyRule.if | Condición lógica que activa la policy | { "field": "tags", "notContainsKey": "[parameters('tagName')]" } |
| policyRule.then.effect | Acción cuando se cumple la condición | "deny" | "audit" | "modify" |
// Estructura mÃnima de una Policy Definition
{
"mode": "All",
"parameters": {
"allowedLocations": {
"type": "Array",
"metadata": { "displayName": "Allowed locations" }
}
},
"policyRule": {
"if": {
"not": {
"field": "location",
"in": "[parameters('allowedLocations')]"
}
},
"then": { "effect": "deny" }
}
}Tipos de definición
Built-in
Creadas y mantenidas por Microsoft. No modificables. Prefijo /providers/Microsoft.Authorization/policyDefinitions/
Custom
Creadas por tu organización. Requieren JSON propio. LÃmite: 500 custom policies por tenant.
El efecto determina qué pasa cuando la condición de la policy se cumple. El AZ-104 evalúa especialmente la diferencia entre deny (bloquea la operación) y audit (solo registra, no bloquea).
| Efecto | Comportamiento | Bloquea? | Cuándo usar |
|---|---|---|---|
| deny | Bloquea la operación PUT/PATCH si viola la policy. Devuelve error 403. | ✅ Sà | Norma que NUNCA se debe incumplir |
| audit | Permite la operación pero marca el recurso como NonCompliant en el dashboard. | ⌠No | Visibilidad sin impacto operativo |
| auditIfNotExists | Audita si un recurso relacionado NO existe (ej: VM sin extensión). | ⌠No | Detectar recursos faltantes relacionados |
| modify | Agrega, actualiza o elimina tags/propiedades durante CREATE/UPDATE. | ⌠No | Estandarizar tags automáticamente |
| append | Añade campos al recurso durante CREATE/UPDATE (sin eliminar existentes). | ⌠No | Forzar configuración adicional |
| deployIfNotExists | Despliega un recurso relacionado si no existe (usa identidad administrada). | ⌠No | Remediar recursos existentes automáticamente |
| disabled | La policy está definida pero no se evalúa. Útil para testing. | ⌠No | Desactivar temporalmente sin borrar |
Orden de evaluación de efectos
Cuando varias policies aplican, Azure evalúa los efectos en este orden de precedencia:
Una iniciativa (también llamada Policy Set) agrupa múltiples definiciones de policy en un único objeto asignable. Facilita la gestión cuando necesitas aplicar 20+ policies relacionadas de una vez, como el estándar CIS o PCI-DSS.
Iniciativas Built-in importantes
Policy vs Iniciativa
Policy Definition
Una regla: "negar recursos fuera de eastus"
Initiative Definition
Conjunto de reglas: todas las reglas CIS juntas (150+ policies)
Policy Assignment
Asignación de policy O iniciativa a un scope
Una policy solo tiene efecto cuando se asigna. El ámbito define dónde aplica y puede ser Management Group, Subscription, Resource Group, o recurso individual.
JerarquÃa de scope — herencia hacia abajo
Componentes de una Policy Assignment
El dashboard de compliance (Portal → Policy → Compliance) muestra el estado de cumplimiento de todas las policies y recursos. Los estados posibles son:
Compliant
Recurso cumple la policy
Non-compliant
Recurso viola la policy (si efecto es audit)
Exempt
Recurso excluido explÃcitamente
Conflict
Dos polÃticas en conflicto sobre el mismo recurso
Ciclo de evaluación
Las policies se evalúan automáticamente cada 24 horas. También se evalúan inmediatamente cuando:
az policy state trigger-scanLas policies con efecto deployIfNotExists o modifypueden remediar recursos existentes que no cumplen la policy. Los nuevos recursos son controlados automáticamente, pero los recursos ya existentes requieren una tarea de remediación explÃcita.
Flujo de remediación
â–¸1. Asignar policy con efecto deployIfNotExists o modify
▸2. La policy evalúa recursos existentes → marca NonCompliant
▸3. Crear una Remediation Task (Portal → Policy → Remediation → New)
▸4. La task usa la Managed Identity de la asignación para ejecutar el deploy/modify
â–¸5. Recursos pasan a estado Compliant tras completarse
Requisito importante
La Managed Identity de la asignación debe tener el rol Contributor (o equivalente) en el scope donde va a remediar. Sin permisos, la remediación falla silenciosamente.
Exclusión (Not Scope)
Se define al momento de asignar. Excluye sub-scopes especÃficos del ámbito de la asignación.
El RG Dev-RG queda exento de la policy aunque esté dentro de la suscripción.
Exemption
Excepción formal con caducidad y categorÃa. Aparece en el dashboard como "Exempt" (no como NonCompliant).
| Nombre | Efecto | Qué hace |
|---|---|---|
| Allowed locations | deny | Restringe dónde se pueden crear recursos |
| Allowed virtual machine size SKUs | deny | Limita tamaños de VM permitidos |
| Require a tag and its value on resources | deny | Exige tag especÃfico con valor concreto |
| Add a tag to resources | modify | Añade tag automáticamente si no existe |
| Audit VMs that do not use managed disks | audit | Detecta VMs con discos no administrados |
| Deploy Log Analytics agent for Windows VMs | deployIfNotExists | Instala agente AMA en VMs nuevas |
| Storage accounts should use customer-managed keys | audit | Audita cuentas sin CMK configurada |
| MFA should be enabled on accounts with write permissions | auditIfNotExists | Audita cuentas admin sin MFA |
deny vs audit — cuándo bloquea
Audit NO bloquea la creación del recurso, solo lo marca como NonCompliant. Solo deny impide la operación. Pregunta tÃpica: "Necesitas que nadie pueda crear recursos fuera de westeurope" → deny, no audit.
Policy NO es retroactiva por defecto
Una policy asignada hoy no remedia recursos existentes. Solo controla recursos nuevos o modificados. Para remediar existentes necesitas una Remediation Task (solo con deployIfNotExists o modify).
deployIfNotExists requiere Managed Identity
Cuando asignas una policy con efecto deployIfNotExists o modify, DEBES configurar una managed identity en la asignación. Sin ella, la remediación no funciona.
Policy vs RBAC: independientes y complementarios
RBAC deny impide realizar la acción. Policy deny impide el resultado (el recurso en ese estado). Un Owner puede ser bloqueado por Policy aunque RBAC no lo restrinja.
LÃmite de custom policies
500 policy definitions customizadas por tenant. 200 initiative definitions customizadas. 200 exemptions por asignación. Estos lÃmites aparecen en escenarios de diseño.
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
Una empresa necesita garantizar que NINGÚN recurso de Azure pueda crearse fuera de las regiones westeurope y northeurope, incluyendo recursos creados por Global Administrators. ¿Cuál es la solución correcta?