Azure · AZ-104

Azure Storage (AZ-104) — Redundancia, seguridad y WORM

Dominio: Almacenamiento en Azure Nivel: Intermedio Tiempo de lectura: 30–40 min Última revisión: Nov 2025

0. Rol del almacenamiento en AZ-104

Azure Storage está presente en casi todos los escenarios de AZ-104: guardar discos, logs, backups, estáticos web, etc.

Diferenciar cuentas v2 de propósito general, premium y escenarios especiales.
Elegir el nivel de redundancia correcto según requisitos de disponibilidad y coste.
Saber cuándo usar claves, tokens SAS o RBAC para delegar acceso.
Configurar inmutabilidad y protecciones frente a borrado accidental o ransomware.

1. Tipos de cuenta y redundancia

Para el examen centra tu cabeza en las cuentas StorageV2 (propósito general v2). A partir de ahí decide la redundancia:

Opción	Descripción	Uso típico
LRS	Copia sincrónica de los datos 3 veces en un único datacenter.	Entornos de desarrollo, backups secundarios, escenarios donde la pérdida regional es aceptable.
ZRS	Replicación sincrónica entre varias zonas de una región.	Aplicaciones productivas que necesitan alta disponibilidad dentro de la región.
GRS	LRS local + replicación asíncrona a una región emparejada (lectura solo tras failover).	Escenarios de DR económico, con capacidad de hacer geo-failover manual.
GZRS	ZRS local + replicación asíncrona a región emparejada.	Cargas críticas que requieren resiliencia a fallos de zona y región.

Pregunta típica: “máxima disponibilidad dentro de la región sin replicar a otra región” → ZRS. “protección ante caída completa de región” → GRS o GZRS según nivel de criticidad.

2. Control de acceso: claves, SAS y RBAC

Existen tres grandes formas de acceso a Storage:

Claves de cuenta (account keys): control total, evita usarlas directamente en aplicaciones.
Shared Access Signatures (SAS): tokens firmados que limitan permiso, tiempo y origen.
RBAC con Azure AD: acceso basado en identidades y roles, ideal para producción.

Clave de cuenta vs SAS vs RBAC en el examen

Si el enunciado habla de “shared key” o herramientas antiguas → claves o SAS.
Si pide revocar acceso rápidamente a un partner concreto → SAS con expiración y revocación.
Si enfatiza seguridad y cumplimiento → RBAC + Managed Identities.

# Generar SAS de lectura sobre un contenedor durante 1 día
az storage container generate-sas \
  --account-name mystorage \
  --name logs \
  --permissions r \
  --expiry 2025-12-31 \
  --auth-mode login

3. Clases de rendimiento y niveles de acceso

Para Blob Storage tienes dos ejes de decisión: rendimiento y tier de acceso.

Rendimiento: Estándar (HDD) vs Premium (SSD). Premium para latencias bajas y transacciones altas.
Tier de acceso: Hot, Cool, Archive. Cambia el coste de almacenamiento vs acceso.

Tier	Coste de almacenamiento	Coste de acceso	Uso típico
Hot	Más alto	Bajo	Datos muy accedidos (logs recientes, contenido web).
Cool	Medio	Medio/alto	Datos que se leen ocasionalmente (backups de semanas, informes).
Archive	Muy bajo	Muy alto y acceso con latencia de horas	Retención legal, backups a largo plazo.

4. Inmutabilidad y protección de datos

Este tema está muy ligado a ransomware, por lo que Microsoft lo empuja fuerte en el examen.

Soft delete para blobs y contenedores: permite recuperar objetos borrados.
Versioning: cada cambio genera una nueva versión del blob.
WORM (Immutable Blob Storage): modo de retención legal o basada en tiempo.

Si el requisito dice “impedir que incluso un administrador pueda borrar o modificar datos durante N días” la respuesta es configurar políticas de inmutabilidad (WORM) con bloqueo de la política tras validarla.

5. Files, Blob, Tables y Queues: cuándo usar cada uno

Blob: datos no estructurados, grandes volúmenes (imágenes, backups, logs).
Files: compartidos SMB para lift-and-shift o aplicaciones que esperan un file share clásico.
Tables: NoSQL clave/atributo, consultas simples, alta escalabilidad.
Queues: mensajería simple para desacoplar componentes.

Pregunta típica: “migrar un servidor de ficheros on-premises sin modificar la aplicación” → Azure Files con Azure File Sync.

6. Networking para Storage: firewalls y Private Endpoints

En entornos seguros es habitual restringir Storage a redes internas.

Activar el firewall de Storage para permitir sólo rangos específicos o VNets.
Crear Private Endpoints en las subredes donde están las aplicaciones.
Configurar Private DNS Zones para resolver el FQDN al endpoint privado.

7. Laboratorios y patrones de examen

Laboratorio recomendado

Crea una cuenta StorageV2 con redundancia ZRS y un contenedor datos.
Habilita soft delete y versioning en blobs.
Crea una política de inmutabilidad basada en tiempo para un conjunto de datos críticos.
Configura el firewall para permitir acceso sólo desde una VNet y un private endpoint.

Patrones de examen

Coste vs recuperación: mover datos antiguos a Cool/Archive con lifecycle management.
Seguridad: reemplazar claves compartidas por RBAC y Managed Identities.
Ransomware: combinar soft delete, versioning e inmutabilidad para tener varias capas de protección.