O domínio de banco de dados do AZ-305 exige julgamento baseado em cenários, não memorização. Azure SQL Database, SQL Managed Instance, Cosmos DB, PostgreSQL Flexible Server e Synapse Analytics têm condições distintas em que cada um é a escolha certa — e a prova testa exatamente esses limites. Aqui detalhamos os critérios de seleção essenciais por meio de padrões encontrados em 36 questões reais de prova.
---
Escolhendo entre Azure SQL Database e Managed Instance
Os serviços de banco de dados relacional do Azure se dividem em três opções: Azure SQL Database, SQL Managed Instance e SQL Server on Azure VM. Os três são construídos sobre o mecanismo SQL Server, mas diferem significativamente em cobertura de recursos e sobrecarga operacional.
Azure SQL Database é uma oferta PaaS totalmente gerenciada. Na camada Serverless, o vCore escala automaticamente para cima e para baixo, e o banco de dados pausa após um período de inatividade, eliminando custos de computação durante esse tempo. Isso o torna ideal para cargas de trabalho intermitentes.
SQL Managed Instance oferece compatibilidade próxima de 100% com o SQL Server. Recursos de nível de instância que Azure SQL Database não suporta — SQL Server Agent, stored procedures CLR, consultas entre bancos de dados e transações distribuídas (MSDTC) — ficam disponíveis sem alterações de código, tornando-o a primeira escolha para migrações lift-and-shift.
As diferenças entre camadas dentro do Azure SQL Database também importam. Somente a camada General Purpose suporta Serverless, enquanto Business Critical entrega I/O abaixo de 1ms usando SSDs locais. Hyperscale permite escalar computação e armazenamento de forma independente até 100 TB, sendo adequado para cargas de trabalho OLTP de grande escala em dezenas de terabytes ou mais.
Elastic Pool permite que vários bancos de dados compartilhem um pool de vCore, reduzindo custos em até 50% em cenários SaaS multi-tenant, ao mesmo tempo que garante isolamento com limites mínimos e máximos por banco de dados. O modelo de compra vCore é o único que suporta Azure Hybrid Benefit (até 55% de economia) e Long-Term Retention (LTR, até 10 anos de retenção de backup).
!Azure SQL Database vs Managed Instance
Cosmos DB e NoSQL distribuído globalmente
Azure Cosmos DB é um banco de dados NoSQL totalmente gerenciado que garante latência de um único dígito em milissegundos em qualquer região do mundo. Duas palavras-chave acompanham cada cenário de Cosmos DB na prova: escritas simultâneas em múltiplas regiões e SLA de resposta em milissegundos.
Com escritas em múltiplas regiões habilitadas, cada região tem um endpoint de escrita independente, de modo que as escritas continuam mesmo que alguma região falhe (Active-active). Em contraste, Azure SQL Database Active Geo-Replication mantém as réplicas secundárias como somente leitura, o que significa que não pode suportar escritas em múltiplas regiões.
O modo Provisioned Throughput pré-aloca a taxa de transferência em RU/s e garante contratualmente uma latência de leitura P99 de 10ms e latência de escrita de 15ms. Esta é a única opção quando você precisa provar SLAs de latência em documentação durante auditorias regulatórias.
Escolha a API de acordo com seu modelo de dados. Documentos JSON com consultas SQL requerem a API NoSQL (Core SQL); compatibilidade com o driver do MongoDB indica a MongoDB API; SQL distribuído sobre PostgreSQL usa a PostgreSQL API (baseada em Citus); e traversal de relacionamentos nó/aresta usa a Gremlin API. Para traversals de múltiplos saltos como “amigos dos amigos,” a Gremlin API é a resposta correta.
Synapse Link for Cosmos DB sincroniza automaticamente os dados do Cosmos DB em um repositório analítico orientado a colunas sem ETL, permitindo análises no Synapse Analytics sem impacto no desempenho operacional.
---
PostgreSQL e MySQL Flexible Server
Azure Database for PostgreSQL Flexible Server e Azure Database for MySQL Flexible Server são versões totalmente gerenciadas de seus respectivos bancos de dados relacionais de código aberto. As questões do exame AZ-305 nessa área focam principalmente em configurações de alta disponibilidade e opções de recuperação de desastres.
Existem três camadas de computação: Burstable, General Purpose e Business Critical. A alta disponibilidade com redundância de zona só é suportada na camada General Purpose e superiores. A camada Burstable tem o menor custo, mas como não suporta HA Zone-redundant, você deve escolher General Purpose ou superior sempre que o requisito indicar que o serviço deve sobreviver a uma falha de único datacenter.
Também é importante distinguir entre as opções de recuperação de desastres regionais. Zone-redundant HA oferece redundância entre zonas de disponibilidade dentro da mesma região, protegendo contra falhas no nível do datacenter. Geo-redundant Backup replica automaticamente os backups para outra região do Azure, permitindo a recuperação quando uma região inteira fica indisponível. Se um RTO de algumas horas for aceitável e a recuperação manual for viável, o backup georredundante por si só pode cumprir os requisitos de recuperação de desastres regional de forma econômica, sem necessidade de Zone-redundant HA.
Lembre-se também de que réplicas de leitura implantadas na mesma região não podem servir para recuperação de desastres regional. Se o DR regional é o objetivo, as réplicas devem ser implantadas em uma região diferente, ou o backup georredundante deve ser usado.
---
Cargas de trabalho analíticas: Synapse e data warehousing
Azure Synapse Analytics oferece um data warehouse (Dedicated SQL Pool), processamento de big data baseado em Apache Spark e integração com Azure Data Lake Storage em uma única plataforma. Se você precisa transformar dezenas de terabytes de dados de pesquisa com Spark e analisar dados estruturados e não estruturados juntos, o Synapse Studio oferece uma única superfície de gerenciamento.
Dedicated SQL Pool usa uma arquitetura MPP para suportar data warehouses em escala de petabytes. A decisão entre Synapse e Databricks é simples: escolha Synapse Analytics quando precisar de gerenciamento unificado de SQL DW + Spark + Data Lake; escolha Databricks quando o foco for em machine learning avançado centrado em Spark.
---
Tabela comparativa de serviços
| Serviço | Caso de uso principal | Escalabilidade | Latência | Modelo de custo | |---------|-----------------------|----------------|----------|-----------------| | Azure SQL Database (Serverless) | Cargas intermitentes ou imprevisíveis | vCore escala automaticamente 0,5–80 | Nível geral | Cobrança por segundo; sem custo de computação em inatividade | | Azure SQL Database (Hyperscale) | OLTP de grande escala 10+ TB | Computação e armazenamento escalam independentemente até 100 TB | Nível geral | Arquitetura de servidor de páginas de armazenamento | | SQL Managed Instance | Compatibilidade total com SQL Server para lift-and-shift | Escalonamento vertical no nível de instância | Sub-1ms na camada Business Critical | Cobrança por hora de instância | | Cosmos DB (Provisioned) | Escritas em múltiplas regiões, SLA em ms, NoSQL | Escalonamento horizontal em RU/s | P99 abaixo de 10ms | RU/s pré-alocados | | PostgreSQL Flexible Server | Relacional de código aberto com Zone-redundant HA | Escalonamento vertical | RDBMS padrão | Cobrança por hora por camada | | Synapse Analytics | SQL DW + Spark + Data Lake unificados | Escalonamento horizontal em DWU | Processamento analítico em lote | Cobrança por hora de DWU |
---
Critérios de seleção que frequentemente confundem os candidatos
A chave das questões de prova é mapear palavras-chave com precisão aos serviços. Aqui estão os padrões mais testados organizados por cenário.
Cenário de migração de banco de dados relacional
Cenário: Você está migrando um SQL Server on-premises e precisa preservar o SQL Agent, stored procedures CLR e consultas entre bancos de dados exatamente como estão.
A resposta é SQL Managed Instance. Azure SQL Database não suporta esses recursos de nível de instância. SQL Server on Azure VM oferece compatibilidade perfeita de recursos, mas como solução IaaS requer que você gerencie patches do sistema operacional e backups por conta própria, adicionando sobrecarga operacional significativa. Quando você precisa de gestão PaaS combinada com plena compatibilidade com SQL Server, SQL Managed Instance é a resposta.
Cenário de redução de custos
Cenário: Você quer reutilizar licenças de SQL Server existentes (com Software Assurance) no Azure, ou precisa reter backups por sete ou mais anos.
Ambas as condições exigem o modelo vCore. Azure Hybrid Benefit e Long-Term Retention (LTR) estão disponíveis somente sob o modelo de compra vCore. Nenhum dos dois recursos está disponível com o modelo DTU.
Decisão Cosmos DB vs SQL Database
Cenário: Os dados devem ser escritos simultaneamente de múltiplas regiões ao redor do mundo, com tempos de resposta em milissegundos garantidos.
A resposta é Cosmos DB com escritas em múltiplas regiões habilitadas. Azure SQL Database Active Geo-Replication mantém as réplicas secundárias como somente leitura e não pode suportar escritas em múltiplas regiões.
Cenário: Você precisa de SLAs garantidos contratualmente para latência de escrita e taxa de transferência, com documentação que possa ser apresentada durante auditorias regulatórias.
Novamente, a resposta é Cosmos DB Provisioned Throughput. O Azure documenta oficialmente SLAs de quatro dimensões — disponibilidade, latência de leitura, latência de escrita e taxa de transferência — em seus acordos de serviço.
Decisão Elastic Pool vs Serverless
Cenário: Você gerencia centenas de bancos de dados de clientes com padrões de uso altamente variáveis e quer reduzir a sobrecarga de gestão enquanto otimiza custos.
A resposta é Elastic Pool. Vários bancos de dados compartilham um recurso em pool, e o gerenciamento é simplificado ao nível do pool. Serverless é a esc