AZ-305 Cheat Sheet

RBAC controla QUIÉN puede hacer QUÉ acción. Azure Policy controla QUÉ configuración/recurso es válido, independientemente de quién lo cree.

Un custom role se define en un scope (sub/MG) y puede asignarse en ese scope o inferiores. AssignableScopes limita dónde puede usarse.

Bloquea la operación de creación/actualización si no cumple la regla. Se evalúa antes de que el recurso se cree (a diferencia de Audit).

Efecto que despliega automáticamente un recurso relacionado si falta (ej. Diagnostic Settings). Requiere identidad administrada con permisos.

Activación just-in-time de roles con aprobación, MFA y expiración automática. Reduce standing access de roles privilegiados.

Hasta 6 niveles de profundidad + root. RBAC y Policy se heredan de arriba hacia abajo por toda la jerarquía.

Agrupa varias definiciones de Policy relacionadas (ej. CIS Benchmark) para asignarlas juntas como una unidad de compliance.

Balanceo a nivel DNS (capa de nombre). No ve el tráfico HTTP real, solo resuelve el dominio al endpoint óptimo. Funciona con cualquier protocolo.

Balanceo global L7 (HTTP/S) con terminación TLS, WAF, caching y routing basado en path — actúa como reverse proxy global (anycast).

Balanceo L7 regional (dentro de una región/VNet). WAF, path-based routing, SSL offload. No es global como Front Door.

Patrón común: Front Door como entrada global (WAF, cache), App Gateway como balanceador regional detrás, dentro de cada región.

Priority, Weighted, Performance, Geographic, MultiValue, Subnet — cada uno resuelve el DNS con una estrategia distinta.

Si el tráfico no es HTTP/S (ej. TCP/UDP crudo, RDP, SQL directo) — usar Traffic Manager o Load Balancer en su lugar.

Crea una NIC con IP privada de la VNet para el servicio PaaS. Tráfico nunca sale a Internet — accesible incluso on-premises vía VPN/ER.

Optimiza la ruta hacia el servicio por el backbone de Azure, pero el recurso conserva IP pública. Solo funciona desde dentro de la misma región/VNet.

Permite exponer tu propio servicio (detrás de un Standard LB) como Private Endpoint consumible por otras VNets/tenants.

Requiere Private DNS Zone vinculada a la VNet para resolver el FQDN público al IP privado del endpoint (ej. privatelink.blob.core.windows.net).

Al habilitar Private Endpoint se recomienda deshabilitar el acceso público del recurso PaaS para forzar todo el tráfico por la ruta privada.

Service Endpoint es gratis. Private Endpoint tiene costo por hora + procesamiento de datos.

El recurso se ancla a UNA zona específica (ej. VM pinned a Zone 1). Si esa zona falla, el recurso no está disponible.

El servicio replica automáticamente entre las zonas de disponibilidad de la región (ej. ZRS Storage, Standard LB zone-redundant). Sin acción del cliente.

El recurso no tiene awareness de zonas — vive en un único datacenter lógico dentro de la región.

Requiere una región con soporte de Availability Zones (no todas las regiones Azure las tienen).

Availability Zones protegen contra falla de datacenter (misma región). Región secundaria (par) protege contra falla regional completa.

VMs distribuidas en 2+ Availability Zones ofrecen SLA de 99.99%, el más alto disponible para VMs.

Debe elegirse para distribuir uniformemente lecturas/escrituras y evitar "hot partitions". No se puede cambiar tras crear el container.

Unidad de medida normalizada de costo de operación. Se puede provisionar manual, autoscale, o serverless.

Comparte recursos (eDTU/vCore) entre múltiples bases de datos con patrones de uso variables — optimiza costo en multi-tenant SaaS.

Geo-replication crea réplicas legibles. Failover Group añade un listener con failover automático/manual y agrupa varias BD.

Cifra datos en reposo a nivel de página en SQL Database/MI. Habilitado por defecto, usa claves gestionadas por Microsoft o BYOK.

El compute vCore serverless se pausa tras inactividad configurable y solo cobra storage — ideal para cargas intermitentes.

Reglas basadas en días desde última modificación/acceso para mover automáticamente blobs entre Hot → Cool → Archive → Delete.

RPO = cuánta pérdida de datos es aceptable (medido hacia atrás desde el fallo). RTO = cuánto tiempo de downtime es aceptable.

Replica VMs completas (SO + discos) continuamente a región secundaria. RPO de segundos/minutos, RTO de minutos vía failover orquestado.

Backup protege contra pérdida/corrupción de datos (RPO horas). ASR protege contra caída de datacenter/región completa (RPO minutos).

Configurable LRS/ZRS/GRS. GRS es el default y recomendado — el vault mismo debe sobrevivir al desastre que protege.

Tiempo de espera antes del failover automático (default 1h) para evitar failovers innecesarios por outages transitorios.

Azure prioriza actualizaciones secuenciales y recuperación conjunta entre regiones emparejadas (ej. East US ↔ West US).