Última revisão: maio de 2026
Uma referência rápida dos padrões arquiteturais que o exame DP-300 avalia. Leia de cima a baixo ou pule para uma seção.
Um banco de dados SQL de missão crítica requer 99,995% de SLA, HA com redundância de zona e capacidades de scale-out para leitura.
Implantar o Azure SQL Database usando o nível de serviço Business Critical com redundância de zona habilitada.
Por quê: Business Critical oferece o SLA mais alto, usa SSDs locais para baixa latência e inclui réplicas secundárias legíveis integradas sem custo adicional. General Purpose tem um SLA inferior e não possui réplicas de leitura integradas.
Um banco de dados possui padrões de uso imprevisíveis e intermitentes com longos períodos de inatividade. A otimização de custos é fundamental.
Implantar o Azure SQL Database usando o nível General Purpose com o modelo de computação Serverless.
Por quê: Serverless escala automaticamente a computação com base na demanda e pode pausar automaticamente durante a inatividade, cobrando apenas pelo armazenamento. Isso é mais econômico do que a computação Provisioned para cargas de trabalho não contínuas.
Migrando um SQL Server local que depende fortemente de recursos como SQL Server Agent, consultas entre bancos de dados e Service Broker.
Migrar para o Azure SQL Managed Instance.
Por quê: Managed Instance oferece quase 100% de compatibilidade com o SQL Server local, preservando recursos de nível de instância não disponíveis no Azure SQL Database.
Um aplicativo requer acesso em nível de sistema operacional, acesso ao sistema de arquivos (por exemplo, para Filestream) ou recursos não suportados por ofertas PaaS como CLR com EXTERNAL_ACCESS.
Implantar o SQL Server em uma Máquina Virtual do Azure (IaaS).
Por quê: IaaS oferece controle total sobre o sistema operacional e a instância do SQL Server, proporcionando máxima compatibilidade com as configurações locais, ao custo de um aumento na sobrecarga de gerenciamento.
Espera-se que um banco de dados cresça além de 4 TB, até 100 TB, e requeira escalonamento rápido de armazenamento e restaurações rápidas.
Implantar o Azure SQL Database usando o nível de serviço Hyperscale.
Por quê: Hyperscale é projetado para Bancos de Dados Muito Grandes (VLDBs), oferecendo até 100 TB de armazenamento que escala automaticamente. Ele usa uma arquitetura única com servidores de página para restaurações de banco de dados rápidas e em tempo constante, independentemente do tamanho.
Um aplicativo SaaS hospeda muitos bancos de dados pequenos com padrões de uso variados e imprevisíveis. É necessário otimizar custos enquanto se fornece recursos compartilhados.
Agrupar os bancos de dados em um pool elástico do Azure SQL Database.
Por quê: Pools elásticos permitem que vários bancos de dados compartilhem um conjunto de recursos (eDTUs ou vCores) a um preço fixo, o que é mais econômico do que provisionar bancos de dados individuais quando o uso não é constante entre todos os inquilinos.
Implantando um Azure SQL Managed Instance em uma rede virtual.
Criar uma sub-rede dedicada com um tamanho mínimo de /27 (32 endereços) e delegá-la a Microsoft.Sql/managedInstances.
Por quê: Managed Instance requer uma sub-rede dedicada e vazia com endereços IP suficientes para seus componentes internos e escalonamento futuro. Um /27 é o tamanho mínimo suportado.
Migrando um banco de dados SQL Server local grande e de missão crítica para o Azure com tempo de inatividade mínimo.
Usar o Azure Database Migration Service (DMS) no modo de migração online.
Por quê: A migração online do DMS realiza uma carga inicial e, em seguida, usa a sincronização contínua de dados (log shipping) para manter o destino sincronizado, permitindo uma janela de cutover muito curta.
Configurando o armazenamento para um SQL Server em VM do Azure que hospeda uma carga de trabalho de data warehouse com grandes leituras sequenciais.
Usar Premium SSDs. Configurar cache de host somente leitura para arquivos de dados e Nenhum para arquivos de log.
Por quê: O cache somente leitura é ideal para as grandes leituras sequenciais comuns em data warehouses. Os arquivos de log devem ter o cache desativado para garantir a durabilidade da gravação e evitar a perda de dados.
Uma política de segurança exige que todas as conexões de banco de dados sejam criptografadas e que o certificado do servidor seja validado.
Definir a versão mínima de TLS para 1.2 no servidor. Nas strings de conexão do cliente, usar `Encrypt=Strict`.
Por quê: Definir o TLS mínimo no servidor impede a negociação de protocolo inseguro. `Encrypt=Strict` (TDS 8.0+) impõe a criptografia e a validação completa do certificado, prevenindo ataques man-in-the-middle.
Dados sensíveis em colunas específicas (por exemplo, SSN) devem ser criptografados, mas o aplicativo precisa realizar pesquisas de igualdade e junções nos dados criptografados.
Usar Always Encrypted com criptografia determinística para as colunas pesquisáveis.
Por quê: A criptografia determinística gera o mesmo texto cifrado para um determinado valor de texto simples, permitindo comparações de igualdade. A criptografia randomizada oferece proteção mais forte, mas não permite essas operações.
É necessária a criptografia de dados em repouso, mas a organização deve manter controle total sobre as chaves de criptografia.
Habilitar Transparent Data Encryption (TDE) com chaves gerenciadas pelo cliente (BYOK) armazenadas no Azure Key Vault.
Por quê: Esta configuração permite à organização gerenciar o ciclo de vida da chave (rotação, revogação) em seu próprio Key Vault, fornecendo controle e atendendo aos requisitos de conformidade para a propriedade da chave.
Um Azure SQL Database deve ser acessível apenas a partir de uma Rede Virtual do Azure específica, com o acesso público à internet completamente bloqueado.
Configurar um Private Endpoint para o SQL Server e definir "Deny public network access" como Sim.
Por quê: Um Private Endpoint atribui ao banco de dados SQL um IP privado dentro da sua VNet. Desabilitar o acesso público garante que esta seja a única forma de conexão, proporcionando isolamento completo da rede.
Um aplicativo multi-tenant deve garantir que os usuários possam ver apenas seus próprios dados dentro de uma tabela compartilhada.
Implementar Row-Level Security (RLS) criando um predicado de segurança (função com valor de tabela inline) e uma política de segurança que o aplica à tabela.
Por quê: RLS filtra transparentemente as linhas com base no contexto do usuário (por exemplo, USER_NAME() ou SESSION_CONTEXT), aplicando o isolamento de dados no nível do mecanismo de banco de dados sem alterações no aplicativo.
Administradores de banco de dados precisam gerenciar o banco de dados, mas não devem ser capazes de visualizar dados sensíveis em certas colunas.
Implementar Dynamic Data Masking (DDM) nas colunas sensíveis. Não conceder a permissão UNMASK aos DBAs.
Por quê: DDM ofusca dados em resultados de consulta para usuários não privilegiados sem alterar os dados armazenados. Isso permite que os DBAs realizem suas tarefas enquanto os impede de ver as informações sensíveis reais.
Uma política de segurança exige a desativação da autenticação SQL para impor o gerenciamento centralizado de identidade e MFA para um Azure SQL DB ou Managed Instance.
Definir um administrador do Azure AD para o servidor e habilitar a propriedade "Azure AD-only authentication".
Por quê: Esta configuração desativa completamente o endpoint de autenticação SQL, forçando todas as conexões a usar o Azure AD. Este é um passo crítico para impor políticas de autenticação modernas.
É necessário detectar e receber alertas para atividades anômalas de banco de dados, incluindo possíveis injeções de SQL, padrões de acesso incomuns e ataques de força bruta.
Habilitar o Microsoft Defender for SQL (anteriormente Advanced Threat Protection).
Por quê: O Defender for SQL analisa os logs do banco de dados em busca de atividades suspeitas e gera alertas de segurança, fornecendo uma camada crucial de detecção de ameaças além dos controles de acesso básicos.
Os logs de auditoria para um Azure SQL Database devem ser retidos por vários anos e ser pesquisáveis para investigações de conformidade e segurança.
Configurar a Auditoria do Azure SQL para enviar logs para um workspace do Log Analytics com a retenção de dados necessária configurada.
Por quê: O Log Analytics oferece retenção de longo prazo e poderosas capacidades de consulta baseadas em KQL, tornando-o superior ao Blob Storage para dados de auditoria pesquisáveis e de longo prazo.
Fornecer acesso temporário, limitado no tempo e com aprovação a um banco de dados para uma equipe de DevOps para solução de problemas.
Usar o Azure AD Privileged Identity Management (PIM) para gerenciar a elegibilidade para um grupo do Azure AD que tenha acesso ao banco de dados.
Por quê: O PIM fornece acesso just-in-time (JIT) que é auditável, requer justificativa e expira automaticamente, aderindo ao princípio do menor privilégio.
Um sistema requer um histórico verificável e à prova de adulteração de todas as modificações de dados para atender a rigorosas conformidades regulatórias.
Usar o recurso de ledger do Azure SQL Database.
Por quê: As tabelas de ledger usam conceitos de blockchain para vincular criptograficamente as alterações de dados, criando um histórico imutável que pode ser verificado de forma independente. Isso é mais forte do que as tabelas temporais, que não são à prova de adulteração.
Um banco de dados está enfrentando degradação de desempenho. É necessário identificar as consultas que mais consomem recursos, rastrear alterações de plano e encontrar regressões de desempenho.
Habilitar e utilizar o Query Store.
Por quê: O Query Store é o "gravador de dados de voo" integrado para o desempenho de consultas. Ele captura automaticamente o histórico de consultas, planos e estatísticas de espera, tornando-se a ferramenta principal para diagnosticar problemas de desempenho ao longo do tempo.
Uma consulta funciona bem às vezes, mas mal em outras, devido a problemas de parameter sniffing, onde um plano de execução é otimizado para um valor de parâmetro não representativo.
Usar o Query Store para identificar os diferentes planos e forçar o plano de execução consistentemente bom.
Por quê: A imposição de plano no Query Store oferece uma maneira rápida e eficaz de estabilizar o desempenho de consultas problemáticas sem alterações de código. Ela substitui a escolha do otimizador por um plano comprovadamente bom.
Para melhorar o desempenho de consultas sem alterações de código, aproveitando recursos como o modo de lote em rowstore, feedback de concessão de memória e compilação adiada de variáveis de tabela.
Definir o nível de compatibilidade do banco de dados para 150 (para recursos do SQL 2019) ou superior.
Por quê: O conjunto de recursos Intelligent Query Processing (IQP) é habilitado pelo nível de compatibilidade do banco de dados. O nível 150+ ativa uma ampla gama de aprimoramentos de desempenho "sem alteração de código" no processador de consultas.
A equipe de operações precisa ser notificada quando métricas chave de desempenho, como percentual de CPU ou deadlocks, excederem um limite definido.
Usar o Azure Monitor para criar alertas de métrica (para CPU) e alertas de log (para deadlocks) que acionam um Grupo de Ação.
Por quê: O Azure Monitor é a plataforma centralizada para monitoramento e alertas em recursos do Azure. Os Grupos de Ação fornecem canais de notificação flexíveis (e-mail, SMS, webhook, etc.).
Melhorar o desempenho de gravação identificando e removendo índices que não estão sendo usados por nenhuma consulta de leitura.
Consultar a DMV `sys.dm_db_index_usage_stats`.
Por quê: Esta DMV rastreia o uso do índice (buscas, varreduras, lookups) versus atualizações. Índices com muitas atualizações, mas uso zero ou muito baixo, são os principais candidatos à remoção, reduzindo a sobrecarga de manutenção.
É necessário capturar informações detalhadas sobre problemas de bloqueio intermitentes, incluindo as instruções e sessões envolvidas na cadeia de bloqueio.
Configurar uma sessão de Extended Events que capture o evento `blocked_process_report`.
Por quê: Este evento fornece um relatório XML detalhado das cadeias de bloqueio quando o `blocked process threshold` é excedido, oferecendo informações diagnósticas profundas não disponíveis em DMVs.
Um banco de dados precisa que sua estratégia de índice se adapte automaticamente a padrões de carga de trabalho em mudança sem intervenção manual.
Habilitar a opção CREATE_INDEX no ajuste automático do Azure SQL Database.
Por quê: Este recurso permite que o Azure analise a carga de trabalho, identifique índices ausentes com alto impacto, os crie e valide seu benefício de desempenho, automatizando uma tarefa chave do DBA.
Descarregar cargas de trabalho de relatório intensivas em leitura do banco de dados OLTP primário em um nível Business Critical ou Premium.
Modificar as strings de conexão somente leitura do aplicativo para incluir `ApplicationIntent=ReadOnly`.
Por quê: Esses níveis incluem uma réplica secundária legível gratuita e integrada. A propriedade `ApplicationIntent` na string de conexão roteia automaticamente as conexões somente leitura para esta réplica, isolando as cargas de trabalho de leitura.
Uma grande tabela de fatos em um data warehouse é frequentemente usada para consultas de agregação (SUM, COUNT, AVG) que estão com desempenho lento.
Criar um índice columnstore clusterizado na tabela de fatos.
Por quê: Os índices columnstore armazenam dados em formato colunar, proporcionando altíssima compressão de dados e habilitando a execução em modo de lote, o que acelera drasticamente as consultas analíticas de agregação e intensivas em varredura.
Um banco de dados apresenta contenção de bloqueio significativa entre consultas de leitura (relatórios) e consultas de gravação (transações).
Habilitar Read Committed Snapshot Isolation (RCSI) no banco de dados.
Por quê: O RCSI usa versionamento de linha, permitindo que os leitores vejam a última versão confirmada dos dados sem adquirir bloqueios compartilhados, eliminando assim os bloqueios dos escritores. Os escritores não bloqueiam os leitores.
Um aplicativo usando um banco de dados Serverless experimenta tempos de conexão iniciais lentos após um período de inatividade.
Diminuir o atraso de auto-pausa ou configurar um valor mínimo de vCore maior que zero.
Por quê: O atraso é causado pelo banco de dados que retoma de um estado pausado (cold start). Definir um valor mínimo de vCore impede que o banco de dados pause completamente, eliminando a latência de retomada ao custo de alguma cobrança contínua de computação.
Implementar um pipeline de CI/CD para implantações de esquema de banco de dados automatizadas, versionadas e repetíveis.
Usar um Projeto de Banco de Dados SQL (por exemplo, no Visual Studio) para gerar um arquivo DACPAC. Usar pipelines do Azure DevOps para implantar o DACPAC.
Por quê: Este é o padrão de Infraestrutura como Código (IaC) padrão para esquema SQL. O DACPAC é um modelo declarativo do esquema, e as ferramentas de implantação lidam com a geração do script diferencial, garantindo a consistência.
Um Azure SQL Database precisa ser escalonado automaticamente para cima ou para baixo com base em um cronograma ou limites de métricas (por exemplo, alta CPU).
Usar um runbook de Automação do Azure (PowerShell) acionado por um agendamento ou um alerta do Azure Monitor.
Por quê: O Azure SQL Database (nível Provisioned) não possui autoescalonamento integrado. O Azure Automation é a ferramenta padrão para orquestrar este tipo de tarefa operacional usando scripts e agendamentos.
Um script de manutenção (por exemplo, reconstrução de índice) precisa ser executado em centenas de bancos de dados Azure SQL.
Usar Elastic Jobs.
Por quê: Elastic Jobs é um serviço PaaS projetado especificamente para executar tarefas T-SQL em um grupo alvo de bancos de dados, gerenciando credenciais, agendamento e registro centralizadamente.
Garantir que todos os Azure SQL Servers recém-criados em uma assinatura tenham um recurso específico, como TDE ou Auditing, habilitado por padrão.
Criar uma Política do Azure com um efeito `DeployIfNotExists` ou `Modify`.
Por quê: O Azure Policy oferece governança em escala. O efeito `DeployIfNotExists` configurará automaticamente a configuração ausente durante a criação do recurso, aplicando a conformidade sem intervenção manual.
Agendar um script T-SQL recorrente ou tarefa de manutenção em um Azure SQL Managed Instance.
Usar o SQL Server Agent integrado.
Por quê: Managed Instance inclui o SQL Server Agent completo, fornecendo as mesmas capacidades familiares de agendamento de tarefas que o SQL Server local, sem a necessidade de um serviço de automação externo.
Controlar quando o Azure realiza manutenção planejada em um Azure SQL Database ou Managed Instance para minimizar o impacto nas operações de negócios.
Configurar uma Janela de Manutenção para o recurso.
Por quê: Este recurso permite selecionar um período de tempo predefinido (por exemplo, fins de semana) para o Azure aplicar atualizações, proporcionando previsibilidade sobre a manutenção que afeta o serviço.
Um aplicativo requer failover automático para uma região secundária para recuperação de desastres, sem a necessidade de alterações nas strings de conexão.
Configurar um Grupo de Failover Automático entre os bancos de dados/instâncias primários e secundários.
Por quê: Os grupos de failover fornecem endpoints de ouvinte de leitura-escrita e somente leitura. Esses endpoints redirecionam automaticamente o tráfego para o servidor primário/secundário atual após um failover, tornando o processo transparente para o aplicativo.
Os backups do banco de dados devem ser retidos por muitos anos (por exemplo, 7 a 10 anos) para atender aos requisitos legais ou regulatórios de conformidade.
Configurar uma política de Retenção de Backup de Longo Prazo (LTR).
Por quê: Os backups padrão de Restauração Pontual (PITR) são mantidos por um máximo de 35 dias. O LTR armazena backups completos em um Azure Blob Storage separado por até 10 anos, especificamente para necessidades de conformidade.
Um banco de dados deve permanecer disponível durante uma falha de datacenter (Availability Zone) dentro de uma única região do Azure.
Habilitar a configuração de redundância de zona para um banco de dados de nível Business Critical ou Premium.
Por quê: A redundância de zona implanta réplicas secundárias síncronas em diferentes datacenters físicos dentro da mesma região, proporcionando failover automático com RPO próximo de zero para interrupções em nível de zona.
Um Azure SQL Managed Instance requer uma solução de recuperação de desastres em uma região emparelhada do Azure com capacidade de failover automático.
Configurar um Grupo de Failover Automático para o Managed Instance.
Por quê: Este é o padrão canônico de DR para Managed Instance, fornecendo replicação assíncrona, endpoints de ouvinte para failover transparente de aplicativos e uma opção de failover automatizado.
É necessário poder restaurar um banco de dados para qualquer segundo específico do último mês.
Configurar o período de retenção de backup de curto prazo (PITR) para 30-35 dias.
Por quê: O Azure SQL automaticamente realiza backups completos, diferenciais e frequentes do log de transações. A configuração de retenção PITR (1-35 dias) determina por quanto tempo esses backups são mantidos, definindo a janela para restaurações pontuais.
Configurando um Windows Server Failover Cluster para um Grupo de Disponibilidade Always On do SQL Server em VMs do Azure.
Usar um Cloud Witness como testemunha de quorum.
Por quê: Um Cloud Witness usa o Azure Blob Storage e é a opção recomendada e mais resiliente para clusters no Azure. Evita a necessidade de uma terceira VM para uma testemunha de compartilhamento de arquivos ou configurações complexas de disco compartilhado.
Implementando uma Instância de Cluster de Failover (FCI) do SQL Server em VMs do Azure que requer armazenamento compartilhado.
Usar Azure Shared Disks (anexando um disco gerenciado a várias VMs).
Por quê: O Azure Shared Disks é a solução nativa do Azure para fornecer armazenamento de bloco que pode ser acessado por várias VMs, o que é um pré-requisito para uma FCI tradicional.
O processo de recuperação de desastres para um grupo de failover precisa ser testado sem impactar o banco de dados primário de produção.
Iniciar um failover planejado (manual) durante uma janela de manutenção de baixo impacto, validar a conectividade do aplicativo e, em seguida, fazer o failback.
Por quê: Um failover planejado garante a não perda de dados e é a forma mais completa de validar todo o processo de DR, incluindo a propagação de DNS e a reconexão do aplicativo. É um evento de produção breve e controlado.