O exame DP-300 pede que você escolha o modelo de implantação do Azure SQL certo para cada cenário. Memorizar nomes de recursos não é suficiente — você precisa entender quando cada opção chega aos seus limites. O exame cobre cinco domínios operacionais: implantação da plataforma de dados, proteção do ambiente, monitoramento e otimização, automação de tarefas e design de HA/DR. Este artigo percorre os critérios de decisão e as armadilhas frequentes por meio de cenários reais.
Três Modelos de Implantação
Imagine escolher entre um apartamento onde a administração cuida de toda a manutenção e outro onde você mesmo resolve problemas de encanamento. As duas opções mudam completamente sua rotina. O Azure SQL funciona da mesma forma.
é uma oferta de PaaS totalmente gerenciada. A Microsoft cuida de patches do SO, backups e alta disponibilidade. Opera no nível de banco de dados único; SQL Server Agent, consultas entre bancos de dados e CLR não são suportados.
também é PaaS, mas fornece uma instância completa do SQL Server. É a escolha certa para migrações de sistemas legados que exigem SQL Server Agent, consultas entre bancos de dados ou Linked Servers. Superfície de gerenciamento maior implica custo mais elevado.
é IaaS. O DBA controla todo o SO e a instalação do SQL Server. Escolha quando precisar de SSRS, SSIS ou controle completo sobre o sistema operacional.
Escolhas de Criptografia: TDE ou Always Encrypted?
Se você deposita dinheiro em um cofre, mas os funcionários da empresa gestora ainda podem abri-lo e ver o conteúdo, isso é realmente seguro? Essa pergunta traça a linha exata entre TDE e Always Encrypted.
criptografa dados em repouso no nível do disco. O mecanismo do SQL Server e os DBAs ainda podem ver os dados em texto simples. Protege contra ransomware e roubo físico de disco; habilitado por padrão no Azure SQL Database e no Managed Instance.
é criptografia do lado do cliente. Como as chaves ficam no aplicativo cliente ou no Azure Key Vault, o mecanismo do SQL Server não consegue acessar o texto simples. Quando um requisito afirma que mesmo os DBAs não devem ler colunas sensíveis — como CPF ou cartões de crédito — Always Encrypted é a resposta correta.
Nas questões: 'criptografar dados em repouso' aponta para TDE. 'DBAs não podem ler a coluna' ou 'equipe de segurança controla as chaves' aponta para Always Encrypted.
Alta Disponibilidade: Auto-Failover Group vs Active Geo-Replication
Uma aeronave comercial não voa com um único motor. Se um falhar, o outro mantém o voo. A alta disponibilidade do Azure SQL segue o mesmo princípio; a escolha depende do nível de automação necessário.
cria réplicas secundárias somente leitura em outra região do Azure. Se houver falha, você aciona o failover manualmente. Suportada apenas pelo Azure SQL Database.
adiciona failover automático sobre o Active Geo-Replication. Quando a região primária cai, o Azure redireciona o tráfego automaticamente. Fornece um único ponto de extremidade de leitura e gravação — a string de conexão não precisa mudar. Suportado pelo Azure SQL Database e pelo Managed Instance.
Requisitos rigorosos de RPO e RTO com automação: Auto-Failover Group. Controle manual para reduzir custo: Active Geo-Replication.
Ajuste de Desempenho: DTU vs vCore
Ao comprar um carro, você olha apenas para a potência ou também considera o consumo e o torque? Escolher o nível de serviço do Azure SQL requer o mesmo raciocínio multidimensional.
O modelo agrupa CPU, memória e I/O em um único número. Configuração simples, adequada para cargas previsíveis, mas sem ajuste granular de recursos. Comum em aplicações pequenas ou fases iniciais de migração.
O modelo permite especificar núcleos de CPU, memória e armazenamento de forma independente. Suporta Azure Hybrid Benefit para aplicar licenças existentes do SQL Server e reduzir custos. Preferido em ambientes corporativos.
é um conjunto de otimizações do SQL Server 2019: Adaptive Joins, Memory Grant Feedback e Deferred Variable Deferral. Eleve o nível de compatibilidade para 150 ou superior e os recursos são ativados automaticamente.
!DTU vs vCore
Os Três Modelos em uma Tabela
| Critério | Azure SQL Database | Azure SQL Managed Instance | SQL Server on Azure VM | |:--|:--|:--|:--| | Tipo de serviço | PaaS | PaaS | IaaS | | Controle do SO | Não disponível | Não disponível | Controle total | | SQL Server Agent | Não disponível | Disponível | Disponível | | Consultas entre BD | Não disponível | Disponíveis | Disponíveis | | SSRS / SSIS | Não disponível | Limitado | Suporte completo | | Gerenciamento de backup | Automático (Microsoft) | Automático (Microsoft) | Autogerenciado |
Recursos legados do SQL Server: Managed Instance. Controle total do SO: SQL Server on VM. Mínima sobrecarga de gerenciamento para nova aplicação: Azure SQL Database.
Roteiro de Estudo
Um bibliotecário classifica livros por gênero primeiro, depois por autor e ano. Estudar para o DP-300 funciona melhor da mesma forma: comece pelo panorama geral e aprofunde em recursos específicos.
Modelos de implantação: defina a fronteira entre Azure SQL Database, Managed Instance e SQL Server on Azure VM. → Azure SQL Database, Managed Instance e SQL on VM, Camadas de Serviço e Modelos de Computação do Azure SQL, Migração do SQL Server para o Azure SQL Autenticação e autorização: integração com Microsoft Entra ID, logins de servidor vs usuários de banco de dados, RBAC. → Microsoft Entra ID e Autenticação SQL Proteção de dados: TDE vs Always Encrypted, alcance do Dynamic Data Masking. → TDE e Always Encrypted, SQL Audit, Dynamic Data Masking e Row-Level Security Monitoramento e ajuste: Query Store, Intelligent Query Processing, principais DMVs. → Query Store, Azure Monitor e SQL Insights, Automatic Tuning, Manutenção de Índices e MAXDOP Automação: SQL Server Agent (apenas Managed Instance) vs Elastic Jobs (Azure SQL Database). → SQL Server Agent e Elastic Jobs HA/DR: PITR, LTR, Active Geo-Replication e Auto-Failover Group por retenção e automação. → Failover Group, Geo-Replication e PITR/LTR
Armadilhas Comuns: PITR vs LTR
Tirar uma foto diária do inventário e guardar um ano de fotos têm propósitos diferentes. A estratégia de backup no DP-300 segue a mesma lógica.
é o backup automático integrado do Azure SQL Database e do Managed Instance. Retenção padrão de 7 dias, configurável até 35. Use para recuperar dados excluídos acidentalmente restaurando para um momento específico.
armazena backups no Azure Blob Storage por até 10 anos. Para requisitos legais ou de conformidade além do limite de 35 dias do PITR. Qualquer menção de 'retenção além de 35 dias' ou 'arquivamento de conformidade' aponta para LTR.
SQL Server Agent está disponível apenas no Managed Instance. Para Azure SQL Database, use para agendar tarefas de automação.
Resumo do Exame
'Migração legada com consultas T-SQL entre bancos de dados' -- Azure SQL Managed Instance 'Controle total do SO e da instalação do SQL Server' -- SQL Server on Azure VM 'Banco de dados único com mínima sobrecarga de gerenciamento' -- Azure SQL Database 'Criptografia de coluna que DBAs não conseguem descriptografar' -- Always Encrypted 'Criptografia transparente em repouso, habilitada por padrão' -- Transparent Data Encryption (TDE) 'Failover automático com único ponto de extremidade' -- Auto-Failover Group 'Réplica somente leitura entre regiões, failover manual' -- Active Geo-Replication 'Retenção de backup além de 35 dias, conformidade' -- Long-Term Retention (LTR) 'Restaurar para ponto específico após exclusão acidental, até 35 dias' -- Point-in-Time Restore (PITR) 'Licenças SQL Server existentes, recursos independentes' -- Modelo vCore 'Automatizar tarefas no Azure SQL Database' -- Elastic Jobs
TDE = criptografia transparente em disco | Always Encrypted = chave no cliente, colunas cifradas | Auto-Failover Group = troca automática + ponto único
Pronto para saber onde você está? Experimente agora o exame de prática do DP-300.