Microsoft AZ-900: Armazenamento e Bancos de Dados — Guia de estudos

By Laurynas Brazys · 23 July 2026 · #microsoft #az-900 #certification #exam-prep #study-guide

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

O Azure fornece uma base ampla para armazenar dados estruturados e não estruturados em escala global, com durabilidade, segurança e controles de custo integrados. Compreender o primitivo de armazenamento, o modelo de redundância, a camada de acesso e o serviço de banco de dados corretos desbloqueia aplicações confiáveis e de alto desempenho, desde máquinas virtuais até plataformas web e móveis distribuídas globalmente.

Serviços do Azure Storage e managed disks

O Azure Blob Storage é a base para dados não estruturados. Os block blobs lidam com objetos grandes com streaming eficiente e upload paralelo, snapshots, versionamento e tiering. Os page blobs são otimizados para E/S de leitura/gravação aleatória em páginas de 512 bytes e servem de base para discos rígidos virtuais; eles estão por trás dos discos e de cenários que exigem IOPS consistentes de baixa latência. Os append blobs são projetados para cenários de anexação com uso intensivo de gravação, como logs de aplicação, onde novos blocos são adicionados eficientemente ao final. O Azure Files oferece compartilhamentos de arquivos totalmente gerenciados, acessíveis via SMB ou NFS com ACLs NTFS, opções de integração de diretório e o Azure File Sync para armazenar em cache dados quentes em Windows Servers. O Queue Storage fornece um sistema de mensagens de aplicação leve e durável para desacoplar componentes com semântica de entrega at-least-once. O Table Storage fornece um armazenamento de chave/atributo sem esquema (schemaless) para conjuntos de dados vastos e particionados, onde você controla as chaves de partição e de linha para obter escalabilidade e eficiência de custo. Os managed disks fornecem armazenamento em bloco durável e persistente para Azure Virtual Machines sem a necessidade de gerenciar contas de armazenamento ou page blobs diretamente. Escolha entre Standard HDD para cargas de trabalho de taxa de transferência otimizadas para custo, Standard SSD para desempenho balanceado, Premium SSD e Premium SSD v2 para IOPS altos e de baixa latência, e Ultra Disk para as cargas de trabalho transacionais mais exigentes com IOPS e taxa de transferência configuráveis. Os managed disks suportam snapshots, backups incrementais, criptografia de disco e opções de disponibilidade alinhadas aos SLAs de sua VM.

Blob – Block blob
- Modelo de dados ou padrão de E/S: Objeto grande, E/S sequencial
- Principais capacidades: Tiering, snapshots, versionamento, políticas de ciclo de vida
- Casos de uso típicos: Imagens, vídeo, backups, landing zones de big data
- Limites/notas importantes: Blob único de até ~190 TiB; não otimizado para E/S aleatória
Blob – Page blob
- Modelo de dados ou padrão de E/S: E/S aleatória em páginas de 512 bytes
- Principais capacidades: Leituras/gravações de baixa latência, base para VHDs
- Casos de uso típicos: Armazenamento subjacente para discos e cenários que precisam de acesso aleatório
- Limites/notas importantes: Tamanho do page blob de até 8 TiB; os managed disks abstraem isso
Blob – Append blob
- Modelo de dados ou padrão de E/S: Gravações somente de anexação (append-only)
- Principais capacidades: Anexações de log eficientes, opções de imutabilidade
- Casos de uso típicos: Telemetria e logs de aplicação
- Limites/notas importantes: Atualização no local (in-place) não suportada; aplicam-se limites de contagem de blocos
Azure Files
- Modelo de dados ou padrão de E/S: Semântica de arquivo POSIX/SMB/NFS
- Principais capacidades: Acesso SMB/NFS, ACLs NTFS, integração com AD DS/Azure AD DS, File Sync
- Casos de uso típicos: Compartilhamentos de arquivos “lift-and-shift”, configuração de aplicações, diretórios home de usuários
- Limites/notas importantes: Tiers Standard e Premium; compartilhamentos de arquivos grandes de até 100 TiB
Queue Storage
- Modelo de dados ou padrão de E/S: Fila de mensagens
- Principais capacidades: Entrega at-least-once, timeouts de visibilidade, tratamento de poison messages
- Casos de uso típicos: Processamento em segundo plano, microsserviços desacoplados
- Limites/notas importantes: Tamanho da mensagem de até 64 KB (use o Service Bus para padrões maiores/avançados)
Table Storage
- Modelo de dados ou padrão de E/S: NoSQL de chave/atributo
- Principais capacidades: Escala massiva, particionamento por PartitionKey, baixo custo
- Casos de uso típicos: Telemetria, catálogos, perfis de usuário
- Limites/notas importantes: Sem joins ou índices secundários; use a API de Tabela do Cosmos DB para necessidades globais
Managed disks
- Modelo de dados ou padrão de E/S: Armazenamento em bloco para VMs
- Principais capacidades: SKUs Standard/Premium/Ultra, snapshots, escalonamento, criptografia de disco
- Casos de uso típicos: Discos de SO/dados para VMs, bancos de dados, aplicações de linha de negócio (LOB)
- Limites/notas importantes: Até 32 TiB por disco; ZRS disponível para SKUs selecionados

Opções de redundância e durabilidade

Os modelos de redundância definem onde e quantas réplicas síncronas e assíncronas o Azure mantém para seus dados. O armazenamento com redundância local (LRS) mantém três cópias em um único datacenter em uma região, protegendo contra falhas de disco e de rack com o menor custo. O armazenamento com redundância de zona (ZRS) distribui três cópias síncronas por zonas de disponibilidade separadas em uma região, fornecendo resiliência a uma interrupção de zona sem failover da aplicação. O armazenamento com redundância geográfica (GRS) estende o LRS replicando assincronamente seus dados para a região emparelhada, resultando em seis cópias no total em duas regiões; depois que a Microsoft inicia o failover da conta, a secundária se torna a nova primária. O armazenamento com redundância geográfica e acesso de leitura (RA-GRS) adiciona um endpoint secundário ativo e somente leitura para que as aplicações possam ler da região secundária mesmo antes do failover, permitindo a distribuição global de leitura e o descarregamento de análises (analytics offloading). O armazenamento com redundância geozonal (GZRS) combina o ZRS na região primária com a replicação assíncrona para o LRS na região emparelhada, protegendo contra falhas de zona e regionais; uma variante com acesso de leitura (RA-GZRS) fornece endpoints de leitura na secundária. A seleção é orientada por objetivos de recuperação, expectativas de latência e orçamento. Dentro de uma região, o ZRS protege contra falhas de zona, mantendo baixa a latência de gravação. Entre regiões, GRS/RA-GRS e GZRS são preferidos para recuperação de desastres e cenários de leitura entre regiões. A consistência dos dados na região secundária é assíncrona por design nas opções geográficas, portanto, as aplicações devem tolerar a consistência eventual até que um failover seja concluído.

LRS
- Layout de replicação: 3 cópias em um único datacenter (região)
- Acesso de leitura à secundária: Não
- Tolerância regional/de zona: Protege contra falhas locais de hardware/rack
- Cargas de trabalho comuns: Dev/test, armazenamento de baixo custo, dados não críticos
ZRS
- Layout de replicação: 3 cópias sincronicamente em 3 zonas de disponibilidade (região)
- Acesso de leitura à secundária: Não
- Tolerância regional/de zona: Sobrevive a interrupções de zona sem failover no nível da aplicação
- Cargas de trabalho comuns: Conteúdo de produção web/app que necessita de alta disponibilidade regional
GRS
- Layout de replicação: LRS na primária + LRS assíncrono na região emparelhada (total ~6 cópias)
- Acesso de leitura à secundária: Não
- Tolerância regional/de zona: DR regional via failover da conta; sem proteção de zona na primária
- Cargas de trabalho comuns: Backup/arquivamento com postura de DR regional
RA-GRS
- Layout de replicação: GRS + endpoint de leitura na região secundária
- Acesso de leitura à secundária: Sim
- Tolerância regional/de zona: O mesmo que GRS; permite distribuição global de leitura
- Cargas de trabalho comuns: Leituras de conteúdo global, descarregamento de análises/relatórios na secundária
GZRS
- Layout de replicação: ZRS na primária + LRS assíncrono na região emparelhada
- Acesso de leitura à secundária: Não (use RA-GZRS)
- Tolerância regional/de zona: Protege contra falhas de zona e desastres regionais
- Cargas de trabalho comuns: Aplicações de missão crítica que exigem resiliência de zona + geográfica

Camadas de acesso e gerenciamento do ciclo de vida

As camadas de acesso de blob alinham o custo de armazenamento com os padrões de acesso. A camada Hot é otimizada para acesso frequente, com os menores custos de transação de leitura e gravação e um preço de armazenamento por GB mais alto. A camada Cool reduz o preço de armazenamento por GB e aumenta os custos de transação e de exclusão antecipada, tornando-a adequada para conjuntos de dados acessados com pouca frequência, como relatórios mensais ou backups de curto prazo. A camada Archive oferece o menor custo de armazenamento, mas exige reidratação antes do acesso, com as mais altas taxas de acesso e de exclusão antecipada; ela é projetada para cenários de retenção de longo prazo e conformidade (compliance). As políticas de gerenciamento do ciclo de vida automatizam a organização em camadas (tiering) e a retenção no nível do contêiner ou da conta. As regras podem mover blobs entre as camadas Hot, Cool e Archive com base na data da última modificação, na data do último acesso ou em tags de índice de blob; e excluir versões, snapshots ou blobs base após uma idade definida. As políticas ajudam a reduzir o custo total de propriedade (TCO) movendo dados frios para fora do armazenamento Hot e descartando dados obsoletos sem intervenção manual. O gerenciamento do ciclo de vida está disponível para contas de armazenamento de uso geral v2 e de Blob e opera em blobs de bloco e de acréscimo; não é aplicável ao armazenamento de blobs de bloco premium. A reidratação do Archive suporta opções de prioridade padrão e alta, trocando custo por velocidade. Planeje janelas de recuperação medidas em horas para a reidratação padrão e de minutos a horas para a de alta prioridade em objetos menores. Para conformidade, combine o Archive com políticas de imutabilidade (retenção baseada em tempo ou retenção legal) para impor garantias de write-once, read-many (WORM) no nível do contêiner ou do blob.

Hot
- Custo de armazenamento: Mais alto
- Custo de acesso/transação: Mais baixo
- Retenção mínima: Nenhuma
- Latência de recuperação: Milissegundos (online)
- Dados típicos: Conteúdo ativo, dados lidos/gravados com frequência
Cool
- Custo de armazenamento: Menor que o Hot
- Custo de acesso/transação: Maior que o Hot; aplica-se taxa de exclusão antecipada
- Retenção mínima: 30 dias
- Latência de recuperação: Milissegundos (online)
- Dados típicos: Dados acessados com pouca frequência, backups de curto prazo
Archive
- Custo de armazenamento: Mais baixo
- Custo de acesso/transação: Mais alto; aplica-se taxa de exclusão antecipada
- Retenção mínima: 180 dias
- Latência de recuperação: Horas (reidratação necessária)
- Dados típicos: Retenção de longo prazo, arquivos de conformidade, backups raramente acessados

Segurança, criptografia e controle de acesso

A criptografia em repouso é habilitada por padrão via Storage Service Encryption (SSE). Por padrão, chaves gerenciadas pela Microsoft protegem os dados de forma transparente. Para um controle mais rigoroso e separação de funções, chaves gerenciadas pelo cliente (CMK) podem ser configuradas por conta de armazenamento usando chaves no Azure Key Vault ou em um Managed HSM, com suporte a fluxos de trabalho de rotação e revogação de chaves. Para cargas de trabalho sensíveis, as opções de criptografia dupla e computação confidencial reduzem ainda mais os riscos de exposição de dados. Em trânsito, imponha o uso de HTTPS com TLS para todas as operações do plano de dados. O controle de acesso abrange autorização baseada em identidade e tokens com escopo definido. O Azure RBAC se integra com o Microsoft Entra ID para conceder acesso de privilégio mínimo ao plano de dados, como as funções de Storage Blob Data Reader/Contributor, a usuários, grupos e identidades gerenciadas. O RBAC elimina segredos compartilhados e oferece suporte a acesso condicional, Privileged Identity Management e auditoria. As Shared Access Signatures (SAS) delegam acesso com tempo e permissões limitados a clientes que podem não ter uma identidade; as SAS podem ser assinadas com chaves da conta ou com delegação de usuário usando credenciais do Microsoft Entra para evitar a exposição das chaves da conta. Combine o RBAC para acesso de serviço a serviço e administrativo com SAS para fluxos de acesso temporário de clientes. Proteja as chaves da conta e rotacione-as regularmente; prefira SAS de delegação de usuário sempre que possível. O isolamento de rede com Private Endpoints ou service endpoints, regras de firewall e políticas de armazenamento imutável completam uma postura de defesa em profundidade para as contas de armazenamento.

Azure RBAC (Microsoft Entra ID)
- Escopo: Funções baseadas em identidade no plano de dados e no plano de gerenciamento do armazenamento
- Ideal para: Administradores, serviços e aplicativos com identidades gerenciadas
- Propriedades principais: Privilégio mínimo, acesso condicional, auditabilidade, sem segredos compartilhados
- Considerações de risco: Requer integração de identidade; a revogação é feita por meio de alterações de função
Shared Access Signature (SAS)
- Escopo: Tokens com tempo e permissões limitados em recursos específicos
- Ideal para: Delegar acesso limitado a clientes/parceiros
- Propriedades principais: Permissões granulares, restrições de IP/tempo; SAS de delegação de usuário evita o uso de chaves da conta
- Considerações de risco: O vazamento de tokens concede acesso até a expiração; proteja a distribuição e defina tempos de vida curtos

PaaS relacional e NoSQL distribuído globalmente

O Azure SQL Database oferece um mecanismo relacional gerenciado com aplicação automática de patches, alta disponibilidade integrada, backups e escalonamento. Implante bancos de dados únicos ou pools elásticos para consolidar cargas de trabalho variáveis. O serviço mantém múltiplas réplicas dentro de uma região e suporta redundância de zona; a Transparent Data Encryption (TDE) é ativada por padrão. Backups automatizados permitem a restauração point-in-time (PITR), geralmente por 7 a 35 dias, com retenção de longo prazo opcional de até anos no armazenamento do Azure. Para resiliência multirregional e leituras de baixa latência, use a replicação geográfica ativa (até quatro secundários legíveis) ou grupos de Auto-failover para DR coordenado em escala. O Azure SQL Managed Instance oferece quase 100% de compatibilidade com o mecanismo do SQL Server para recursos no nível da instância, como SQL Agent, consultas entre bancos de dados, Service Broker e CLR, permitindo uma modernização direta do ambiente on-premises sem refatoração. Ele compartilha a mesma arquitetura de HA gerenciada, aplicação de patches online, backups automatizados, TDE por padrão e suporta grupos de auto-failover entre regiões. O isolamento de rede com private endpoints e o escalonamento de computação/armazenamento por banco de dados ou por instância fornecem envelopes de desempenho previsíveis. O Azure Cosmos DB fornece um banco de dados NoSQL multimodelo totalmente gerenciado com distribuição global turnkey e gravações multirregionais. Ele garante latências de milissegundos de um dígito no percentil 99 dentro de uma região e oferece cinco níveis de consistência ajustáveis para equilibrar desempenho e correção entre as regiões. Provisione a taxa de transferência (throughput) em RU/s ou use o autoescalonamento, adicione ou remova regiões sem tempo de inatividade e configure o failover automático. As APIs incluem Core (SQL), MongoDB, Cassandra, Gremlin e Table, simplificando a migração e a integração em diversas pilhas de aplicativos.

Azure SQL Database
- Modelo: PaaS relacional (banco de dados único/pool elástico)
- Compatibilidade: Recursos mais recentes do SQL; compatibilidade no nível do aplicativo
- HA/DR: Réplicas integradas, redundância de zona; replicação geográfica ativa; grupos de Auto-failover
- Backups/TDE: PITR automático de 7 a 35 dias; LTR de até anos; TDE ativado por padrão
- Opções geográficas: Secundários legíveis entre regiões; grupos de failover coordenados
- Mais adequado para: Aplicativos SaaS/multilocatário, novas cargas de trabalho relacionais nativas da nuvem
Azure SQL Managed Instance
- Modelo: PaaS relacional (instância)
- Compatibilidade: Alta paridade de recursos com o SQL Server, incl. SQL Agent, cross-DB
- HA/DR: HA integrado; redundância de zona; grupos de Auto-failover
- Backups/TDE: PITR automático de 7 a 35 dias; LTR; TDE ativado por padrão; suporte a restauração nativa
- Opções geográficas: Multirregional com grupos de failover e secundários legíveis
- Mais adequado para: Lift-and-shift de SQL on-prem com alterações mínimas
Azure Cosmos DB
- Modelo: NoSQL, multimodelo (Core, MongoDB, Cassandra, Gremlin, Table)
- Compatibilidade: Compatibilidade no nível da API para pilhas NoSQL populares
- HA/DR: Gravações multirregionais e multimestre; SLAs de 99,99%
- Backups/TDE: Opções de backup automatizado e contínuo; criptografia em repouso
- Opções geográficas: Adicionar/remover regiões em tempo real; consistência ajustável; failover automático
- Mais adequado para: Aplicativos globais de baixa latência, IoT, catálogos, personalização