Última revisión: mayo de 2026
Una referencia escaneable de patrones arquitectónicos que evalúa el examen DP-300. Lee de arriba a abajo o salta a una sección.
Una base de datos SQL de misión crítica requiere un SLA del 99,995%, HA con redundancia de zona y capacidades de escalado de lectura.
Implementar Azure SQL Database utilizando el nivel de servicio Business Critical con redundancia de zona habilitada.
Por qué: Business Critical proporciona el SLA más alto, utiliza SSD locales para baja latencia e incluye réplicas secundarias legibles integradas sin costo adicional. General Purpose tiene un SLA inferior y no tiene réplicas de lectura integradas.
Una base de datos tiene patrones de uso impredecibles e intermitentes con largos períodos de inactividad. La optimización de costos es crítica.
Implementar Azure SQL Database utilizando el nivel General Purpose con el modelo de cómputo Serverless.
Por qué: Serverless escala automáticamente el cómputo según la demanda y puede pausarse automáticamente durante la inactividad, cobrando solo por el almacenamiento. Esto es más rentable que el cómputo Provisioned para cargas de trabajo no continuas.
Migrar un SQL Server local que depende en gran medida de características como SQL Server Agent, consultas entre bases de datos y Service Broker.
Migrar a Azure SQL Managed Instance.
Por qué: Managed Instance ofrece casi un 100% de compatibilidad con SQL Server local, conservando características a nivel de instancia no disponibles en Azure SQL Database.
Una aplicación requiere acceso a nivel de sistema operativo, acceso al sistema de archivos (por ejemplo, para Filestream) o características no compatibles con las ofertas de PaaS como CLR con EXTERNAL_ACCESS.
Implementar SQL Server en una máquina virtual de Azure (IaaS).
Por qué: IaaS proporciona control total sobre el sistema operativo y la instancia de SQL Server, ofreciendo máxima compatibilidad con configuraciones locales a costa de un mayor gasto general de administración.
Se espera que una base de datos crezca más allá de 4 TB, hasta 100 TB, y requiere un escalado rápido del almacenamiento y restauraciones rápidas.
Implementar Azure SQL Database utilizando el nivel de servicio Hyperscale.
Por qué: Hyperscale está diseñado para bases de datos muy grandes (VLDBs), ofreciendo hasta 100 TB de almacenamiento que escala automáticamente. Utiliza una arquitectura única con servidores de página para restauraciones de bases de datos rápidas y de tiempo constante, independientemente del tamaño.
Una aplicación SaaS aloja muchas bases de datos pequeñas con patrones de uso variados e impredecibles. Es necesario optimizar los costos proporcionando recursos compartidos.
Agrupar las bases de datos en un grupo elástico de Azure SQL Database.
Por qué: Los grupos elásticos permiten que varias bases de datos compartan un conjunto de recursos (eDTU o vCores) a un precio fijo, lo que es más rentable que aprovisionar bases de datos individuales cuando el uso no es constante en todos los inquilinos.
Implementar una instancia de Azure SQL Managed Instance en una red virtual.
Crear una subred dedicada con un tamaño mínimo de /27 (32 direcciones) y delegarla a Microsoft.Sql/managedInstances.
Por qué: Managed Instance requiere una subred dedicada y vacía con suficientes direcciones IP para sus componentes internos y escalado futuro. Un /27 es el tamaño mínimo admitido.
Migrar una base de datos SQL Server local grande y de misión crítica a Azure con un tiempo de inactividad mínimo.
Usar Azure Database Migration Service (DMS) en modo de migración online.
Por qué: La migración online de DMS realiza una carga inicial y luego utiliza la sincronización continua de datos (envío de registros) para mantener el objetivo sincronizado, lo que permite una ventana de corte muy corta.
Configurar el almacenamiento para un SQL Server en una VM de Azure que aloja una carga de trabajo de almacén de datos con grandes lecturas secuenciales.
Usar SSD Premium. Configurar el almacenamiento en caché de host de solo lectura para archivos de datos y Ninguno para archivos de registro.
Por qué: El almacenamiento en caché de solo lectura es óptimo para las grandes lecturas secuenciales comunes en los almacenes de datos. Los archivos de registro deben tener el almacenamiento en caché deshabilitado para garantizar la durabilidad de la escritura y evitar la pérdida de datos.
Una política de seguridad requiere que todas las conexiones de la base de datos estén cifradas y validen el certificado del servidor.
Establecer la versión mínima de TLS en 1.2 en el servidor. En las cadenas de conexión del cliente, usar `Encrypt=Strict`.
Por qué: Establecer el TLS mínimo en el servidor evita la negociación de protocolos inseguros. `Encrypt=Strict` (TDS 8.0+) fuerza el cifrado y la validación completa del certificado, previniendo ataques de intermediario.
Los datos sensibles en columnas específicas (por ejemplo, SSN) deben cifrarse, pero la aplicación necesita realizar búsquedas de igualdad y uniones en los datos cifrados.
Usar Always Encrypted con cifrado determinista para las columnas buscables.
Por qué: El cifrado determinista genera el mismo texto cifrado para un valor de texto sin formato dado, lo que permite comparaciones de igualdad. El cifrado aleatorio proporciona una protección más fuerte pero no permite estas operaciones.
Se requiere cifrado de datos en reposo, pero la organización debe mantener el control total sobre las claves de cifrado.
Habilitar Transparent Data Encryption (TDE) con claves administradas por el cliente (BYOK) almacenadas en Azure Key Vault.
Por qué: Esta configuración permite a la organización administrar el ciclo de vida de las claves (rotación, revocación) en su propio Key Vault, proporcionando control y cumpliendo los requisitos de cumplimiento para la propiedad de las claves.
Una base de datos de Azure SQL solo debe ser accesible desde una red virtual de Azure específica, con el acceso público a Internet completamente bloqueado.
Configurar un Private Endpoint para el SQL Server y establecer "Denegar acceso a la red pública" en Sí.
Por qué: Un Private Endpoint le da a la base de datos SQL una IP privada dentro de su VNet. Deshabilitar el acceso público asegura que sea la única forma de conectarse, proporcionando un aislamiento de red completo.
Una aplicación multi-inquilino debe asegurar que los usuarios solo puedan ver sus propios datos dentro de una tabla compartida.
Implementar Seguridad a Nivel de Fila (RLS) creando un predicado de seguridad (función con valores de tabla en línea) y una política de seguridad que lo aplique a la tabla.
Por qué: RLS filtra filas de forma transparente según el contexto del usuario (por ejemplo, USER_NAME() o SESSION_CONTEXT), aplicando el aislamiento de datos a nivel del motor de la base de datos sin cambios en la aplicación.
Los administradores de bases de datos necesitan administrar la base de datos pero no deberían poder ver datos sensibles en ciertas columnas.
Implementar Dynamic Data Masking (DDM) en las columnas sensibles. No otorgar el permiso UNMASK a los DBAs.
Por qué: DDM ofusca los datos en los resultados de las consultas para usuarios no privilegiados sin cambiar los datos almacenados. Esto permite a los DBAs realizar sus tareas mientras les impide ver la información sensible real.
Una política de seguridad exige deshabilitar la autenticación SQL para aplicar la administración centralizada de identidades y MFA para una Azure SQL DB o Managed Instance.
Establecer un administrador de Azure AD para el servidor y habilitar la propiedad "Autenticación solo de Azure AD".
Por qué: Esta configuración deshabilita completamente el punto de conexión de autenticación SQL, forzando a todas las conexiones a usar Azure AD. Este es un paso crítico para aplicar políticas de autenticación modernas.
Necesidad de detectar y recibir alertas por actividades anómalas de la base de datos, incluyendo posibles inyecciones SQL, patrones de acceso inusuales y ataques de fuerza bruta.
Habilitar Microsoft Defender for SQL (anteriormente Advanced Threat Protection).
Por qué: Defender for SQL analiza los registros de la base de datos en busca de actividades sospechosas y genera alertas de seguridad, proporcionando una capa crucial de detección de amenazas más allá de los controles de acceso básicos.
Los registros de auditoría de una Azure SQL Database deben conservarse durante varios años y ser consultables para investigaciones de cumplimiento y seguridad.
Configurar la Auditoría de Azure SQL para enviar registros a un espacio de trabajo de Log Analytics con la retención de datos requerida configurada.
Por qué: Log Analytics proporciona retención a largo plazo y potentes capacidades de consulta basadas en KQL, lo que lo hace superior a Blob Storage para datos de auditoría consultables a largo plazo.
Proporcionar acceso temporal, limitado en el tiempo y aprobado a una base de datos para un equipo de DevOps para la resolución de problemas.
Usar Azure AD Privileged Identity Management (PIM) para administrar la elegibilidad de un grupo de Azure AD que tiene acceso a la base de datos.
Por qué: PIM proporciona acceso just-in-time (JIT) que es auditable, requiere justificación y caduca automáticamente, adhiriéndose al principio de mínimo privilegio.
Un sistema requiere un historial verificable y a prueba de manipulaciones de todas las modificaciones de datos para cumplir con estrictas regulaciones de cumplimiento.
Usar la característica de libro mayor (ledger) de Azure SQL Database.
Por qué: Las tablas de libro mayor utilizan conceptos de blockchain para vincular criptográficamente los cambios de datos, creando un historial inmutable que puede verificarse de forma independiente. Esto es más fuerte que las tablas temporales, que no son a prueba de manipulaciones.
Una base de datos está experimentando una degradación del rendimiento. Es necesario identificar las consultas que consumen más recursos, rastrear los cambios de plan y encontrar regresiones de rendimiento.
Habilitar y utilizar Query Store.
Por qué: Query Store es la "caja negra" incorporada para el rendimiento de las consultas. Captura automáticamente el historial de consultas, los planes y las estadísticas de espera, lo que la convierte en la herramienta principal para diagnosticar problemas de rendimiento a lo largo del tiempo.
Una consulta se ejecuta bien a veces pero mal otras veces debido a problemas de parameter sniffing, donde un plan de ejecución se optimiza para un valor de parámetro no representativo.
Usar Query Store para identificar los diferentes planes y forzar el plan de ejecución consistentemente bueno.
Por qué: El forzado de planes en Query Store proporciona una forma rápida y efectiva de estabilizar el rendimiento de consultas problemáticas sin cambios en el código. Anula la elección del optimizador con un plan conocido y bueno.
Mejorar el rendimiento de las consultas sin cambios en el código aprovechando características como el modo por lotes en rowstore, la retroalimentación de la concesión de memoria y la compilación diferida de variables de tabla.
Establecer el nivel de compatibilidad de la base de datos en 150 (para características de SQL 2019) o superior.
Por qué: El conjunto de características de Intelligent Query Processing (IQP) se habilita mediante el nivel de compatibilidad de la base de datos. El nivel 150+ activa una amplia gama de mejoras de rendimiento "sin cambios de código" en el procesador de consultas.
El equipo de operaciones necesita ser notificado cuando las métricas clave de rendimiento, como el porcentaje de CPU o los interbloqueos, superan un umbral definido.
Usar Azure Monitor para crear alertas de métricas (para CPU) y alertas de registro (para interbloqueos) que activen un Grupo de Acciones.
Por qué: Azure Monitor es la plataforma centralizada para monitorear y alertar sobre los recursos de Azure. Los Grupos de Acciones proporcionan canales de notificación flexibles (correo electrónico, SMS, webhook, etc.).
Mejorar el rendimiento de escritura identificando y eliminando índices que no están siendo utilizados por ninguna consulta de lectura.
Consultar la DMV `sys.dm_db_index_usage_stats`.
Por qué: Esta DMV rastrea el uso del índice (búsquedas, exploraciones, búsquedas) frente a las actualizaciones. Los índices con muchas actualizaciones pero cero o muy poco uso son candidatos principales para la eliminación, reduciendo la sobrecarga de mantenimiento.
Necesidad de capturar información detallada sobre problemas de bloqueo intermitentes, incluyendo las sentencias y sesiones involucradas en la cadena de bloqueo.
Configurar una sesión de Extended Events que capture el evento `blocked_process_report`.
Por qué: Este evento proporciona un informe XML detallado de las cadenas de bloqueo cuando se excede el `blocked process threshold`, ofreciendo información de diagnóstico profunda no disponible en las DMVs.
Una base de datos necesita que su estrategia de índices se adapte automáticamente a los patrones de carga de trabajo cambiantes sin intervención manual.
Habilitar la opción CREATE_INDEX en la sintonización automática de Azure SQL Database.
Por qué: Esta característica permite a Azure analizar la carga de trabajo, identificar índices faltantes de alto impacto, crearlos y validar su beneficio de rendimiento, automatizando una tarea clave de DBA.
Descargar cargas de trabajo de informes intensivas en lectura de la base de datos OLTP principal en un nivel Business Critical o Premium.
Modificar las cadenas de conexión de solo lectura de la aplicación para incluir `ApplicationIntent=ReadOnly`.
Por qué: Estos niveles incluyen una réplica secundaria legible gratuita e integrada. La propiedad `ApplicationIntent` en la cadena de conexión enruta automáticamente las conexiones de solo lectura a esta réplica, aislando las cargas de trabajo de lectura.
Una tabla de hechos grande en un almacén de datos se utiliza con frecuencia para consultas de agregación (SUM, COUNT, AVG) que se están ejecutando lentamente.
Crear un índice columnstore agrupado en la tabla de hechos.
Por qué: Los índices columnstore almacenan datos en formato columnar, proporcionando una compresión de datos muy alta y permitiendo la ejecución en modo por lotes, lo que acelera drásticamente las consultas analíticas intensivas en agregación y escaneo.
Una base de datos experimenta una contención de bloqueo significativa entre las consultas de lectura (informes) y las consultas de escritura (transacciones).
Habilitar Read Committed Snapshot Isolation (RCSI) en la base de datos.
Por qué: RCSI utiliza el versionado de filas, permitiendo a los lectores ver la última versión confirmada de los datos sin tomar bloqueos compartidos, eliminando así los bloqueos de los escritores. Los escritores no bloquean a los lectores.
Una aplicación que utiliza una base de datos Serverless experimenta tiempos de conexión iniciales lentos después de un período de inactividad.
Disminuir el retardo de auto-pausa o configurar un valor mínimo de vCore mayor que cero.
Por qué: El retardo es causado por la reanudación de la base de datos desde un estado de pausa (arranque en frío). Establecer un valor mínimo de vCore evita que la base de datos se pause por completo, eliminando la latencia de reanudación a costa de cierta facturación de cómputo continua.
Implementar una pipeline de CI/CD para despliegues de esquemas de bases de datos automatizados, controlados por versiones y repetibles.
Usar un proyecto de base de datos SQL (por ejemplo, en Visual Studio) para generar un archivo DACPAC. Usar pipelines de Azure DevOps para desplegar el DACPAC.
Por qué: Este es el patrón estándar de Infrastructure as Code (IaC) para esquemas SQL. El DACPAC es un modelo declarativo del esquema, y las herramientas de despliegue se encargan de generar el script diferencial, asegurando la consistencia.
Una Azure SQL Database necesita escalarse automáticamente hacia arriba o hacia abajo según un programa o umbrales de métricas (por ejemplo, alta CPU).
Usar un runbook de Azure Automation (PowerShell) activado por un programa o una alerta de Azure Monitor.
Por qué: Azure SQL Database (nivel Provisioned) no tiene escalado automático incorporado. Azure Automation es la herramienta estándar para orquestar este tipo de tarea operativa utilizando scripts y programas.
Un script de mantenimiento (por ejemplo, reconstrucción de índices) necesita ejecutarse en cientos de bases de datos de Azure SQL.
Usar Elastic Jobs.
Por qué: Elastic Jobs es un servicio PaaS diseñado específicamente para ejecutar trabajos T-SQL en un grupo objetivo de bases de datos, gestionando credenciales, programación y registro de forma centralizada.
Asegurarse de que todos los nuevos servidores de Azure SQL creados en una suscripción tengan una característica específica, como TDE o Auditoría, habilitada por defecto.
Crear una Azure Policy con un efecto `DeployIfNotExists` o `Modify`.
Por qué: Azure Policy proporciona gobernanza a escala. El efecto `DeployIfNotExists` configurará automáticamente la configuración faltante durante la creación del recurso, aplicando el cumplimiento sin intervención manual.
Programar un script T-SQL recurrente o una tarea de mantenimiento en una Azure SQL Managed Instance.
Usar el SQL Server Agent incorporado.
Por qué: Managed Instance incluye el SQL Server Agent completo, proporcionando las mismas capacidades familiares de programación de trabajos que en SQL Server local sin necesidad de un servicio de automatización externo.
Controlar cuándo Azure realiza el mantenimiento planificado en una Azure SQL Database o Managed Instance para minimizar el impacto en las operaciones comerciales.
Configurar una Ventana de Mantenimiento para el recurso.
Por qué: Esta característica le permite seleccionar un período de tiempo predefinido (por ejemplo, fines de semana) para que Azure aplique actualizaciones, dándole previsibilidad sobre el mantenimiento que afecta al servicio.
Una aplicación requiere una conmutación por error automática a una región secundaria para la recuperación ante desastres, sin necesidad de cambios en la cadena de conexión.
Configurar un Grupo de Conmutación por Error Automática entre las bases de datos/instancias primarias y secundarias.
Por qué: Los grupos de conmutación por error proporcionan puntos de conexión de escucha de lectura-escritura y de solo lectura. Estos puntos de conexión redirigen automáticamente el tráfico al servidor primario/secundario actual después de una conmutación por error, haciendo que el proceso sea transparente para la aplicación.
Las copias de seguridad de la base de datos deben conservarse durante muchos años (por ejemplo, 7-10 años) para cumplir con los requisitos legales o regulatorios de cumplimiento.
Configurar una política de Retención de Copias de Seguridad a Largo Plazo (LTR).
Por qué: Las copias de seguridad estándar de Point-in-Time Restore (PITR) se mantienen durante un máximo de 35 días. LTR almacena copias de seguridad completas en Azure Blob Storage separadas por hasta 10 años, específicamente para necesidades de cumplimiento.
Una base de datos debe permanecer disponible durante un fallo de centro de datos (Zona de Disponibilidad) dentro de una única región de Azure.
Habilitar la configuración con redundancia de zona para una base de datos de nivel Business Critical o Premium.
Por qué: La redundancia de zona implementa réplicas secundarias síncronas en diferentes centros de datos físicos dentro de la misma región, proporcionando conmutación por error automática con RPO cercano a cero para interrupciones a nivel de zona.
Una Azure SQL Managed Instance requiere una solución de recuperación ante desastres en una región de Azure emparejada con capacidad de conmutación por error automática.
Configurar un Grupo de Conmutación por Error Automática para la Managed Instance.
Por qué: Este es el patrón de DR canónico para Managed Instance, que proporciona replicación asíncrona, puntos de conexión de escucha para una conmutación por error de aplicación transparente y una opción de conmutación por error automatizada.
Necesidad de poder restaurar una base de datos a cualquier segundo específico del mes pasado.
Configurar el período de retención de copias de seguridad a corto plazo (PITR) a 30-35 días.
Por qué: Azure SQL realiza automáticamente copias de seguridad completas, diferenciales y frecuentes del registro de transacciones. La configuración de retención de PITR (1-35 días) determina cuánto tiempo se conservan estas copias de seguridad, definiendo la ventana para las restauraciones a un momento dado.
Configuración de un clúster de conmutación por error de Windows Server para un Grupo de Disponibilidad Always On de SQL Server en VMs de Azure.
Usar un Testigo en la Nube como testigo de quórum.
Por qué: Un Testigo en la Nube utiliza Azure Blob Storage y es la opción más recomendada y resistente para clústeres en Azure. Evita la necesidad de una tercera VM para un testigo de recurso compartido de archivos o configuraciones complejas de discos compartidos.
Implementar una Instancia de Clúster de Conmutación por Error (FCI) de SQL Server en VMs de Azure que requiere almacenamiento compartido.
Usar Discos Compartidos de Azure (adjuntando un disco administrado a múltiples VMs).
Por qué: Los Discos Compartidos de Azure son la solución nativa de Azure para proporcionar almacenamiento de bloques al que pueden acceder varias VMs, lo cual es un requisito previo para una FCI tradicional.
El proceso de recuperación ante desastres para un grupo de conmutación por error necesita ser probado sin afectar la base de datos primaria de producción.
Iniciar una conmutación por error planificada (manual) durante una ventana de mantenimiento de bajo impacto, validar la conectividad de la aplicación y luego revertir la conmutación por error.
Por qué: Una conmutación por error planificada asegura la ausencia de pérdida de datos y es la forma más exhaustiva de validar todo el proceso de DR, incluyendo la propagación de DNS y la reconexión de la aplicación. Es un evento de producción breve y controlado.