Microsoft AZ-305: Armazenamento de Dados e Soluções de Banco de Dados — Guia de estudos

By Laurynas Brazys · 11 August 2026 · #microsoft #az-305 #certification #exam-prep #study-guide

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

Visão Geral

Projetar o armazenamento de dados no Azure exige equilibrar consistência, latência, disponibilidade, complexidade operacional e custo entre múltiplas opções de banco de dados e armazenamento. A plataforma abrange bancos de dados relacionais totalmente gerenciados, NoSQL distribuído globalmente, armazenamento de objetos com governança do ciclo de vida dos dados, data lakes analíticos de alta taxa de transferência e caches em memória. Sua arquitetura deve começar com as características da carga de trabalho — transacional vs. analítica, alcance global vs. localidade, rigidez do esquema, padrões de leitura/escrita, tamanho e velocidade — e selecionar o serviço e a configuração que correspondam a essas restrições, ao mesmo tempo em que atendem aos requisitos de segurança, resiliência e governança.

Serviços de Dados Relacionais no Azure

O Azure SQL Database oferece dois modelos de compra. O modelo DTU combina CPU, memória e E/S em uma unidade mista nas camadas Basic, Standard e Premium; é simples, mas opaco para o planejamento de capacidade. O modelo vCore separa computação, memória e armazenamento, com opções de hardware, escalabilidade previsível e alavancas de custo, como o Azure Hybrid Benefit e a capacidade reservada. No modelo vCore, as principais camadas de serviço são General Purpose (computação desacoplada e armazenamento remoto, custo equilibrado), Business Critical (SSD local com réplicas Always On para E/S de baixa latência e failover rápido) e Hyperscale (arquitetura estruturada em log com servidores de página e armazenamento distribuído para escala de múltiplos terabytes e operações rápidas baseadas em snapshots). A opção Serverless para General Purpose escala a computação automaticamente entre um mínimo e um máximo configurados e pode pausar automaticamente quando ocioso; você paga por segundo de computação e pelo armazenamento. Isso é adequado para cargas de trabalho intermitentes ou de desenvolvimento, mas incorre em um “cold-start” (partida a frio) e aquecimento de cache ao ser retomado.

Os pools elásticos (Elastic pools) permitem que vários bancos de dados compartilhem um orçamento de computação e uma margem de E/S, suavizando picos e reduzindo custos para muitos bancos de dados pequenos com carga variável. Os pools existem nos modelos DTU e vCore; o dimensionamento correto exige a compreensão da concorrência agregada e dos limites de burst por banco de dados para evitar efeitos de “vizinho barulhento” (noisy-neighbor).

Os padrões de resiliência do Azure SQL incluem a replicação geográfica ativa (active geo-replication) e os grupos de failover automático (auto-failover groups). A replicação geográfica ativa mantém de forma assíncrona até quatro bancos de dados secundários legíveis em qualquer região do Azure, com o failover iniciado por banco de dados. Os grupos de failover automático gerenciam múltiplos bancos de dados como uma unidade entre servidores lógicos emparelhados, fornecem endpoints de listener de leitura/escrita e somente leitura, e lidam com failover planejado ou não planejado com períodos de carência configuráveis — ideal para SaaS multilocatário (multi-tenant). A redundância de zona está disponível nas camadas Business Critical (e Hyperscale) para abranger Zonas de Disponibilidade dentro de uma região, melhorando a tolerância a falhas intrarregional.

O Azure SQL Managed Instance (MI) visa a compatibilidade de quase 100% com o SQL Server (SQL Agent, consultas entre bancos de dados, Linked Servers, CLR, Service Broker). Ele é executado dentro da sua rede virtual em uma sub-rede dedicada e delegada (Microsoft.Sql/managedInstances). As instâncias usam apenas IPs privados; configure grupos de segurança de rede (network security groups) e tabelas de rotas (route tables) para permitir o tráfego de gerenciamento para os planos de controle do Azure e o tráfego de dados para suas aplicações. Integre com o Azure Private DNS (ou DNS personalizado) para que os clientes resolvam o FQDN privado da instância gerenciada. Para conectividade híbrida e migração, garanta linha de visada via VPN site-to-site ou ExpressRoute. Os caminhos de migração incluem backup/restauração nativos para o Azure Blob Storage (WITH COPY_ONLY, WITH MOVE), migrações online ou offline usando o Azure Database Migration Service (DMS) e replicação transacional ou “log shipping” quando apropriado. A camada Business Critical do MI adiciona armazenamento de baixa latência e alta disponibilidade; a General Purpose oferece armazenamento de custo-benefício com discos remotos.

O Azure Database for PostgreSQL e o MySQL Flexible Server fornecem controle granular sobre as janelas de manutenção, parada/início para economia de custos e isolamento de rede via integração com VNet. As opções de alta disponibilidade incluem um standby síncrono na mesma zona para o failover mais rápido e HA com redundância de zona para resistir a falhas de zona (replicação síncrona com failover automático). As réplicas de leitura (na mesma região e, para muitas versões, entre regiões) descarregam cargas de trabalho de leitura e suportam análises quase em tempo real; elas são assíncronas e não são adequadas para leituras estritamente consistentes. Selecione as camadas de computação e armazenamento com base nas metas de IOPS/latência e planeje o tratamento de failover de conexão nas bibliotecas de cliente.

Armazenamentos Não Relacionais e Distribuídos Globalmente

O Azure Cosmos DB é um banco de dados totalmente gerenciado, multimodelo e distribuído globalmente, com replicação global turnkey e leituras e escritas com latência de milissegundos de um dígito no percentil 99. Escolha a API com base na adequação ao ecossistema e no modelo de dados: API Core (SQL) para documentos e consultas semelhantes a SQL com amplo suporte de SDK; API do MongoDB para compatibilidade com o protocolo de fio (wire-protocol) do Mongo; API do Cassandra para cargas de trabalho de coluna larga (wide-column); API do Gremlin para travessia de grafos; e API de Tabela para cenários de chave/atributo. A taxa de transferência (throughput) é provisionada em unidades de requisição (RUs), usando modos fixo ou de dimensionamento automático (autoscale); projete as partições e a indexação para minimizar o consumo de RUs.

O particionamento é fundamental. Selecione uma chave de partição de alta cardinalidade que distribua o armazenamento e o tráfego uniformemente, evite partições quentes (hot partitions) e se alinhe com seus padrões de acesso (por exemplo, tenantId ou userId para escritas multilocatário (multi-tenant), ou uma chave composta sintética para balancear as leituras). As partições lógicas são limitadas em tamanho e taxa de transferência; modele para manter os conjuntos de trabalho quentes (hot working sets) distribuídos. Não é possível alterar a chave de partição de um contêiner após a criação; as migrações exigem novos contêineres e movimentação de dados.

A consistência do Cosmos abrange cinco níveis ajustáveis: Forte (linearizável, maior RU/latência), Desatualização Limitada (Bounded Staleness, com atraso previsível ou janela de versão), Sessão (leitura de suas próprias escritas centrada no cliente, um padrão popular), Prefixo Consistente (sem leituras fora de ordem) e Eventual (máxima disponibilidade e desempenho com possíveis anomalias). Escolha padrões por conta e substitua-os por requisição quando necessário. As escritas multirregionais habilitam um verdadeiro multi-mestre (multi-master) para escritas globais de baixa latência e maior disponibilidade; lide com a resolução de conflitos via Última Escrita Vence (Last-Writer-Wins, em uma propriedade designada), políticas personalizadas ou lógica de aplicação com procedimentos armazenados (stored procedures) e feed de conflitos.

Ao escolher o armazenamento de dados correto, combine os requisitos com as capacidades. Integridade relacional estrita, junções complexas (joins) e garantias transacionais favorecem o Azure SQL Database ou a Managed Instance. Escala global massiva, esquema flexível e acesso geográfico de baixa latência favorecem o Cosmos DB. Problemas de grafo (social, recomendação, topologia de rede) mapeiam para a API Gremlin do Cosmos DB ou para os recursos de grafo no Azure SQL quando a colocação relacional é benéfica. Telemetria de série temporal de alta ingestão, exploração ad hoc e análises em tempo quase real se alinham com o Azure Data Explorer. Blobs não estruturados, mídias e grandes cargas binárias (payloads) pertencem ao Azure Blob Storage ou ao ADLS Gen2, com os metadados em um banco de dados complementar.

Armazenamento de Objetos e Analítico

O Azure Blob Storage é a base para dados não estruturados. As camadas de acesso alinham o custo de armazenamento com os padrões de acesso: Hot para acesso frequente, Cool para acesso infrequente com retenção mínima de 30 dias, e Archive para armazenamento frio de longo prazo com retenção mínima de 180 dias e reidratação que leva horas. Contas de blob de bloco Premium em SSD oferecem suporte a cargas de trabalho de baixa latência e alta transação, como pipelines de ingestão. As políticas de gerenciamento do ciclo de vida automatizam transições e exclusões com base em regras — hora da última modificação, tags de índice de blob ou prefixos — reduzindo o custo sem intervenção manual.

A replicação de objetos para blobs de bloco espelha objetos e suas versões de forma assíncrona entre contas de armazenamento (na mesma região ou em regiões diferentes). Ela requer o versionamento de blobs na origem e no destino e é orientada por políticas por par de contêineres, suportando conformidade e distribuição multirregional, ao mesmo tempo que mantém a independência das escolhas de redundância no nível da conta. A imutabilidade (WORM) é aplicável no escopo do contêiner ou do blob por meio de retenção baseada em tempo e bloqueios legais (legal holds), com opções como ⟦CODE

Padrões de Segurança, Acesso e Resiliência

A delegação de acesso do Azure Storage usa tokens e políticas de SAS (Shared Access Signature). Uma SAS de Serviço concede acesso com escopo definido a um recurso específico (contêiner, blob, compartilhamento de arquivos, fila ou tabela). Uma SAS de Conta abrange vários serviços na conta e é muito poderosa; proteja-a com cuidado. Uma SAS de delegação de usuário (apenas para o serviço Blob) deriva do Azure AD e de uma chave de delegação de usuário, permitindo o controle de acesso por usuário sem as chaves da conta — ideal para aplicações multilocatário (multi-tenant) e concessões de curta duração. As políticas de acesso armazenadas (em contêineres, compartilhamentos, filas e tabelas) vinculam os tokens SAS a uma política do lado do servidor para que você possa revogar ou encurtar o acesso sem rotacionar as chaves da conta; uma SAS sem uma política de acesso armazenada só pode ser revogada pela expiração do token ou pela rotação das chaves.

Para criptografia, o Azure Storage usa a criptografia do lado do serviço por padrão. Chaves gerenciadas pelo cliente (CMK) armazenadas no Azure Key Vault ou Managed HSM fornecem controle centralizado do ciclo de vida das chaves e auditabilidade. Os escopos de criptografia permitem diferentes CMKs dentro da mesma conta de armazenamento por contêiner ou prefixo, suportando o uso de chaves por locatário (per-tenant). Para controle por blob do lado do cliente, chaves fornecidas pelo cliente (CPK) podem ser fornecidas nas requisições. Combine CMK no nível da conta ou do escopo com CPK conforme necessário para isolamento regulatório.

A segurança e a resiliência do Azure SQL se baseiam nos níveis (tiers) da plataforma e nos recursos de replicação já descritos. Use grupos de failover automático para failover coordenado entre regiões e endpoints de ouvinte (listener) cativos, e habilite a redundância de zona onde disponível para suportar falhas de zona. Para dados sensíveis, aplique o mascaramento dinâmico de dados para ofuscar PII nos resultados de consultas para usuários não privilegiados, e considere o Always Encrypted com enclaves seguros para proteção do lado do cliente de colunas quando os administradores devem ser impedidos de visualizar o texto simples. Monitore as metas de RPO/RTO em relação ao comportamento de replicação do seu nível e teste o failover rotineiramente.

Ao planejar arquiteturas de ponta a ponta, unifique a identidade (Azure AD para SQL, armazenamento e analytics), aplique o princípio do menor privilégio com RBAC e ACLs, use o Private Link ou a integração com VNet para manter os dados fora da internet pública, e implemente políticas de ciclo de vida, imutabilidade e replicação para atender aos objetivos de retenção e DR (recuperação de desastres).

Cenário de Problema Prático

A Contoso Retail está lançando uma plataforma global de e-commerce com tráfego diurno volátil, controles rigorosos de PII, mídia de produtos em escala de petabytes e personalização quase em tempo real. Eles exigem leituras de baixa latência em todo o mundo, tempo de inatividade (downtime) mínimo e análise de dados governada.

Coloque os bancos de dados transacionais de catálogo e pedidos no Azure SQL Database usando o modelo vCore:

Seleção de nível (tier): Business Critical para pedidos (armazenamento de baixa latência e failover rápido) e General Purpose serverless para o catálogo (picos de tráfego com janelas de ociosidade).
Por quê: O modelo vCore fornece dimensionamento previsível e o Benefício Híbrido do Azure; o nível Business Critical atende aos requisitos de latência/HA para pedidos; o modo serverless minimiza o custo de computação durante a baixa atividade.

Configure um grupo de failover automático entre regiões emparelhadas para ambos os bancos de dados e habilite a redundância de zona:

Por quê: Um ouvinte (listener) de leitura/escrita unificado simplifica o failover da aplicação; a redundância de zona protege contra interrupções de zona; as réplicas entre regiões atendem aos requisitos de DR e oferecem escala de leitura para relatórios.

Armazene imagens e vídeos de produtos no Azure Blob Storage (general-purpose v2) com gerenciamento do ciclo de vida e replicação de objetos:

Política: Camada Hot para itens ativos, Cool após 30 dias, Archive após 180 dias; replique para uma região secundária via replicação de objetos.
Por quê: Minimiza o custo de armazenamento ao longo do tempo, ao mesmo tempo que fornece distribuição regional assíncrona independente da redundância da conta; atende aos requisitos de retenção com imutabilidade para ativos legais (WORM baseado em tempo).

Construa o serviço de perfil de cliente e carrinho de compras no Azure Cosmos DB (Core API) com escritas multirregionais e consistência de Sessão (Session):

Design: Particionar por userId para distribuir as escritas; habilitar RUs com autoscale.
Por quê: O modo multimestre (multi-master) fornece escritas de baixa latência para uma audiência global e alta disponibilidade; a consistência de Sessão garante a leitura das próprias escritas (read-your-writes) por usuário com fortes garantias de UX e uso eficiente de RUs.

Introduza o Azure Cache for Redis Enterprise para estado de sessão, cache de detalhes de produtos e limitação de taxa (rate limiting):

Modo: Cluster com georreplicação Ativo-Ativo para escritas multirregionais.
Por quê: O acesso na casa dos submilissegundos e a resolução de conflitos baseada em CRDT mantêm as sessões e os contadores consistentes entre as regiões sem um único mestre de escrita.

Deposite os logs de clickstream e operacionais no Azure Data Lake Storage Gen2 com namespaces hierárquicos e ACLs POSIX:

Integração: A ingestão de stream grava em pastas curadas; Databricks e Synapse leem via ABFS; habilitar o feed de alterações e a exclusão reversível (soft delete).
Por quê: ACLs refinadas em nível de diretório/arquivo suportam a governança multiequipe; o namespace hierárquico otimiza as operações de arquivo; a integração nativa com analytics reduz o tempo para obter insights.

Use o Azure Database for PostgreSQL Flexible Server para o microsserviço de recomendação:

HA: Standby síncrono com redundância de zona; provisionar réplicas de leitura para experimentação de funcionalidades.
Por quê: O ecossistema rico de extensões do Postgres e as capacidades JSONB se encaixam no serviço; a alta disponibilidade (HA) gerenciada mantém o RTO baixo; as réplicas descarregam as leituras.

Proteja o acesso com SAS de delegação de usuário para upload temporário de mídia e CMK com escopos de criptografia por locatário (tenant):

Por quê: Elimina a exposição das chaves da conta e permite isolamento criptográfico e auditabilidade por locatário.

Migre os dados de pedidos legados de um SQL Server on-premises para o Azure SQL Managed Instance para processamento de arquivamento e tarefas orientadas por agente:

Passos: Avaliar com o Data Migration Assistant; realizar a migração online via DMS; conectar via ExpressRoute.
Por quê: O MI preserva os trabalhos do SQL Agent e as operações entre bancos de dados, facilitando a modernização enquanto mantém as cargas de trabalho de arquivamento próximas aos dados na nuvem.

Este design atende ao desempenho global por meio das escritas multirregionais do Cosmos DB e do Redis Enterprise, impõe a governança com ACLs do ADLS Gen2 e imutabilidade do Storage, entrega integridade transacional e failover rápido com os níveis e grupos de failover automático do Azure SQL, e otimiza o custo por meio da computação serverless e das políticas de ciclo de vida.

← Identidade · Todos os domínios · Computação e Arquitetura de Aplicações →

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