Microsoft AZ-104: Bancos de Dados do Azure e Serviços de Dados — Guia de estudos

By Laurynas Brazys · 6 August 2026 · #microsoft #az-104 #certification #exam-prep #study-guide

Faz parte do Microsoft Azure Administrator Associate AZ-104 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Microsoft, ou faça testes cronometrados no ExamRoll.io.

Visão Geral

Os serviços de banco de dados e dados do Azure abrangem mecanismos relacionais gerenciados, NoSQL distribuído globalmente, cache em memória, análise em grande escala e integração/orquestração. Como administrador, você deve entender os modelos de compra, as camadas de serviço, a topologia de rede e segurança, a semântica de backup/DR e como combinar serviços para obter desempenho, custo e resiliência. Esta seção foca nas escolhas operacionais e nos recursos da plataforma que você configura no dia a dia: modelos de provisionamento (DTU vs. vCore), pools elásticos, backup e retenção de longo prazo, georreplicação e failover, instâncias gerenciadas injetadas em VNet, distribuição e consistência do Cosmos DB, réplicas de leitura/HA para bancos de dados relacionais de código aberto, mecanismos do Synapse e runtimes do Data Factory.

Bancos de Dados Relacionais do Azure (SQL Database, Managed Instance, MySQL/PostgreSQL)

O Azure SQL Database oferece dois modelos de compra. O modelo DTU agrupa CPU, memória e IOPS em Unidades de Transação de Banco de Dados (Database Transaction Units) com as camadas Basic, Standard e Premium; ele é simples, mas opaco, bom para cargas de trabalho estáveis, previsíveis e para dimensionamento legado. O modelo vCore expõe a geração/contagem de CPU e a memória, combinadas com controles de armazenamento e IOPS. O vCore permite transparência no dimensionamento, o Benefício Híbrido do Azure e descontos de Capacidade Reservada. Dentro do vCore, as camadas de serviço mapeiam para padrões de carga de trabalho e disponibilidade: a camada Uso Geral (General Purpose) usa armazenamento remoto Premium SSD ou Azure Premium com uma arquitetura de disponibilidade padrão; a camada Comercialmente Crítico (Business Critical) coloca computação e armazenamento em SSD local com múltiplas réplicas, baixa latência e scale-out de leitura integrado; a camada Hiperescala (Hyperscale) desacopla computação e armazenamento com servidores de página para escalonamento quase instantâneo e bancos de dados muito grandes. Para bancos de dados únicos, a camada de computação sem servidor (serverless) (vCore) escala a CPU elasticamente e pode pausar automaticamente para cortar custos de ociosidade.

Pools elásticos compartilham a computação entre múltiplos bancos de dados para absorver cargas de trabalho intermitentes e fora de fase a um custo agregado menor. Os pools estão disponíveis nas variantes DTU (eDTU) e vCore. Você define limites mínimos/máximos por banco de dados para conter “vizinhos barulhentos” e um máximo para o pool para controlar os gastos. A sobrescrição é aceitável quando os picos de uso são curtos e não correlacionados. O dimensionamento do pool depende do consumo médio somado mais uma margem para simultaneidade; monitorar as métricas por banco de dados e do pool é crucial para manter os SLOs.

Os backups são automáticos. O Azure SQL mantém backups completos, diferenciais e de log de transações com restauração pontual (PITR) para qualquer segundo dentro da janela de retenção (normalmente de 7 a 35 dias, dependendo da camada e da configuração de armazenamento). A retenção de longo prazo (LTR) persiste backups completos semanais por anos em armazenamento RA-GRS; você pode restaurar um backup LTR como um novo banco de dados em qualquer servidor na mesma assinatura e conjunto de regiões, e a restauração entre regiões está disponível se o armazenamento de backup com redundância geográfica estiver habilitado. As restaurações criam um novo banco de dados; elas não sobrescrevem o banco de dados existente.

As opções de georreplicação incluem a georreplicação ativa para bancos de dados e pools únicos (até quatro secundários legíveis com replicação assíncrona) e grupos de failover automático no escopo do servidor lógico. Os grupos de failover agrupam múltiplos bancos de dados (ou um servidor inteiro) com DR geográfico, um endpoint de ouvinte de leitura/gravação, um endpoint somente leitura para descarregar leituras, failover automático baseado em saúde e redirecionamento baseado em DNS. A camada Comercialmente Crítico também fornece scale-out de leitura por meio de uma réplica legível local, permitindo o descarregamento imediato da carga de trabalho de leitura sem a complexidade entre regiões.

O Azure SQL Managed Instance (MI) oferece compatibilidade de quase 100% com o mecanismo do SQL Server, incluindo SQL Agent, consultas entre bancos de dados, CLR, servidores vinculados, Service Broker e backup/restauração nativos de arquivos .bak do Azure Blob Storage. A MI é injetada em VNet: você a implanta em uma sub-rede dedicada e delegada com IPs privados e controles de NSG/UDR; planeje o tamanho da sub-rede e o espaço de endereço com antecedência, pois redimensionar sub-redes posteriormente é complexo. Os caminhos de migração incluem o Azure Database Migration Service (migrações online/offline), backup/restauração nativos para URL na MI e replicação transacional do SQL Server local para a MI. Escolha a MI quando precisar de paridade de área de superfície ou recursos no escopo da instância que os bancos de dados únicos não expõem.

O Azure Database for MySQL e o Azure Database for PostgreSQL (Servidor Flexível) fornecem mecanismos OSS gerenciados com controle sobre janelas de manutenção, opção de parar/iniciar para economizar custos, computação expansível e de uso geral, crescimento automático do armazenamento e integração com VNet. O Servidor Flexível oferece alta disponibilidade com replicação síncrona; você pode escolher HA com redundância de zona entre Zonas de Disponibilidade para um isolamento de falhas mais forte ou HA na mesma zona para menor latência de escrita. Réplicas de leitura estão disponíveis para scale-out de leituras e podem ser provisionadas dentro ou entre regiões; elas usam replicação assíncrona e são ideais para análises, relatórios ou microsserviços com uso intensivo de leitura. Promova uma réplica para failover ou expansão regional quando necessário, reconhecendo o potencial atraso na replicação.

Dados Distribuídos e Cache (Cosmos DB e Azure Cache for Redis)

O Azure Cosmos DB é um banco de dados multimodelo e distribuído globalmente que oferece APIs para Core (SQL), MongoDB, Cassandra, Gremlin (grafo) e Table. A escolha da API determina a compatibilidade do driver do cliente e a semântica do modelo de dados; operacionalmente, você gerencia a vazão (RUs provisionadas ou autoscale) e as partições, independentemente da API. Os dados são particionados horizontalmente por uma chave de partição que deve apresentar alta cardinalidade e distribuição de acesso uniforme para evitar partições quentes (hot partitions); evite chaves monotonicamente crescentes e considere chaves de partição hierárquicas onde existam padrões de acesso compostos. Consultas entre partições (cross-partition) são suportadas, mas consomem mais RUs; coloque dados relacionados na mesma partição (co-locate) usando a chave de partição sempre que possível.

Os níveis de consistência são ajustáveis por conta, banco de dados ou requisição: Strong (Forte) garante linearizabilidade; Bounded Staleness (Obsolescência Limitada) limita a obsolescência por tempo ou versão; Session (Sessão), o padrão, fornece leituras de suas próprias escritas (read-your-writes) para uma sessão; Consistent Prefix (Prefixo Consistente) garante a ordem sem consistência total; Eventual (Eventual) maximiza a disponibilidade e o desempenho. Para escritas em múltiplas regiões, escolha uma política de resolução de conflitos apropriada (LastWriterWins ou personalizada via stored procedures) e defina as prioridades de failover. A distribuição global permite adicionar regiões com um clique; o serviço gerencia a replicação, o failover e o roteamento otimizado para latência com SLAs de vazão, latência, disponibilidade e consistência.

O Azure Cache for Redis oferece latência de submilisegundos, com tecnologia Redis. Os níveis (tiers) progridem em capacidade: Basic (nó único, para dev/test), Standard (nó duplo primário/réplica replicado com SLA), Premium (tamanhos maiores, clustering, persistência, injeção de VNet, georreplicação e módulos Redis como Bloom), Enterprise e Enterprise Flash (baseados no Redis Enterprise com clustering avançado, georreplicação ativa para escritas multiprimárias e caches maiores com suporte de Flash). As políticas de remoção (eviction) definem o comportamento sob pressão de memória: noeviction (erros na escrita), allkeys-lru/lfu/random (considera todas as chaves) e volatile-lru/lfu/ttl/random (considera apenas chaves com TTL). Para cache de sessão, use o nível Premium ou superior para persistência se não puder arcar com a perda de sessão, habilite TTLs nas chaves para limitar o crescimento e considere o clustering para vazão e escala. Posicione o cache na mesma região e rede virtual (virtual network) dos servidores da aplicação para minimizar a latência; use Managed Identity ou chaves de acesso e imponha o isolamento de rede via Private Link ou injeção de VNet.

Analytics e Integração (Synapse Analytics e Data Factory)

O Azure Synapse Analytics unifica data warehousing, big data e integração de dados. O pool de SQL dedicado (antigo SQL DW) é um mecanismo MPP com distribuições hash/round-robin, tabelas replicadas e cache de conjunto de resultados. Você pode escalar a computação (scale up/down) para atender às janelas de SLA e pode pausá-la para pagar apenas pelo armazenamento. O isolamento de cargas de trabalho (workload) pode ser alcançado com grupos de carga de trabalho e configurações de importância para proteger consultas críticas. O pool de SQL sem servidor (serverless) fornece T-SQL sob demanda sobre dados no Azure Data Lake Storage Gen2 sem provisionamento; você paga por TB verificado e pode externalizar esquemas usando exibições (views) para camadas semânticas. Os pools do Spark trazem o Apache Spark para o Synapse com autoscale e clusters sob demanda, permitindo o uso de notebooks, Delta Lake e machine learning com segurança integrada e linhagem de dados; você pode compartilhar dados do lakehouse entre os mecanismos Spark e SQL.

O Azure Data Factory (ADF) orquestra a movimentação e a transformação de dados. Os pipelines coordenam atividades como Copy, Data Flow (fluxos de mapeamento baseados em Spark) e computação externa (Databricks, Synapse, Functions). Os Datasets definem a forma e a localização dos dados, enquanto os linked services encapsulam os detalhes de conexão (autenticação, endpoints) para as origens/destinos. Os Integration Runtimes (IRs) fornecem o plano de computação e rede: Azure IR para movimentação e transformação nativas da nuvem, Self-hosted IR para fontes de dados on-premises ou em redes privadas via HTTPS de saída, e Azure-SSIS IR para a migração lift-and-shift de pacotes SSIS. Os gatilhos (Triggers) — de agendamento (schedule), janela em cascata (tumbling window), baseados em eventos (event-based) — permitem uma orquestração repetível; a rede virtual gerenciada e os private endpoints podem ser habilitados para proteção contra exfiltração de dados e conectividade em conformidade. A parametrização e a integração com o Key Vault dão suporte a padrões reutilizáveis e seguros para a promoção entre ambientes (dev/test/prod).

Continuidade de Negócios, Recursos Geográficos e Pools Elásticos

As estratégias de backup e restauração diferem por serviço, mas compartilham temas principais: automatizar, testar restaurações regularmente e separar a PITR (restauração para um ponto no tempo) de erros operacionais da LTR (retenção de longo prazo) para conformidade. No Azure SQL, use a PITR para exclusões acidentais ou implantações ruins; armazene backups completos semanais de LTR em RA-GRS para retenção regulatória e restaurações de recuperação de desastres entre regiões. Para o Servidor Flexível do MySQL/PostgreSQL, habilite backups automatizados com armazenamento com redundância geográfica onde for suportado, defina a retenção por política e valide restaurações para um ponto no tempo em servidores alternativos. Contas do Cosmos DB com múltiplas regiões permitem failover automático; combine com gravações multirregionais quando o RPO deve ser zero e a aplicação consegue resolver conflitos de forma determinística.

A georreplicação e os grupos de failover automático no Azure SQL fornecem DR e offload de leitura. Use a georreplicação ativa para um único banco de dados/pool quando quiser gerenciar explicitamente os secundários; use grupos de failover automático para agrupar muitos bancos de dados e obter listeners baseados em DNS, além de failover automático. Onde leituras de baixa latência são importantes, mas DR não é o objetivo, use o scale-out de leitura do nível Business Critical ou as réplicas nomeadas do Hyperscale para manter as cargas de trabalho de análise e relatórios fora do primário. Monitore o lag de replicação e os sinais de saúde do failover, e teste exercícios de failover para validar o RTO/RPO.

Pools elásticos são alavancas de otimização de custos para SaaS multi-tenant e frotas de pequenos bancos de dados. Em pools baseados em DTU, aloque eDTUs com limites por banco de dados; em pools vCore, aloque vCores, memória e taxa de transferência de IO com um máximo de vCores por banco de dados e governança de IO. Dimensione corretamente medindo o uso do 95º percentil por banco de dados e alinhando a capacidade do pool aos padrões de concorrência; aumente os limites por banco de dados para tenants com SLOs mais altos e considere dividir os pools por classe de carga de trabalho (ex: tenants pesados vs. leves). Use alertas sobre os limites do pool e por banco de dados para detectar a saturação precocemente. Quando um pequeno número de bancos de dados atinge consistentemente os limites máximos, mova-os para uma computação dedicada ou um pool separado para manter a previsibilidade.

Cenário de Problema Prático

A Starbucks precisa modernizar sua plataforma global de fidelidade para atender aos picos de tráfego durante promoções, reduzir a sobrecarga operacional e suportar análises sem interromper as operações das lojas em todo o mundo.

Particionar o armazenamento de dados operacional:

Escolha o Azure Cosmos DB (API Core SQL) para interações de clientes e eventos de recompensas para alcançar distribuição global com baixa latência. Configure gravações multirregionais em regiões próximas às principais populações de clientes e defina a consistência de Sessão para equilibrar o read-your-writes com o desempenho. Selecione uma chave de partição de alta cardinalidade, como customerId, ou uma chave hierárquica composta (customerId, eventMonth) para distribuir a taxa de transferência e suportar padrões de consulta comuns.

Implementar dados transacionais de contas e catálogo:

Implante o Azure SQL Managed Instance para saldos de contas, resgates e SKU/catálogo, pois é necessária compatibilidade de quase 100% com o SQL Server para os stored procedures existentes e a lógica entre bancos de dados. Coloque a MI em uma sub-rede dedicada e delegada com NSGs e tabelas de rotas, conforme exigido pela injeção de VNet, permitindo o acesso privado a partir de sub-redes de aplicativos e do ExpressRoute.

Fornecer escala de leitura global e DR para cargas de trabalho relacionais:

Para novos microsserviços usando o Azure SQL Database, use o nível vCore Business Critical para baixa latência e scale-out de leitura. Crie um grupo de failover automático para uma região emparelhada com endpoints de ouvinte (listener) somente leitura para leituras localizadas e failover automático para atender aos objetivos de DR.

Adicionar gerenciamento de sessão de baixa latência:

Implante o Azure Cache for Redis Premium com clusterização e persistência de dados para tokens de sessão web e móvel. Defina uma política de evicção allkeys-lfu para manter as sessões acessadas com frequência residentes. Integre o cache na mesma VNet e região da camada de aplicação para minimizar a latência.

Orquestrar a movimentação de dados e construir a análise:

Use o Azure Data Factory para copiar dados operacionais (do change feed do Cosmos DB e do SQL MI) para o Azure Data Lake Storage Gen2. Empregue um IR de VNet Gerenciada com endpoints privados para evitar a exfiltração de dados. Parametrize os pipelines e use gatilhos de janela em cascata (tumbling window) para garantir o processamento ordenado.

Habilitar análise empresarial com controle de custos elástico:

No Azure Synapse Analytics, use o pool de SQL sem servidor (serverless) para exploração ad hoc sobre dados parquet e um pool de SQL dedicado para modelos de BI curados e de alta concorrência com desempenho previsível. Crie pools do Spark para engenharia de features sobre o comportamento de fidelidade e grave tabelas Delta no lake para interoperabilidade entre Spark e SQL.

Governança, backups e retenção:

Configure as prioridades de failover automático do Cosmos DB e monitore conflitos usando LastWriterWins com um campo de timestamp. Para o Azure SQL Database e MI, verifique as janelas de PITR e habilite a LTR para atender à retenção de conformidade. Para instâncias do Servidor Flexível que suportam serviços OSS auxiliares (ex: telemetria de loja regional em PostgreSQL), habilite a alta disponibilidade com redundância de zona e configure réplicas de leitura para relatórios.

Por que esses serviços: A distribuição global e a consistência ajustável do Cosmos DB atendem às interações sensíveis à latência em todo o mundo; a MI preserva recursos complexos do SQL Server enquanto fornece operações gerenciadas; os bancos de dados Business Critical fornecem escala de leitura local sem a latência entre regiões; o Redis garante acesso à sessão em submilisegundos durante picos de tráfego; o ADF proporciona movimentação segura e governada a partir de redes privadas; o Synapse combina análises sob demanda e provisionadas para insights escaláveis e com custo-benefício. Essa composição atende aos SLOs de desempenho durante as promoções, reduz o esforço administrativo por meio de PaaS gerenciado e impõe limites claros de RTO/RPO e conformidade.

← Azure App Service e Computação PaaS · Todos os domínios · Azure Monitor →

Pratique estas questões → · Prática cronometrada no ExamRoll.io →