Microsoft AZ-204: Azure Storage e Blob Storage — Guia de estudos

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

Faz parte do Microsoft Azure Developer Associate AZ-204 — 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 oferece armazenamento em nuvem durável e massivamente escalável para dados não estruturados e estruturados. Para o desenvolvimento de aplicações, foque em selecionar o tipo de conta de armazenamento correto, configurar a redundância para atender aos objetivos de RTO/RPO, escolher o tipo de blob e a camada de acesso adequados para custo/desempenho e proteger o acesso com o Azure AD e SAS. Use políticas de ciclo de vida para automatizar a movimentação de dados entre as camadas, sirva sites estáticos diretamente do Blob storage quando apropriado e aplique o Azure Files e o Queue Storage onde a semântica de arquivos ou o desacoplamento baseado em mensagens forem necessários.

Tipos de conta de armazenamento e fundamentos de redundância

General-purpose v2 (GPv2) é o tipo de conta padrão para a maioria das cargas de trabalho. Ele suporta blobs, arquivos, filas e tabelas, todas as camadas de acesso, gerenciamento do ciclo de vida e os recursos mais recentes. As contas legadas do tipo BlobStorage expõem apenas o serviço de Blob e as camadas de acesso (tiering), mas não possuem a amplitude de recursos e otimizações de custo encontradas no GPv2; novas implementações devem preferir o GPv2. As contas FileStorage são contas premium, baseadas em SSD, dedicadas ao Azure Files, oferecendo IOPS e throughput consistentes e de baixa latência para cargas de trabalho de arquivos empresariais (por exemplo, compartilhamentos de perfil, aplicativos de linha de negócios). Escolha FileStorage quando precisar de desempenho premium para compartilhamentos SMB/NFS; caso contrário, o GPv2 é o padrão.

As opções de redundância determinam a durabilidade e a disponibilidade dos dados entre domínios de falha:

LRS (Locally Redundant Storage) armazena sincronicamente três cópias dentro de um único datacenter. É o menor custo, sem proteção de zona ou regional. Use para dev/test, cargas de trabalho efêmeras ou quando você possui replicação em camadas superiores.
ZRS (Zone-Redundant Storage) replica sincronicamente entre zonas de disponibilidade em uma região, protegendo contra uma interrupção de zona com alta disponibilidade e RPO zero. Escolha para produção em regiões com zonas que exigem resiliência intrarregional.
GRS (Geo-Redundant Storage) armazena três cópias síncronas na região primária (como o LRS) e replica assincronamente para uma região secundária pareada (com LRS lá). O RPO típico é inferior a 15 minutos; a secundária não é legível por padrão. Selecione para recuperação de desastres quando você não precisa de acesso de leitura.
RA-GRS (Read-Access Geo-Redundant Storage) adiciona acesso de leitura à secundária por meio de endpoints -secondary. Use quando você precisa de tolerância a desastres entre regiões e cargas de trabalho principalmente de leitura durante incidentes na primária, ou para leituras com proximidade geográfica onde a consistência eventual é aceitável.

Quando você precisar tanto de proteção contra falhas de zona quanto de DR (recuperação de desastres) entre regiões, considere combinar o ZRS localmente com um padrão adicional de conta geo-replicada no nível da solução. Planeje testes de failover da conta, entenda as trocas de endpoint DNS (flips) e valide as políticas de novas tentativas (retry) da aplicação para lidar com a consistência eventual e o desvio de relógio (clock skew) durante eventos geográficos.

Modelo de dados de blob, camadas e gerenciamento do ciclo de vida

Existem três tipos de blobs com semânticas distintas. Block blobs são otimizados para streaming e leitura aleatória de objetos grandes, como imagens, vídeos e backups. Os uploads são divididos em blocos (chunks) e confirmados (committed), permitindo uploads paralelos e novas tentativas eficientes. Append blobs são otimizados para cargas de trabalho somente de acréscimo (append-only), como captura de telemetria e logs; apenas operações de acréscimo são permitidas, o que simplifica a concorrência. Page blobs expõem páginas alinhadas de 512 bytes para I/O de leitura/escrita aleatória e servem de base para os discos rígidos virtuais do Azure (VHDs) usados pelos discos de VM do Azure; eles são o único tipo de blob suportado para discos IaaS e grandes cargas de trabalho de I/O aleatório.

As camadas de acesso de blob (access tiers) controlam o custo e o desempenho. Hot é otimizada para acesso frequente, com a menor latência de leitura/escrita e o maior custo de armazenamento. Cool visa dados acessados com pouca frequência, retidos por pelo menos 30 dias, com menor custo de armazenamento, mas custos de transação/leitura mais altos e cobranças por retenção mínima. Archive é a camada de menor custo para retenção de longo prazo; os objetos ficam offline e devem ser reidratados para a camada hot ou cool antes da leitura. A reidratação pode ser solicitada com prioridade padrão ou alta, trocando custo por velocidade. Você pode definir uma camada de acesso padrão no nível da conta (hot ou cool) e substituí-la por blob; a camada archive é definida apenas por blob.

As políticas de gerenciamento do ciclo de vida (lifecycle management) automatizam a movimentação e a retenção de dados para controlar custos e atender à governança. No nível da conta, defina regras que:

Transicionam blobs ou versões/snapshots de blobs para a camada cool ou archive após N dias desde a última modificação
Excluem blobs, snapshots ou versões após limites de idade
Filtram por prefixo de contêiner e por tags de índice de blob para atingir conjuntos de dados específicos (por exemplo, tag env=prod e policy=retention-7y)

Combine as regras de ciclo de vida com o versionamento e a exclusão reversível (soft delete) para proteger contra exclusões acidentais, ao mesmo tempo em que impõe a retenção. Lembre-se de que a camada archive tem retenção mínima e cobranças por exclusão antecipada; projete políticas para minimizar reidratações desnecessárias.

Para rastreamento de alterações e processamento downstream, habilite o feed de alterações (change feed) da conta de armazenamento para consumir um log ordenado e imutável de operações de criação, atualização, exclusão e cópia de blobs. Isso suporta conformidade e processadores assíncronos que precisam de semântica exactly-once ou at-least-once com checkpointing.

A hospedagem de site estático no Blob storage expõe um contêiner especial $web servido por meio de um endpoint web dedicado. Configure documentos de índice e de erro e publique os ativos estáticos diretamente. O endpoint do site estático fornece acesso de leitura anônimo ao conteúdo do site, independentemente da configuração de acesso público do blob; o acesso através do endpoint do blob pode permanecer desabilitado. Para domínios personalizados e aceleração global, coloque o Azure Front Door ou o Azure CDN na frente do endpoint. Endpoints privados não são suportados para o endpoint do site estático; use um serviço de borda (edge service) para proteger e acelerar a entrega onde o acesso privado é necessário.

Segurança, identidade e acesso controlado a dados

O Azure Storage criptografa os dados em repouso por padrão com AES de 256 bits usando chaves gerenciadas pela Microsoft. Para um controle mais rigoroso, habilite chaves gerenciadas pelo cliente (CMK) armazenadas no Azure Key Vault ou Managed HSM para governar a rotação de chaves e a separação de responsabilidades; conceda à identidade gerenciada da conta de armazenamento permissões de wrap/unwrap. Para cargas de trabalho altamente regulamentadas, habilite a criptografia de infraestrutura para aplicar uma segunda camada de criptografia independente. Combine a criptografia do lado do servidor com a criptografia do lado do cliente se for necessário um controle criptográfico de ponta a ponta.

A autorização do Azure AD integra o plano de dados com o RBAC para os serviços Blob e Queue e para a API REST do Files. Conceda funções de menor privilégio, como Storage Blob Data Reader ou Storage Blob Data Contributor, a identidades gerenciadas, usuários ou grupos. No código, use DefaultAzureCredential para adquirir tokens OAuth 2.0 e evite incorporar chaves. Para acesso SMB ao Azure Files, habilite a autenticação baseada em identidade usando o Active Directory: associe a conta de armazenamento a um AD DS local (via Azure AD Kerberos para identidades híbridas) ou ao Azure AD DS, e use ACLs NTFS e RBAC (por exemplo, Storage File Data SMB Share Contributor) para autorização no nível do compartilhamento. Garanta o uso do SMB 3.x com criptografia em trânsito e considere o uso de Private Endpoints, VPN ou ExpressRoute para atravessar redes que bloqueiam a porta 445.

As Assinaturas de Acesso Compartilhado (Shared Access Signatures - SAS) delegam acesso com escopo definido e tempo limitado sem expor as chaves da conta. Uma SAS de serviço concede acesso a um serviço e recurso específico (por exemplo, um único blob ou contêiner) com permissões precisas e horários de início/expiração. Uma SAS de conta opera no nível da conta, abrangendo múltiplos serviços (blobs, arquivos, filas, tabelas) e APIs de serviço, como listar ou criar. Uma SAS de delegação de usuário é específica para o Blob storage e é assinada com uma chave de delegação de usuário obtida via Azure AD para uma entidade de segurança com o RBAC apropriado; ela remove a dependência da chave e centraliza o controle de acesso no Azure AD. Aplique restrições, incluindo intervalos de IP, protocolos permitidos (somente HTTPS) e curtos períodos de vida. As políticas de acesso armazenadas centralizam as restrições da SAS e permitem a revogação ao atualizar ou excluir a política; elas se aplicam à SAS de serviço e à SAS de conta. A SAS de delegação de usuário não utiliza políticas de acesso armazenadas; revogue-a expirando a chave de delegação de usuário ou removendo as atribuições de função do Azure AD. Sempre prefira SAS em vez das chaves da conta, e prefira a SAS de delegação de usuário quando seu aplicativo puder adquirir tokens do Azure AD.

Fundamentos do Azure Files e do Queue Storage

O Azure Files oferece compartilhamentos SMB totalmente gerenciados e uma opção NFS para cenários POSIX. Use compartilhamentos SMB para migrações lift-and-shift e compatibilidade de aplicativos. Contas Premium FileStorage entregam desempenho previsível de baixa latência, enquanto compartilhamentos standard são econômicos para dados de arquivo de uso geral. Gerencie compartilhamentos e arquivos por meio de clientes SMB ou da API REST/SDKs. O Azure File Sync habilita serviços de arquivos híbridos ao armazenar em cache um compartilhamento da nuvem em um Windows Server, fornecendo desempenho local e movendo dados frios para a nuvem em camadas (tiering), sincronização multi-site e backup/DR offsite sem os ciclos tradicionais de atualização de NAS. Combine a identidade baseada no Azure AD com ACLs NTFS para impor o menor privilégio e use Private Endpoints para conter o risco de exfiltração de dados.

O Azure Queue Storage permite fluxos de trabalho de aplicativos desacoplados e resilientes. Cada mensagem pode ter até 64 KB (cargas maiores devem referenciar URIs de blob). O tempo de vida (TTL) da mensagem determina a expiração automática; especifique um valor positivo de segundos até sete dias, ou -1 para não expirar. Quando um worker recupera uma mensagem, ela se torna invisível durante seu tempo limite de visibilidade. Se o processamento falhar e a mensagem não for excluída antes do tempo limite, ela reaparece para outro consumidor. Ajuste o tempo limite de visibilidade para exceder o pior caso de tempo de processamento e use manipuladores idempotentes mais recuo exponencial (exponential backoff) para reduzir a contenção. Monitore a contagem de retiradas da fila (dequeue count) para detectar mensagens corrompidas (poison messages); quando ela exceder um limite, mova a mensagem para uma fila dedicada para mensagens corrompidas (poison queue) para quarentena e análise. Os gatilhos de fila do Azure Functions implementam esse padrão automaticamente com uma fila -poison. Para necessidades de maior taxa de transferência ou FIFO com garantias de ordenação, considere as filas do Service Bus; caso contrário, o Azure Queue Storage é leve e de baixo custo.

Cenário de Problema Prático

A National Geographic precisa publicar um microsite de fotografia de alto tráfego com processamento de imagens sem servidor (serverless), armazenamento com custo otimizado e acesso híbrido para uma ferramenta editorial local (on-premises). Eles também exigem links de compartilhamento seguros e com tempo limitado para agências parceiras e manipulação robusta de mensagens para processamento em segundo plano.

Crie uma conta de armazenamento GPv2 com RA-GRS

Por quê: O GPv2 desbloqueia os serviços Blob, Files e Queue com recursos de ciclo de vida e tiering. O RA-GRS fornece tolerância a desastres entre regiões e acesso de leitura a endpoints secundários para continuidade de ativos de leitura predominante durante incidentes regionais.

Habilite a hospedagem de site estático e implante os ativos do site no contêiner $web

Por quê: Sites estáticos no Blob eliminam o gerenciamento de servidores web, entregam leituras de baixa latência a partir do nível Hot e escalam globalmente. Combine posteriormente com o Azure Front Door para domínios personalizados, WAF e cache de borda.

Armazene imagens RAW originais como block blobs; telemetria de gravação única como append blobs

Por quê: Block blobs suportam uploads grandes e paralelos e a entrega eficiente de derivados otimizados para a web. Append blobs simplificam escritas de log concorrentes de pipelines de processamento sem conflitos.

Defina políticas de ciclo de vida para mover os originais para o nível Cool após 30 dias e para o Archive após 180 dias; exclua versões com mais de um ano

Por quê: O tiering automatizado reduz o custo de armazenamento com base nos padrões de acesso, ao mesmo tempo que retém cópias para conformidade. A limpeza de versões e snapshots controla o inchaço sem intervenção manual.

Proteja o acesso aos dados com o Azure AD e SAS de delegação de usuário para parceiros

Por quê: Atribua a função Storage Blob Data Reader a uma identidade gerenciada no serviço de compartilhamento, obtenha chaves de delegação de usuário e crie tokens SAS de curta duração, somente HTTPS, com restrições de IP. Isso evita a distribuição de chaves de conta e vincula a autorização ao Azure AD.

Habilite chaves gerenciadas pelo cliente (CMK) com o Key Vault e criptografia de infraestrutura

Por quê: O CMK satisfaz requisitos mais rigorosos de conformidade e rotação, enquanto a criptografia dupla fornece defesa em profundidade para mídias sensíveis.

Integre o Azure Queue Storage para processamento de imagens em segundo plano com um gatilho de fila do Azure Functions; defina o tempo limite de visibilidade para exceder o tempo máximo de processamento e configure o tratamento de mensagens corrompidas

Por quê: As filas desacoplam o caminho de upload da computação. O tempo limite de visibilidade evita trabalho duplicado, e o runtime do Functions roteia itens com falha para uma fila -poison automaticamente para investigação.

Publique ferramentas editoriais via Azure Files usando uma conta Premium FileStorage e o Azure File Sync em um Windows Server local (on-premises)

Por quê: Os editores obtêm acesso SMB de baixa latência com ACLs NTFS e autenticação baseada em identidade através do AD, enquanto o Azure File Sync fornece cache local e tiering na nuvem. O nível premium garante desempenho consistente para cargas de trabalho interativas.

Posicione o Azure Front Door na frente do site estático e habilite cache e HTTPS personalizado

Por quê: Os POPs de borda reduzem a latência globalmente, domínios personalizados atendem aos requisitos de marca e o WAF adiciona segurança sem alterar o backend de armazenamento.