Microsoft AZ-104: Armazenamento do Azure — 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

O Azure Storage sustenta os serviços de dados em todo o Azure, oferecendo armazenamento de objetos e arquivos durável e de alta disponibilidade com segurança granular e rede flexível. O domínio do serviço exige a compreensão dos tipos de conta e redundância, do ciclo de vida e proteção de dados para blobs, das opções de compartilhamento de arquivos e sincronização, da autenticação forte e do acesso controlado à rede, e das ferramentas operacionais para transferência em massa e administração.

Tipos de conta de armazenamento e durabilidade

As contas de uso geral v2 (GPv2) são a escolha padrão e recomendada para a maioria dos cenários. Elas suportam blobs (incluindo o namespace hierárquico do Data Lake Storage Gen2 quando habilitado), arquivos, filas e tabelas, nos níveis de desempenho standard (com base em HDD) e premium (com base em SSD) (premium para blobs de bloco, blobs de página ou compartilhamentos de arquivos, dependendo do subtipo). As contas BlobStorage são contas legadas, exclusivas para blobs e com recursos limitados; elas persistem principalmente para fins de retrocompatibilidade. As contas FileStorage são contas premium especializadas para o Azure Files, fornecendo IOPS e throughput provisionados e previsíveis com baixa latência, e suportando tanto SMB quanto NFS 4.1.

As opções de redundância equilibram durabilidade, disponibilidade e custo:

O LRS armazena três cópias síncronas em um único datacenter, adequado para resiliência intrazona, mas não para falhas de zona ou regionais.
O ZRS armazena três cópias síncronas em zonas de disponibilidade distintas dentro de uma região, protegendo contra uma interrupção de zona enquanto mantém a disponibilidade de leitura/escrita.
O GRS armazena três cópias síncronas localmente (LRS) mais três cópias assíncronas para uma região secundária emparelhada. A secundária não é legível até que ocorra um failover.
O RA-GRS é o GRS com acesso de leitura ao endpoint secundário, permitindo que cargas de trabalho de leitura intensiva continuem durante uma interrupção na primária. Esta é a opção correta quando os dados precisam ser legíveis na secundária o tempo todo.
O GZRS combina o ZRS na região primária com replicação assíncrona para uma região secundária (LRS). Oferece tolerância a falhas de zona e recuperação de desastres regional.
O RA-GZRS adiciona acesso de leitura à secundária para o GZRS.

Escolha RA-GRS ou RA-GZRS quando leituras entre regiões forem necessárias, GRS/GZRS para DR entre regiões sem acesso de leitura, ZRS para resiliência em nível de zona com a menor latência de escrita, e LRS para durabilidade otimizada em custo sem cobertura de zona/região.

Gerenciamento, camadas e proteção de dados de blob

As camadas de acesso a blobs (access tiers) otimizam o custo alinhando o preço do armazenamento com os padrões de acesso. A camada Hot oferece a menor latência de acesso e transação por GB, recomendada para dados acessados com frequência. A camada Cool reduz o custo de armazenamento com cobranças mais altas de acesso e exclusão antecipada; use para dados lidos com pouca frequência (horizonte de pelo menos 30 dias). A camada Archive é offline e tem o menor custo por GB, com latência de reidratação de horas e cobranças de retenção mínima; é ideal para conformidade ou backup de longo prazo. As camadas podem ser definidas por blob; uma camada de acesso padrão pode ser aplicada no nível da conta ou do contêiner para novos objetos.

As políticas de gerenciamento do ciclo de vida (lifecycle management) automatizam a classificação em camadas (tiering) e a retenção. As regras são avaliadas diariamente e podem filtrar por prefixo, tipo de blob, hora da última modificação e tags de índice de blob. As ações incluem mover de Hot para Cool, de Cool para Archive, reidratar (em condições limitadas) e excluir blobs base, snapshots ou versões após uma idade especificada. Políticas baseadas na hora do último acesso podem refinar ainda mais as transições. Regras bem projetadas convertem o custo da supervisão manual para a governança orientada por políticas, garantindo ao mesmo tempo as janelas de retenção para conformidade.

Os recursos de proteção de dados devem ser habilitados deliberadamente:

A exclusão reversível de blobs (soft delete) preserva blobs excluídos ou sobrescritos por uma janela de retenção, permitindo a recuperação sem restaurar de um backup. Aplica-se a blobs base e pode ser estendida a snapshots e versões.
O versionamento mantém uma versão somente leitura a cada sobrescrita ou exclusão, oferecendo recuperação pontual por objeto e permitindo concorrência segura para a aplicação.
A exclusão reversível de contêineres (container soft delete) protege os contêineres contra exclusão acidental, retendo-os por um período configurado, o que permite a restauração do contêiner e de seu conteúdo.
A restauração pontual (point-in-time restore) para contêineres permite restaurar um ou mais contêineres para um carimbo de data/hora anterior dentro de um período de retenção. Requer o versionamento de blobs e o feed de alterações (change feed), e é especialmente valioso para a recuperação de corrupção lógica em grande escala, reconstruindo o estado para um ponto consistente entre muitos objetos.

Os snapshots para blobs de bloco fornecem pontos de recuperação ad hoc adicionais, mas são substituídos pelo versionamento na maioria dos projetos operacionais. Garanta que as políticas de ciclo de vida e os requisitos de retenção legal/imutabilidade (legal hold/immutability) não entrem em conflito, especialmente ao combinar a classificação em camadas Archive e a retenção WORM.

Azure Files e Azure File Sync

O Azure Files oferece compartilhamentos de arquivos totalmente gerenciados com a elasticidade nativa do Azure e disponibilidade global. Os compartilhamentos SMB suportam recursos do SMB 3.x, como criptografia em trânsito, disponibilidade contínua em compartilhamentos premium do tipo FileStorage em determinados cenários e controle de acesso baseado em identidade. Os compartilhamentos NFS 4.1 estão disponíveis apenas em contas premium do tipo FileStorage, otimizados para cargas de trabalho UNIX/Linux; eles usam permissões POSIX e políticas de exportação, com o acesso restrito a redes selecionadas por segurança.

A autenticação baseada em identidade para SMB oferece múltiplas opções:

Autenticação com Active Directory Domain Services (AD DS), usando um controlador de domínio hospedado no local (on-premises) ou em IaaS do Azure, com suporte a ACLs NTFS e Kerberos/NTLM.
Azure AD Domain Services (Azure AD DS), fornecendo um domínio gerenciado sem a necessidade de gerenciar VMs de controlador de domínio.
Azure AD Kerberos para Azure Files, habilitando uma identidade moderna e exclusivamente na nuvem para acesso SMB a partir de clientes Windows ingressados no Azure AD e do Windows Server 2022, eliminando a necessidade de controladores de domínio tradicionais, mas preservando a semântica do Kerberos e das ACLs. Integra-se com o RBAC e permissões em nível de compartilhamento para alinhar a autorização de armazenamento com a governança de identidade.

O Azure File Sync estende o Azure Files para servidores Windows locais (on-premises), convertendo seu compartilhamento de arquivos do Azure em um hub para sincronização multi-site com armazenamento centralizado na nuvem. Um recurso de Storage Sync Service orquestra a replicação. Dentro dele, os grupos de sincronização (sync groups) vinculam:

Um ponto de extremidade na nuvem (cloud endpoint), que referencia um compartilhamento de arquivos do Azure em uma conta de armazenamento.
Um ou mais pontos de extremidade do servidor (server endpoints), cada um mapeando um caminho em um volume de um Windows Server registrado.

Após instalar o agente do Azure File Sync e registrar o servidor, adicione o caminho do ponto de extremidade do servidor (por exemplo, D:\Shares\Projects). O tiering na nuvem (cloud tiering) pode ser habilitado para manter o namespace localmente enquanto os arquivos frios (cold files) são substituídos por stubs; as políticas incluem metas de espaço livre no volume e remoção baseada no calor do último acesso. A recuperação sob demanda (on-demand recall) restaura o conteúdo do arquivo de forma transparente no momento do acesso. Estratégias de propagação inicial (initial seed) e recuperação (recall), integração com DFS-N para referências e exclusões de antivírus para os diretórios de sistema do AFS são considerações operacionais essenciais. A enumeração de alterações e a sincronização baseada em journal minimizam a rotatividade (churn); o controle de fluxo (throttling) e a propagação de dados offline podem proteger a largura de banda durante a replicação inicial.

Segurança, rede e acesso controlado

As assinaturas de acesso compartilhado (Shared Access Signatures - SAS) concedem acesso com escopo definido e tempo limitado sem expor as chaves da conta. Uma SAS de serviço (Service SAS) destina-se a um recurso específico (blob, contêiner, compartilhamento de arquivos, fila, tabela) com permissões definidas, horários de início/expiração, intervalos de IP permitidos, protocolos e nomes de objeto pré-autorizados. Uma SAS de conta (Account SAS) abrange múltiplos serviços e tipos de recursos dentro da conta, mas não pode ser vinculada a uma política de acesso armazenada; deve ser usada com moderação devido ao seu escopo mais amplo. A SAS de delegação de usuário (User delegation SAS) é o padrão recomendado para o serviço de Blob ao usar o Azure AD; ela é assinada com uma chave de delegação de usuário de curta duração obtida via Azure AD, produzindo um token auditável e de privilégio mínimo. As políticas de acesso armazenadas (stored access policies) são anexadas a contêineres ou compartilhamentos e permitem a revogação centralizada e atualizações de permissão/tempo para múltiplos tokens SAS emitidos, modificando ou excluindo a política.

A autorização do Azure AD integra-se com Blob e Queue, e com o Azure Files através dos modelos SMB baseados em AD descritos anteriormente. Para Blob e Queue, atribua funções do Azure RBAC, como Storage Blob Data Reader, Contributor ou Owner, no escopo da conta, do contêiner ou do grupo de recursos. O acesso de aplicativos deve preferir identidades gerenciadas (managed identities) e OAuth em vez de chaves de conta, reduzindo o risco de distribuição de chaves e permitindo o acesso condicional (conditional access) e o Privileged Identity Management em escala.

O firewall de armazenamento impõe restrições de origem de rede quando configurado para Redes selecionadas (Selected networks):

Regras de rede virtual (Virtual network rules) concedem acesso a sub-redes específicas que têm pontos de extremidade de serviço (service endpoints) Microsoft.Storage habilitados, ou usam pontos de extremidade privados (private endpoints) para acesso privado por recurso via IP privado em sua VNet. Os pontos de extremidade de serviço são mais simples de configurar e preservam os pontos de extremidade públicos; os pontos de extremidade privados fornecem o isolamento e o controle de saída (egress) mais fortes.
Regras de rede IP (IP network rules) permitem endereços IPv4 públicos ou intervalos CIDR para clientes locais (on-premises) ou da internet; use isso para acesso administrativo com escopo restrito.
Regras de instância de recurso (Resource instance rules) permitem que instâncias de serviços confiáveis do Azure (por exemplo, um workspace do Synapse ou um Logic App específico) acessem a conta de armazenamento sem exceções amplas de “permitir serviços confiáveis da Microsoft”, especificando o ID do recurso e o tipo de serviço suportado, ajudando a manter o privilégio mínimo.

Habilite o TLS 1.2+, exija transferência segura, rotacione as chaves da conta e audite usando as configurações de diagnóstico do Storage Analytics e do Azure Monitor. Combine as regras de rede com o Azure AD RBAC e a higiene de SAS para uma postura de defesa em profundidade.

← Balanceamento de Carga do Azure e Gerenciamento de Tráfego · Todos os domínios · Azure App Service e Computação PaaS →

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