Laboratório Técnico: Create and Configure Storage Accounts
Questões
Questão 1 — Múltipla Escolha
Uma equipe de dados precisa armazenar arquivos de log com acesso frequente nos primeiros 30 dias e acesso raro após esse período. O custo de armazenamento é uma preocupação central, mas a equipe não quer gerenciar movimentação manual de arquivos.
Qual combinação de tier de acesso padrão e recurso de gerenciamento do ciclo de vida melhor atende a esse requisito?
A) Criar a conta com tier padrão Hot e configurar uma política de lifecycle management para mover blobs para Cool após 30 dias
B) Criar a conta com tier padrão Cool e configurar uma política de lifecycle management para mover blobs para Hot nos primeiros 30 dias
C) Criar a conta com tier padrão Hot e habilitar versioning para controlar automaticamente o custo após 30 dias
D) Criar a conta com tier padrão Archive e configurar uma política de lifecycle management para mover blobs para Hot nos primeiros 30 dias
Questão 2 — Cenário Técnico
Um desenvolvedor executa o seguinte comando para criar uma storage account:
az storage account create \
--name mystorage \
--resource-group rg-prod \
--location eastus \
--sku Standard_LRS \
--kind StorageV2 \
--allow-blob-public-access false
Após a criação, ele tenta acessar um blob via URL pública e recebe erro 403. O gerente afirma que o container foi criado com acesso anônimo habilitado no nível do container.
Qual é a causa correta do erro?
A) O parâmetro --kind StorageV2 não suporta acesso anônimo a blobs
B) O SKU Standard_LRS bloqueia automaticamente qualquer acesso externo
C) O parâmetro --allow-blob-public-access false desabilita o acesso anônimo no nível da conta, tornando irrelevante a configuração do container
D) O container precisa ser recriado com a flag --public-access blob após a criação da conta
Questão 3 — Verdadeiro ou Falso
Uma storage account configurada com redundância GRS (Geo-Redundant Storage) permite que aplicações leiam dados da região secundária a qualquer momento, sem necessidade de failover.
Questão 4 — Cenário Técnico
Uma empresa precisa que apenas recursos dentro de uma VNet específica consigam acessar uma storage account. O administrador configura o firewall da storage account para negar todo tráfego público e adiciona a sub-rede desejada nas regras de rede virtual.
Após a configuração, os recursos na VNet ainda recebem erro de conexão negada.
AuthorizationFailure: This request is not authorized to perform this operation.
Qual é a causa mais provável?
A) O firewall da storage account só funciona com contas do tipo BlobStorage, não com StorageV2
B) O Service Endpoint para Microsoft.Storage não foi habilitado na sub-rede antes de adicioná-la às regras de rede da storage account
C) A regra de VNet exige que a storage account esteja na mesma região que os recursos de computação
D) O acesso por VNet só é suportado quando a redundância está configurada como ZRS ou superior
Questão 5 — Múltipla Escolha
Ao comparar os tipos de conta de armazenamento disponíveis no Azure, qual afirmação descreve corretamente uma diferença funcional relevante entre StorageV2 (General Purpose v2) e BlobStorage?
A) O BlobStorage suporta armazenamento de filas (Queue Storage) e tabelas (Table Storage), enquanto o StorageV2 é restrito a blobs
B) O StorageV2 suporta todos os serviços de armazenamento (Blob, File, Queue, Table), enquanto o BlobStorage suporta apenas blobs, sem suporte a Azure Files
C) O BlobStorage oferece tier de acesso Archive exclusivamente, enquanto o StorageV2 só oferece os tiers Hot e Cool
D) O StorageV2 não suporta lifecycle management policies, sendo necessário usar BlobStorage para esse recurso
Gabarito e Explicações
Gabarito — Questão 1
Resposta: A
A configuração correta é iniciar com o tier Hot para garantir performance nos primeiros 30 dias e usar lifecycle management para mover automaticamente os dados para Cool após esse período. Essa combinação atende ao requisito de custo sem exigir intervenção manual.
- A alternativa B inverte a lógica: definir o padrão como Cool e tentar aquecer os dados automaticamente no início não é o comportamento suportado pelas políticas de lifecycle, que movem blobs para tiers mais frios, não mais quentes.
- A alternativa C confunde versioning com gerenciamento de custo por tier, conceitos completamente distintos.
- A alternativa D é tecnicamente inviável: o tier Archive exige rehidratação (horas a dias) para qualquer leitura, tornando-o inadequado para dados acessados com frequência nos primeiros 30 dias.
Gabarito — Questão 2
Resposta: C
O parâmetro --allow-blob-public-access false atua no nível da conta de armazenamento e funciona como um interruptor global: independentemente de como os containers individuais estiverem configurados, nenhum acesso anônimo será permitido. A configuração do container se torna inoperante nesse cenário.
- A alternativa A é falsa:
StorageV2suporta normalmente acesso anônimo quando habilitado na conta. - A alternativa B é falsa: o SKU define redundância de dados, não políticas de acesso.
- A alternativa D descreve um passo válido em condições normais, mas não resolve o problema enquanto o acesso público estiver desabilitado no nível da conta.
Esse comportamento é relevante em cenários de auditoria e compliance, onde a desabilitação no nível da conta garante proteção mesmo contra configurações incorretas em containers individuais.
Gabarito — Questão 3
Resposta: Falso
O GRS replica os dados de forma assíncrona para uma região secundária, mas essa região é somente leitura apenas após um failover ser iniciado, seja manualmente ou pelo Azure. Para leitura contínua da região secundária sem failover, é necessário usar o RA-GRS (Read-Access Geo-Redundant Storage), que é uma variante distinta.
Confundir GRS com RA-GRS é um equívoco comum que pode resultar em arquiteturas de alta disponibilidade com pressupostos incorretos sobre a disponibilidade de leitura geográfica.
Gabarito — Questão 4
Resposta: B
Para que uma sub-rede possa ser usada nas regras de rede virtual de uma storage account, o Service Endpoint para Microsoft.Storage deve estar habilitado naquela sub-rede. Sem ele, o tráfego da VNet não é reconhecido como originado de dentro da rede virtual pelo plano de controle do Azure Storage, resultando em negação de acesso mesmo com a regra configurada.
- A alternativa A é falsa: StorageV2 é totalmente compatível com regras de VNet.
- A alternativa C é falsa: storage accounts e VNets podem estar em regiões diferentes com Service Endpoint habilitado.
- A alternativa D é falsa: o tipo de redundância não tem relação com a funcionalidade de restrição de rede virtual.
Gabarito — Questão 5
Resposta: B
O StorageV2 (General Purpose v2) é o tipo de conta recomendado pela Microsoft justamente por suportar todos os serviços: Blob, Azure Files, Queue e Table Storage, além de todos os tiers de acesso (Hot, Cool, Archive). O BlobStorage é um tipo legado focado exclusivamente em blobs de bloco e blobs de acréscimo, sem suporte a Azure Files, filas ou tabelas.
- A alternativa A inverte o comportamento: é o BlobStorage que tem escopo reduzido, não o StorageV2.
- A alternativa C é falsa: ambos os tipos suportam os três tiers de acesso (Hot, Cool, Archive) para blobs.
- A alternativa D é falsa: lifecycle management é suportado em StorageV2 e é, inclusive, o cenário mais comum para seu uso.