Microsoft AZ-305: Almacenamiento de Datos y Soluciones de Bases de Datos — Guía de estudio

By Laurynas Brazys · 11 August 2026 · #microsoft #az-305 #certification #exam-prep #study-guide

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

Descripción general

El diseño del almacenamiento de datos en Azure requiere equilibrar la consistencia, la latencia, la disponibilidad, la complejidad operativa y el costo entre múltiples opciones de bases de datos y almacenamiento. La plataforma abarca bases de datos relacionales totalmente gestionadas, NoSQL distribuidas globalmente, almacenamiento de objetos con gobernanza del ciclo de vida de los datos, lagos de datos analíticos de alto rendimiento y cachés en memoria. Su arquitectura debe partir de las características de la carga de trabajo (workload) —transaccional frente a analítica, alcance global frente a localidad, rigidez del esquema, patrones de lectura/escritura, tamaño y velocidad— y seleccionar el servicio y la configuración que se ajusten a esas restricciones, al tiempo que se cumplen los requisitos de seguridad, resiliencia y gobernanza.

Servicios de datos relacionales en Azure

Azure SQL Database ofrece dos modelos de compra. El modelo DTU combina CPU, memoria y E/S en una unidad mixta a través de los niveles Básico, Estándar y Premium; es simple pero opaco para la planificación de la capacidad. El modelo vCore separa el cómputo, la memoria y el almacenamiento, con opciones de hardware, escalado predecible y palancas de costo como Azure Hybrid Benefit y la capacidad reservada. Bajo el modelo vCore, los principales niveles de servicio son General Purpose (cómputo desacoplado y almacenamiento remoto, costo equilibrado), Business Critical (SSD local con réplicas Always On para E/S de baja latencia y failover rápido) e Hyperscale (arquitectura estructurada en logs con servidores de páginas y almacenamiento distribuido para una escala de múltiples terabytes y operaciones rápidas basadas en instantáneas). El modo Serverless para General Purpose escala automáticamente el cómputo entre un mínimo y un máximo configurados y puede pausarse automáticamente cuando está inactivo; se paga por segundo de cómputo y por almacenamiento. Esto es ideal para cargas de trabajo (workloads) intermitentes o de desarrollo, pero incurre en un arranque en frío (cold-start) y un calentamiento de la caché al reanudarse.

Los pools elásticos (Elastic pools) permiten que múltiples bases de datos compartan un presupuesto de cómputo y un margen de E/S, suavizando los picos y reduciendo el costo para muchas bases de datos pequeñas con cargas variables. Los pools existen en los modelos DTU y vCore; un dimensionamiento correcto exige comprender la concurrencia agregada y los límites de ráfaga (burst) por base de datos para evitar los efectos de “vecino ruidoso” (noisy-neighbor).

Los patrones de resiliencia de Azure SQL incluyen la replicación geográfica activa (active geo-replication) y los grupos de conmutación por error automática (auto-failover groups). La replicación geográfica activa mantiene de forma asíncrona hasta cuatro bases de datos secundarias de lectura en cualquier región de Azure, con un failover iniciado por base de datos. Los grupos de conmutación por error automática gestionan múltiples bases de datos como una unidad a través de servidores lógicos emparejados, proporcionan puntos de conexión de escucha (listener endpoints) de lectura/escritura y de solo lectura, y manejan el failover planificado o no planificado con períodos de gracia configurables, lo que es ideal para SaaS multi-tenant. La redundancia de zona (Zone redundancy) está disponible en los niveles Business Critical (y Hyperscale) para abarcar Zonas de Disponibilidad (Availability Zones) dentro de una región, mejorando la tolerancia a fallos dentro de la región.

Azure SQL Managed Instance (MI) tiene como objetivo una compatibilidad de casi el 100% con SQL Server (SQL Agent, consultas entre bases de datos, Linked Servers, CLR, Service Broker). Se ejecuta dentro de su red virtual en una subred dedicada y delegada (Microsoft.Sql/managedInstances). Las instancias utilizan únicamente IPs privadas; configure los grupos de seguridad de red (network security groups) y las tablas de rutas para permitir el tráfico de gestión hacia los planos de control de Azure y el tráfico de datos hacia sus aplicaciones. Intégrelo con Azure Private DNS (o un DNS personalizado) para que los clientes resuelvan el FQDN privado de la instancia administrada. Para la conectividad híbrida y la migración, asegure la línea de visión (line-of-sight) a través de una VPN de sitio a sitio o ExpressRoute. Las rutas de migración incluyen la copia de seguridad/restauración nativa a Azure Blob Storage (WITH COPY_ONLY, WITH MOVE), migraciones en línea (online) o fuera de línea (offline) utilizando Azure Database Migration Service (DMS), y la replicación transaccional o el trasvase de registros (log shipping) cuando sea apropiado. El nivel Business Critical de MI añade almacenamiento de baja latencia y alta disponibilidad; General Purpose ofrece almacenamiento rentable con discos remotos.

Azure Database for PostgreSQL y MySQL Flexible Server proporcionan un control detallado sobre las ventanas de mantenimiento, la detención/inicio para el ahorro de costos y el aislamiento de red a través de la integración con VNet. Las opciones de alta disponibilidad incluyen un modo de espera (standby) síncrono en la misma zona para el failover más rápido y una alta disponibilidad (HA) con redundancia de zona para resistir fallos zonales (replicación síncrona con failover automático). Las réplicas de lectura (en la misma región y, para muchas versiones, entre regiones) descargan las cargas de trabajo de lectura y soportan análisis casi en tiempo real; son asíncronas y no son adecuadas para lecturas estrictamente consistentes. Seleccione los niveles de cómputo y almacenamiento basándose en los objetivos de IOPS/latencia, y planifique el manejo del failover de la conexión en las bibliotecas cliente.

Almacenes no relacionales y distribuidos globalmente

Azure Cosmos DB es una base de datos globalmente distribuida, multimodelo y totalmente gestionada, con replicación global llave en mano y lecturas y escrituras de milisegundos de un solo dígito en el percentil 99. Elija la API en función del ajuste del ecosistema y el modelo de datos: Core (SQL) API para documentos y consultas tipo SQL con un amplio soporte de SDK; MongoDB API para compatibilidad con el protocolo de cable de Mongo; Cassandra API para cargas de trabajo de columna ancha; Gremlin API para recorridos de grafos; y Table API para escenarios de clave/atributo. El rendimiento (throughput) se aprovisiona en unidades de solicitud (RU), utilizando modos fijos o de autoescalado; diseñe las particiones y la indexación para minimizar el consumo de RU.

La creación de particiones es fundamental. Seleccione una clave de partición de alta cardinalidad que distribuya uniformemente el almacenamiento y el tráfico, evite particiones calientes (hot partitions) y se alinee con sus patrones de acceso (p. ej., tenantId o userId para escrituras multi-inquilino, o una clave compuesta sintética para equilibrar las lecturas). Las particiones lógicas están limitadas en tamaño y rendimiento; modele para mantener distribuidos los conjuntos de trabajo activos (hot working sets). No se puede cambiar la clave de partición de un contenedor después de su creación; las migraciones requieren nuevos contenedores y el movimiento de datos.

La consistencia de Cosmos abarca cinco niveles ajustables: Strong (linealizable, con el mayor costo de RU y latencia), Bounded Staleness (obsolescencia acotada, con un desfase predecible o una ventana de versiones), Session (sesión, centrada en el cliente para leer sus propias escrituras, la opción predeterminada más popular), Consistent Prefix (prefijo consistente, sin lecturas fuera de orden) y Eventual (máxima disponibilidad y rendimiento con posibles anomalías). Elija los valores predeterminados por cuenta y anúlelos por solicitud cuando sea necesario. Las escrituras multirregión habilitan un verdadero maestro-maestro (multi-master) para escrituras globales de baja latencia y mayor disponibilidad; gestione la resolución de conflictos a través de Last-Writer-Wins (sobre una propiedad designada), políticas personalizadas o lógica de aplicación con procedimientos almacenados y el conflict feed.

Al elegir el almacén de datos adecuado, haga coincidir los requisitos con las capacidades. La integridad relacional estricta, las uniones complejas (joins) y las garantías transaccionales favorecen a Azure SQL Database o Managed Instance. La escala global masiva, el esquema flexible y el acceso geográfico de baja latencia favorecen a Cosmos DB. Los problemas de grafos (redes sociales, recomendaciones, topología de red) se asignan a la Gremlin API de Cosmos DB o a las características de grafos en Azure SQL cuando la coubicación relacional es beneficiosa. La telemetría de series temporales de alta ingesta, la exploración ad hoc y la analítica casi en tiempo real se alinean con Azure Data Explorer. Los blobs no estructurados, los medios y las grandes cargas binarias (payloads) pertenecen a Azure Blob Storage o ADLS Gen2, con los metadatos en una base de datos complementaria.

Almacenamiento de objetos y analítico

Azure Blob Storage es la base para los datos no estructurados. Los niveles de acceso alinean el costo de almacenamiento con los patrones de acceso: Hot para acceso frecuente, Cool para acceso poco frecuente con una retención mínima de 30 días, y Archive para almacenamiento en frío a largo plazo con una retención mínima de 180 días y una rehidratación que dura horas. Las cuentas de Premium block blob en SSD ofrecen cargas de trabajo de baja latencia y altas transacciones, como las canalizaciones de ingesta (ingestion pipelines). Las políticas de gestión del ciclo de vida (Lifecycle management) automatizan las transiciones y eliminaciones basadas en reglas —fecha de última modificación, etiquetas de índice de blob o prefijos—, reduciendo el costo sin intervención manual.

La replicación de objetos (Object replication) para block blobs replica de forma asíncrona los objetos y sus versiones entre cuentas de almacenamiento (en la misma región o en regiones diferentes). Requiere el versionado de blobs (blob versioning) en el origen y el destino y se rige por políticas por cada par de contenedores, lo que permite el cumplimiento normativo y la distribución multirregión, manteniendo la independencia de las opciones de redundancia a nivel de cuenta. La inmutabilidad (WORM) se puede aplicar a nivel de contenedor o de blob mediante la retención basada en tiempo y las suspensiones legales (legal holds), con opciones como allowProtectedAppendWrites para registros de solo anexión (append-only). La inmutabilidad a nivel de versión protege los estados pasados contra la manipulación y el ransomware.

Azure Data Lake Storage Gen2 añade un espacio de nombres jerárquico al almacenamiento de Blob, proporcionando directorios verdaderos, renombramientos atómicos y operaciones de archivo optimizadas. Las ACL granulares de tipo POSIX controlan el acceso a nivel de directorio y archivo, con ACL de acceso y predeterminadas (Access and Default ACLs), y se evalúan junto con Azure RBAC. Autentíquese con Azure AD y OAuth2 para aplicar el mínimo privilegio y facilitar la auditabilidad. La integración con la analítica es nativa: Azure Synapse Analytics y Azure Databricks acceden a ADLS Gen2 a través del controlador ABFS con un rendimiento escalable, mientras que servicios como Azure Data Factory, Azure Purview y Azure Machine Learning se integran para la orquestación, la gobernanza y el entrenamiento de modelos. Diseñe estructuras de carpetas y herencia de ACL para aislar dominios y dar soporte a la gobernanza multiequipo, y aproveche características como el change feed y la eliminación temporal (soft delete) para el linaje de datos y la recuperación.

Caché y aceleración del rendimiento

Azure Cache for Redis proporciona acceso a datos en menos de un milisegundo, pub/sub y bloqueo distribuido. Los niveles (tiers) se corresponden con las necesidades de disponibilidad y escala. Basic es de un solo nodo para desarrollo/pruebas. Standard añade una configuración de dos nodos primario/réplica con conmutación por error automática. Premium introduce la agrupación en clústeres a través de particiones (shards), persistencia (instantáneas RDB y AOF), soporte para VNet y georreplicación en una topología activo-pasivo. Enterprise y Enterprise Flash (Redis Enterprise) añaden georreplicación Activo-Activo usando CRDTs para escrituras multirregión, mayores capacidades de memoria, rendimiento multihilo y soporte para módulos; Flash aumenta la DRAM con NVMe para cachés masivas a un costo menor. Elija la política de expulsión (eviction policy) que coincida con el TTL de la clave y la carga de trabajo: allkeys-lru/allkeys-random cuando no todas las claves tienen TTL; volatile-lru/volatile-ttl cuando solo las claves que expiran deben ser expulsadas; y noeviction cuando las fallas de escritura son aceptables en lugar de la expulsión. La persistencia reduce la pérdida de datos en caso de conmutación por error a costa de una sobrecarga de E/S y latencia; actívela solo cuando sea necesario y ajuste los intervalos de las instantáneas.

Integre Redis como una caché de tipo cache-aside para los resultados de consultas de base de datos, el estado de la sesión y los contadores de límite de velocidad (rate-limit). Asegure una población idempotente, aplique TTL adecuados e implemente patrones de interruptor de circuito (circuit breakers). Para cachés en clúster, particione (shard) las claves de forma determinista; para Enterprise Activo-Activo, pruebe la semántica de resolución de conflictos.

Patrones de seguridad, acceso y resiliencia

La delegación de acceso de Azure Storage utiliza tokens y directivas SAS. Una SAS de servicio concede acceso con ámbito a un recurso específico (contenedor, blob, recurso compartido de archivos, cola o tabla). Una SAS de cuenta abarca múltiples servicios en la cuenta y es muy potente; protéjala con cuidado. Una SAS de delegación de usuario (solo para el servicio Blob) se deriva de Azure AD y una clave de delegación de usuario, lo que permite el control de acceso por usuario sin claves de cuenta, ideal para aplicaciones multiinquilino y concesiones de corta duración. Las directivas de acceso almacenadas (en contenedores, recursos compartidos, colas y tablas) vinculan los tokens SAS a una directiva del lado del servidor para que pueda revocar o acortar el acceso sin rotar las claves de la cuenta; una SAS sin una directiva de acceso almacenada solo se puede revocar al expirar el token o al rotar las claves.

Para el cifrado, Azure Storage utiliza el cifrado del lado del servicio por defecto. Las claves administradas por el cliente (CMK) almacenadas en Azure Key Vault o Managed HSM proporcionan un control centralizado del ciclo de vida de las claves y auditabilidad. Los ámbitos de cifrado permiten diferentes CMK dentro de la misma cuenta de almacenamiento por contenedor o prefijo, lo que admite el uso de claves por inquilino. Para el control por blob del lado del cliente, se pueden proporcionar claves proporcionadas por el cliente (CPK) en las solicitudes. Combine CMK a nivel de cuenta o de ámbito con CPK según sea necesario para el aislamiento normativo.

La seguridad y la resiliencia de Azure SQL se basan en los niveles de la plataforma y las características de replicación ya descritas. Utilice grupos de conmutación por error automática para una conmutación por error coordinada entre regiones y puntos de conexión de agente de escucha cautivos, y habilite la redundancia de zona donde esté disponible para resistir fallos zonales. Para datos sensibles, aplique el enmascaramiento dinámico de datos para ofuscar la PII en los resultados de las consultas para usuarios no privilegiados, y considere Always Encrypted con enclaves seguros para la protección del lado del cliente de las columnas cuando se deba impedir que los administradores vean el texto sin formato. Supervise los objetivos de RPO/RTO en función del comportamiento de replicación de su nivel y pruebe la conmutación por error de forma rutinaria.

Al planificar arquitecturas de extremo a extremo, unifique la identidad (Azure AD para SQL, almacenamiento y análisis), aplique el privilegio mínimo con RBAC y ACL, utilice Private Link o la integración con VNet para mantener los datos fuera de la red pública de Internet, e implemente directivas de ciclo de vida, inmutabilidad y replicación para cumplir con los objetivos de retención y DR.

Escenario de problema práctico

Contoso Retail está lanzando una plataforma global de comercio electrónico con tráfico diurno volátil, estrictos controles de PII, medios de productos a escala de petabytes y personalización casi en tiempo real. Requieren lecturas de baja latencia en todo el mundo, tiempo de inactividad mínimo y análisis de datos gobernados.

Colocar las bases de datos transaccionales de catálogo y pedidos en Azure SQL Database utilizando el modelo vCore:

Selección de nivel: Business Critical para los pedidos (almacenamiento de baja latencia y conmutación por error rápida) y General Purpose sin servidor para el catálogo (picos de tráfico con ventanas de inactividad).
Por qué: vCore proporciona un dimensionamiento predecible y Ventaja Híbrida; Business Critical cumple con la latencia/HA para los pedidos; el modelo sin servidor minimiza el costo de cómputo durante la baja actividad.

Configurar un grupo de conmutación por error automática entre regiones emparejadas para ambas bases de datos y habilitar la redundancia de zona:

Por qué: Un agente de escucha de lectura/escritura unificado simplifica la conmutación por error de la aplicación; la redundancia de zona protege contra interrupciones zonales; las réplicas entre regiones cumplen con los objetivos de DR y ofrecen escalado de lectura para la generación de informes.

Almacenar imágenes y videos de productos en Azure Blob Storage (general-purpose v2) con administración del ciclo de vida y replicación de objetos:

Directiva: Nivel de acceso frecuente (Hot) para elementos activos, esporádico (Cool) después de 30 días, de archivo (Archive) después de 180 días; replicar a una región secundaria mediante la replicación de objetos.
Por qué: Minimiza el costo de almacenamiento a lo largo del tiempo mientras proporciona una distribución regional asíncrona independiente de la redundancia de la cuenta; cumple con la retención con inmutabilidad para activos legales (WORM basado en tiempo).

Construir el servicio de perfiles de cliente y carrito de compras en Azure Cosmos DB (Core API) con escrituras multirregión y consistencia de sesión (Session):

Diseño: Particionar por userId para distribuir las escrituras; habilitar el escalado automático de RU.
Por qué: El modo multimaestro proporciona escrituras de baja latencia para una audiencia global y alta disponibilidad; la consistencia de sesión (Session) garantiza la lectura de las propias escrituras por usuario con fuertes garantías de UX y un uso eficiente de las RU.

Introducir Azure Cache for Redis Enterprise para el estado de sesión, el almacenamiento en caché de detalles de productos y la limitación de velocidad:

Modo: Clúster con georreplicación activa-activa para escrituras multirregión.
Por qué: El acceso de submilisegundos y la resolución de conflictos basada en CRDT mantienen las sesiones y los contadores consistentes entre regiones sin un único maestro de escritura.

Depositar los registros de secuencias de clics y operativos en Azure Data Lake Storage Gen2 con espacios de nombres jerárquicos y ACL de POSIX:

Integración: La ingesta de flujos de datos escribe en carpetas seleccionadas; Databricks y Synapse leen a través de ABFS; habilitar la fuente de cambios y la eliminación temporal (soft delete).
Por qué: Las ACL detalladas a nivel de directorio/archivo admiten la gobernanza entre múltiples equipos; el espacio de nombres jerárquico optimiza las operaciones de archivos; la integración nativa con herramientas de análisis acorta el tiempo para obtener información.

Usar Azure Database for PostgreSQL Flexible Server para el microservicio de recomendaciones:

HA: Servidor en espera síncrono con redundancia de zona; aprovisionar réplicas de lectura para la experimentación de características.
Por qué: El rico ecosistema de extensiones de Postgres y las capacidades de JSONB se ajustan al servicio; la HA administrada mantiene el RTO bajo; las réplicas descargan las lecturas.

Asegurar el acceso con SAS de delegación de usuario para la carga temporal de medios y CMK con ámbitos de cifrado por inquilino:

Por qué: Elimina la exposición de las claves de la cuenta y permite el aislamiento criptográfico y la auditabilidad por inquilino.

Migrar datos de pedidos heredados de SQL Server local a Azure SQL Managed Instance para el procesamiento de archivos y tareas impulsadas por el agente:

Pasos: Evaluar con Data Migration Assistant; realizar la migración en línea a través de DMS; conectar a través de ExpressRoute.
Por qué: MI preserva los trabajos del Agente SQL y las operaciones entre bases de datos, facilitando la modernización mientras mantiene las cargas de trabajo de archivo cerca de los datos en la nube.

Este diseño cumple con el rendimiento global a través de las escrituras multirregión de Cosmos DB y Redis Enterprise, impone la gobernanza con las ACL de ADLS Gen2 y la inmutabilidad de Storage, ofrece integridad transaccional y conmutación por error rápida con los niveles de Azure SQL y los grupos de conmutación por error automática, y optimiza los costos a través del cómputo sin servidor y las directivas de ciclo de vida.

← Identidad · Todos los dominios · Cómputo y Arquitectura de Aplicaciones →

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