Microsoft AZ-204: Azure Storage y Blob Storage — Guía de estudio

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

Forma parte de la Microsoft Azure Developer Associate AZ-204 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Microsoft, o realiza tests cronometrados en ExamRoll.io.

Información general

Azure Storage proporciona almacenamiento en la nube duradero y masivamente escalable para datos no estructurados y estructurados. Para el desarrollo de aplicaciones, céntrese en seleccionar el tipo de cuenta de almacenamiento correcto, configurar la redundancia para cumplir los objetivos de RTO/RPO, elegir el tipo de blob y el nivel de acceso adecuados para el costo/rendimiento, y asegurar el acceso con Azure AD y SAS. Utilice políticas de ciclo de vida para automatizar el movimiento de datos entre niveles, servir sitios web estáticos directamente desde Blob storage cuando sea apropiado, y aplicar Azure Files y Queue Storage donde se requiera semántica de archivos o desacoplamiento basado en mensajes.

Fundamentos de los tipos de cuentas de almacenamiento y la redundancia

De uso general v2 (GPv2) es el tipo de cuenta estándar para la mayoría de las cargas de trabajo. Admite blobs, archivos, colas y tablas, todos los niveles de acceso, la administración del ciclo de vida y las características más recientes. Las cuentas heredadas de BlobStorage exponen solo el servicio Blob y la organización en niveles (tiering), pero carecen de la amplitud de características y optimizaciones de costos que se encuentran en GPv2; las nuevas implementaciones deberían preferir GPv2. Las cuentas FileStorage son cuentas premium, respaldadas por SSD, dedicadas a Azure Files, que ofrecen IOPS y rendimiento consistentes y de baja latencia para cargas de trabajo de archivos empresariales (p. ej., recursos compartidos de perfiles, aplicaciones de línea de negocio). Elija FileStorage cuando requiera un rendimiento premium para recursos compartidos SMB/NFS; de lo contrario, GPv2 es la opción predeterminada.

Las opciones de redundancia determinan la durabilidad y disponibilidad de los datos a través de los dominios de error:

• LRS (Almacenamiento con redundancia local) almacena sincrónicamente tres copias dentro de un único centro de datos. Es el costo más bajo, sin protección de zona o regional. Úselo para desarrollo/pruebas, cargas de trabajo efímeras o cuando tenga replicación en una capa superior.
• ZRS (Almacenamiento con redundancia de zona) replica sincrónicamente a través de zonas de disponibilidad en una región, protegiendo de una interrupción zonal con alta disponibilidad y sin RPO. Elija esta opción para producción en regiones con zonas que requieran resiliencia dentro de la región.
• GRS (Almacenamiento con redundancia geográfica) almacena tres copias sincrónicas en la región primaria (como LRS) y replica asincrónicamente a una región secundaria emparejada (con LRS allí). El RPO típico es inferior a 15 minutos; la secundaria no es legible por defecto. Selecciónelo para recuperación ante desastres cuando no necesite acceso de lectura.
• RA-GRS (Almacenamiento con redundancia geográfica y acceso de lectura) añade acceso de lectura a la secundaria a través de endpoints -secondary. Úselo cuando requiera tolerancia a desastres entre regiones y cargas de trabajo mayoritariamente de lectura durante incidentes en la primaria, o para lecturas por proximidad geográfica donde la consistencia eventual es aceptable.

Cuando necesite tanto protección contra fallos de zona como DR entre regiones, considere combinar ZRS localmente con un patrón de cuenta adicional con replicación geográfica a nivel de la solución. Planifique pruebas de conmutación por error de la cuenta, comprenda los cambios de endpoints de DNS y valide las políticas de reintento de la aplicación para manejar la consistencia eventual y el desfase de reloj (clock skew) durante eventos geográficos.

Modelo de datos de blobs, niveles y administración del ciclo de vida

Los blobs vienen en tres tipos con semánticas distintas. Los blobs en bloques están optimizados para la transmisión (streaming) y la lectura aleatoria de objetos grandes como imágenes, videos y copias de seguridad. Las cargas se dividen en bloques y se confirman, lo que permite cargas paralelas y reintentos eficientes. Los blobs en anexos están optimizados para cargas de trabajo de solo anexo, como la telemetría y la captura de registros; solo se permiten operaciones de anexo, lo que simplifica la concurrencia. Los blobs en páginas exponen páginas alineadas de 512 bytes para E/S de lectura/escritura aleatoria y respaldan los discos duros virtuales de Azure (VHDs) utilizados por los discos de VM de Azure; son el único tipo de blob admitido para discos IaaS y grandes cargas de trabajo de E/S aleatoria.

Los niveles de acceso a blobs controlan el costo y el rendimiento. El nivel frecuente (Hot) está optimizado para acceso frecuente con la latencia de lectura/escritura más baja y el costo de almacenamiento más alto. El nivel esporádico (Cool) se dirige a datos a los que se accede con poca frecuencia y que se retienen durante al menos 30 días, con un costo de almacenamiento más bajo pero costos de transacción/lectura más altos y cargos por retención mínima. El nivel de archivo (Archive) es el de menor costo para la retención a largo plazo; los objetos están sin conexión (offline) y deben ser rehidratados a un nivel frecuente o esporádico antes de poder leerlos. La rehidratación se puede solicitar con prioridad estándar o alta, intercambiando costo por velocidad. Puede establecer un nivel de acceso predeterminado a nivel de cuenta (frecuente o esporádico) y anularlo por blob; el nivel de archivo es solo por blob.

Las políticas de administración del ciclo de vida automatizan el movimiento y la retención de datos para controlar los costos y cumplir con la gobernanza. A nivel de cuenta, defina reglas que:

• Hagan la transición de blobs o versiones/instantáneas de blobs a un nivel esporádico o de archivo después de N días desde la última modificación
• Eliminen blobs, instantáneas o versiones después de umbrales de antigüedad
• Filtren por prefijo de contenedor y por etiquetas de índice de blob para dirigirse a conjuntos de datos específicos (por ejemplo, etiqueta env=prod y policy=retention-7y) Combine las reglas del ciclo de vida con el control de versiones y la eliminación temporal (soft delete) para protegerse contra eliminaciones accidentales sin dejar de aplicar la retención. Recuerde que el nivel de archivo tiene cargos por retención mínima y eliminación anticipada; diseñe políticas para minimizar las rehidrataciones innecesarias.

Para el seguimiento de cambios y el procesamiento posterior, habilite la fuente de cambios (change feed) de la cuenta de almacenamiento para consumir un registro ordenado e inmutable de las operaciones de creación, actualización, eliminación y copia de blobs. Esto da soporte al cumplimiento normativo y a los procesadores asíncronos que necesitan semántica de tipo “exactamente una vez” (exactly-once) o “al menos una vez” (at-least-once) con puntos de control (checkpointing).

El alojamiento de sitios web estáticos en Blob storage expone un contenedor especial $web que se sirve a través de un endpoint web dedicado. Configure los documentos de índice y de error y publique los activos estáticos directamente. El endpoint del sitio web estático proporciona acceso de lectura anónimo al contenido del sitio, independientemente de la configuración de acceso público del blob; el acceso a través del endpoint del blob puede permanecer deshabilitado. Para dominios personalizados y aceleración global, coloque Azure Front Door o Azure CDN delante del endpoint. Los private endpoints no son compatibles con el endpoint del sitio web estático; utilice un servicio perimetral (edge service) para asegurar y acelerar la entrega donde se requiera acceso privado.

Seguridad, identidad y acceso controlado a los datos

Azure Storage cifra los datos en reposo por defecto con AES de 256 bits utilizando claves administradas por Microsoft. Para un control más estricto, habilite las claves administradas por el cliente (CMK) almacenadas en Azure Key Vault o Managed HSM para gobernar la rotación de claves y la separación de funciones; conceda a la identidad administrada de la cuenta de almacenamiento los permisos de wrap/unwrap. Para cargas de trabajo altamente reguladas, habilite el cifrado de infraestructura para aplicar una segunda capa de cifrado independiente. Combine el cifrado del lado del servidor con el cifrado del lado del cliente si se requiere un control criptográfico de extremo a extremo.

La autorización de Azure AD integra el plano de datos con RBAC para los servicios Blob y Queue y para la API REST de Files. Conceda roles de privilegio mínimo como Storage Blob Data Reader o Storage Blob Data Contributor a identidades administradas, usuarios o grupos. En el código, utilice DefaultAzureCredential para adquirir tokens OAuth 2.0 y evite incrustar claves. Para el acceso SMB a Azure Files, habilite la autenticación basada en identidad utilizando Active Directory: una la cuenta de almacenamiento a un AD DS local (a través de Azure AD Kerberos para identidades híbridas) o a Azure AD DS, y utilice ACL de NTFS y RBAC (p. ej., Storage File Data SMB Share Contributor) para la autorización a nivel de recurso compartido. Asegúrese de usar SMB 3.x con cifrado en tránsito y considere Private Endpoints, VPN o ExpressRoute para atravesar redes que bloquean el puerto 445.

Las Firmas de Acceso Compartido (SAS) delegan un acceso acotado y con límite de tiempo sin exponer las claves de la cuenta. Una SAS de servicio concede acceso a un servicio y recurso específico (p. ej., un único blob o contenedor) con permisos precisos y tiempos de inicio/expiración. Una SAS de cuenta opera a nivel de cuenta, abarcando múltiples servicios (blobs, archivos, colas, tablas) y API de servicio como listar o crear. Una SAS de delegación de usuario es específica para Blob storage y se firma con una clave de delegación de usuario obtenida a través de Azure AD para una entidad de seguridad con el RBAC apropiado; elimina la dependencia de claves y centraliza el control de acceso en Azure AD. Aplique restricciones que incluyan rangos de IP, protocolos permitidos (solo HTTPS) y duraciones cortas. Las políticas de acceso almacenadas centralizan las restricciones de las SAS y permiten la revocación actualizando o eliminando la política; se aplican a las SAS de servicio y a las SAS de cuenta. Las SAS de delegación de usuario no utilizan políticas de acceso almacenadas; revoque expirando la clave de delegación de usuario o eliminando las asignaciones de roles de Azure AD. Prefiera siempre las SAS sobre las claves de cuenta, y prefiera las SAS de delegación de usuario cuando su aplicación pueda adquirir tokens de Azure AD.

Conceptos esenciales de Azure Files y Queue Storage

Azure Files proporciona recursos compartidos SMB totalmente administrados y una opción NFS para escenarios POSIX. Utilice recursos compartidos SMB para migraciones lift-and-shift y compatibilidad de aplicaciones. Las cuentas Premium FileStorage ofrecen un rendimiento predecible de baja latencia, mientras que los recursos compartidos estándar son económicos para datos de archivos de propósito general. Administre los recursos compartidos y los archivos a través de clientes SMB o la API REST/SDK. Azure File Sync habilita servicios de archivos híbridos al almacenar en caché un recurso compartido en la nube en Windows Server, lo que proporciona rendimiento local y mueve los datos fríos a la nube por niveles (tiering), sincronización multisitio y copias de seguridad/recuperación ante desastres externa sin los ciclos de actualización de NAS tradicionales. Combine la identidad basada en Azure AD con las ACL de NTFS para aplicar el principio de privilegio mínimo y utilice Private Endpoints para contener el riesgo de exfiltración de datos.

Azure Queue Storage permite flujos de trabajo de aplicaciones desacoplados y resilientes. Cada mensaje puede tener hasta 64 KB (las cargas útiles más grandes deben hacer referencia a URI de blobs). El tiempo de vida (time-to-live o TTL) del mensaje determina su vencimiento automático; especifique un valor positivo desde segundos hasta siete días, o -1 para que no venza. Cuando un trabajador recupera un mensaje, este se vuelve invisible durante su tiempo de espera de visibilidad (visibility timeout). Si el procesamiento falla y el mensaje no se elimina antes de que expire el tiempo de espera, vuelve a aparecer para otro consumidor. Ajuste el tiempo de espera de visibilidad para que exceda el peor de los casos de tiempo de procesamiento y utilice manejadores idempotentes junto con un retroceso exponencial (exponential backoff) para reducir la contención. Realice un seguimiento del recuento de retiradas de la cola (dequeue count) para detectar mensajes dudosos (poison messages); cuando exceda un umbral, mueva el mensaje a una cola de mensajes dudosos dedicada para ponerlo en cuarentena y analizarlo. Los desencadenadores de cola de Azure Functions implementan este patrón automáticamente con una cola -poison. Para necesidades de mayor rendimiento o FIFO con garantías de orden, considere las colas de Service Bus; de lo contrario, Azure Queue Storage es una opción ligera y rentable.

Escenario de un problema práctico

National Geographic debe publicar un micrositio de fotografía de alto tráfico con procesamiento de imágenes sin servidor (serverless), almacenamiento optimizado en costos y acceso híbrido para una herramienta editorial local (on-premises). También requieren enlaces seguros para compartir por tiempo limitado para agencias asociadas y un manejo robusto de mensajes para el procesamiento en segundo plano.

1. Crear una cuenta de almacenamiento GPv2 con RA-GRS

• Por qué: GPv2 desbloquea los servicios de Blob, Files y Queue con características de ciclo de vida y organización por niveles (tiering). RA-GRS proporciona tolerancia a desastres entre regiones y acceso de lectura a puntos de conexión secundarios para la continuidad de los activos de lectura mayoritaria durante incidentes regionales.

2. Habilitar el alojamiento de sitios web estáticos y desplegar los activos del sitio en el contenedor $web

• Por qué: Los sitios web estáticos de Blob eliminan la gestión de servidores web, ofrecen lecturas de baja latencia desde el nivel de acceso frecuente (Hot tier) y escalan globalmente. Combínelo más tarde con Azure Front Door para dominios personalizados, WAF y almacenamiento en caché en el borde (edge caching).

3. Almacenar imágenes RAW originales como blobs en bloques; telemetría de escritura única como blobs en anexos

• Por qué: Los blobs en bloques admiten cargas grandes y paralelas y una entrega eficiente de derivados optimizados para la web. Los blobs en anexos simplifican las escrituras de registros simultáneas desde las canalizaciones de procesamiento sin conflictos.

4. Definir políticas de ciclo de vida para mover los originales a Cool después de 30 días y a Archive después de 180 días; eliminar versiones con más de un año de antigüedad

• Por qué: La organización por niveles automatizada reduce el costo de almacenamiento según los patrones de acceso, al tiempo que conserva las copias para cumplimiento normativo. La limpieza de versiones e instantáneas controla el crecimiento desmedido sin intervención manual.

5. Asegurar el acceso a los datos con Azure AD y SAS de delegación de usuario para los socios

• Por qué: Asigne el rol Lector de datos de Storage Blob (Storage Blob Data Reader) a una identidad administrada en el servicio de uso compartido, obtenga claves de delegación de usuario y genere tokens SAS de corta duración, solo para HTTPS y con restricciones de IP. Esto evita la distribución de claves de cuenta y vincula la autorización a Azure AD.

6. Habilitar claves administradas por el cliente (CMK) con Key Vault y cifrado de infraestructura

• Por qué: CMK satisface requisitos más estrictos de cumplimiento y rotación, mientras que el doble cifrado proporciona defensa en profundidad para los medios confidenciales.

7. Integrar Azure Queue Storage para el procesamiento de imágenes en segundo plano con un desencadenador de cola de Azure Functions; establecer el tiempo de espera de visibilidad para que exceda el tiempo máximo de procesamiento y configurar el manejo de mensajes dudosos

• Por qué: Las colas desacoplan la ruta de carga del cómputo. El tiempo de espera de visibilidad evita el trabajo duplicado, y el tiempo de ejecución de Functions enruta automáticamente los elementos fallidos a una cola -poison para su investigación.

8. Publicar herramientas editoriales a través de Azure Files utilizando una cuenta Premium FileStorage y Azure File Sync en un Windows Server local

• Por qué: Los editores obtienen acceso SMB de baja latencia con ACL de NTFS y autenticación basada en identidad a través de AD, mientras que Azure File Sync proporciona almacenamiento en caché local y organización por niveles en la nube. El nivel prémium garantiza un rendimiento constante para las cargas de trabajo interactivas.

9. Poner el sitio web estático detrás de Azure Front Door y habilitar el almacenamiento en caché y HTTPS personalizado

• Por qué: Los POP de borde reducen la latencia a nivel mundial, los dominios personalizados cumplen con los requisitos de marca y el WAF agrega seguridad sin cambiar el backend de almacenamiento.

10. Habilitar la fuente de cambios (change feed) de la cuenta de almacenamiento y archivarla en un almacén de cumplimiento

• Por qué: Un registro inmutable y ordenado de los cambios en los blobs permite análisis posteriores, auditorías y reproducción para canalizaciones de contenido reproducibles.

← Azure Functions y Computación sin servidor · Todos los dominios · Azure Cosmos DB →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →

Explorar Microsoft →