Laboratório de Troubleshooting: Create and Configure Storage Accounts
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de operações relata que uma aplicação web hospedada em uma VM no Azure começou a receber erros ao tentar gravar arquivos em uma storage account. A aplicação funcionava normalmente até ontem.
O administrador verifica o seguinte no portal:
- A storage account está na região East US, tipo StorageV2, SKU Standard_LRS
- A VM está na mesma região e na sub-rede
snet-appda VNetvnet-prod - O firewall da storage account está configurado para negar todo acesso público
- A sub-rede
snet-appestá listada nas regras de rede virtual da storage account - O blob versioning foi habilitado ontem à tarde pelo time de segurança
Os logs da aplicação mostram:
[ERROR] StorageException: This request is not authorized to perform this operation.
Status: 403 Forbidden
RequestId: 7e3a1b92-...
Time: 2026-03-26T14:33:01Z
O administrador também confirma que a conta de serviço usada pela aplicação possui a role Storage Blob Data Contributor atribuída corretamente.
Qual é a causa raiz do erro 403?
A) A role Storage Blob Data Contributor não é suficiente para gravar em uma storage account com firewall habilitado
B) O blob versioning habilitado ontem alterou o comportamento de escrita e exige permissões adicionais
C) O Service Endpoint para Microsoft.Storage não está habilitado na sub-rede snet-app, tornando a regra de VNet inoperante
D) O SKU Standard_LRS não é compatível com regras de rede virtual quando o acesso público está desabilitado
Cenário 2 — Decisão de Ação
A causa do problema foi identificada: uma storage account crítica de produção tem a configuração de redundância alterada de GRS para LRS por engano, expondo os dados a risco de perda em caso de falha regional. A alteração foi feita há 15 minutos por um administrador que operou na subscription errada.
O ambiente tem as seguintes restrições:
- A storage account está ativa e sendo utilizada por duas aplicações em produção neste momento
- Nenhuma janela de manutenção está agendada para hoje
- A replicação para a região secundária já foi interrompida no momento da mudança para LRS
- O administrador responsável tem a role Contributor na subscription
Qual é a ação correta a tomar neste momento?
A) Criar uma nova storage account com GRS, copiar os dados via AzCopy e redirecionar as aplicações após a cópia
B) Alterar a redundância de volta para GRS diretamente nas configurações da storage account, sem necessidade de interromper as aplicações
C) Iniciar um failover manual para a região secundária para restaurar a redundância geográfica imediatamente
D) Abrir um ticket de suporte para a Microsoft restaurar o estado anterior da storage account antes de tomar qualquer ação
Cenário 3 — Causa Raiz
Um desenvolvedor criou uma storage account e um container chamado uploads com acesso anônimo configurado como Blob no nível do container. Ele tenta acessar um blob via URL direta no navegador e recebe o seguinte erro:
<Error>
<Code>PublicAccessNotPermitted</Code>
<Message>Public access is not permitted on this storage account.</Message>
<RequestId>a91f2c03-...</RequestId>
</Error>
O desenvolvedor verifica o container no portal e confirma que a opção Anonymous access level está definida como Blob. Ele também confirma que a storage account foi criada há duas horas com as configurações padrão do portal, sem modificações manuais adicionais.
Outras informações coletadas:
- A storage account é do tipo StorageV2
- O SKU é Standard_GRS
- Nenhuma Azure Policy foi identificada como aplicável no resource group
- O time de segurança habilitou Microsoft Defender for Storage na subscription ontem
Qual é a causa raiz do erro?
A) O SKU Standard_GRS bloqueia acesso anônimo a blobs por replicar dados para uma segunda região
B) O Microsoft Defender for Storage bloqueia automaticamente o acesso anônimo quando ativado na subscription
C) O portal do Azure passou a criar storage accounts com acesso público bloqueado por padrão no nível da conta, e essa configuração não foi alterada
D) O acesso anônimo do tipo Blob só funciona quando o container é criado antes da storage account ser totalmente provisionada
Cenário 4 — Sequência de Diagnóstico
Um administrador recebe um alerta indicando que uma aplicação não consegue acessar arquivos em uma storage account configurada com firewall e regras de rede virtual. O acesso era funcional até o dia anterior.
Os passos de investigação disponíveis são:
- Verificar se o Service Endpoint para
Microsoft.Storageestá habilitado na sub-rede da aplicação - Confirmar se o endereço IP ou a sub-rede da aplicação está listado nas regras permitidas do firewall da storage account
- Testar o acesso usando Storage Explorer com credenciais de administrador para isolar se o problema é de rede ou de permissão
- Verificar se houve alterações recentes nas configurações de rede da storage account ou na sub-rede
- Confirmar se a storage account ainda existe e está no estado Available no portal
Qual é a sequência correta de diagnóstico?
A) 5 → 4 → 1 → 2 → 3
B) 3 → 5 → 4 → 1 → 2
C) 1 → 2 → 5 → 3 → 4
D) 4 → 5 → 2 → 1 → 3
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: C
A pista decisiva está na combinação de dois fatos: o firewall da storage account nega todo acesso público, e a sub-rede snet-app está listada nas regras de VNet. Esse par de configurações parece suficiente, mas não é. Para que o Azure reconheça o tráfego de uma sub-rede como originado de dentro da VNet, o Service Endpoint para Microsoft.Storage precisa estar habilitado naquela sub-rede. Sem ele, o tráfego chega à storage account como se fosse tráfego público, e o firewall bloqueia.
A informação irrelevante neste cenário é a habilitação do blob versioning. Ela foi incluída propositalmente para induzir o leitor a associar a mudança recente ao problema. O blob versioning afeta o comportamento de sobrescrita de blobs, mas não tem qualquer relação com autenticação ou autorização de acesso.
Os distratores representam dois erros de raciocínio comuns: confundir a role RBAC com a camada de rede (alternativa A) e atribuir o problema à última mudança visível no ambiente, mesmo sem relação causal (alternativa B). A alternativa D é tecnicamente falsa e serve como filtro de conhecimento básico.
O distrator mais perigoso é o B: um administrador que culpar o versioning pode passar horas investigando uma mudança inofensiva enquanto o problema real permanece ativo.
Gabarito — Cenário 2
Resposta: B
A alteração de redundância de LRS de volta para GRS pode ser feita diretamente nas configurações da storage account sem interromper as aplicações em execução. O Azure permite alterar o nível de redundância de uma storage account existente, e a operação não causa downtime nem exige recriação da conta.
A restrição crítica do cenário é que as aplicações estão em produção e ativas. Isso elimina qualquer abordagem que exija interrupção de serviço ou migração de dados. A alternativa A seria válida em um contexto onde a storage account precisasse ser movida de região ou tivesse restrições que impedissem a alteração in-place, mas aqui ela seria lenta, arriscada e desnecessária. A alternativa C é um erro grave: o failover manual é irreversível e move permanentemente a conta para a região secundária, o oposto do que se quer aqui. A alternativa D desperdiça tempo e não é necessária para uma operação que o administrador pode executar diretamente.
Gabarito — Cenário 3
Resposta: C
A chave está na frase "criada com as configurações padrão do portal". A Microsoft alterou o comportamento padrão do portal e da API para criar storage accounts com a propriedade allowBlobPublicAccess definida como false. Isso significa que, mesmo que o container tenha acesso anônimo configurado no nível do container, o acesso público é bloqueado no nível da conta antes de qualquer verificação do container.
A informação irrelevante deliberada é o Microsoft Defender for Storage. Ele fornece alertas e detecção de ameaças, mas não altera as configurações de acesso público nem bloqueia requisições diretamente. Incluí-lo no enunciado explora a tendência de associar "segurança reforçada ontem" ao problema de hoje.
O distrator mais perigoso é o B: um leitor que não conhece o comportamento real do Defender for Storage pode passar tempo tentando desabilitá-lo ou criar exceções, sem qualquer efeito sobre o problema real. A causa é uma configuração padrão da própria conta, e a solução é habilitar explicitamente o acesso público no nível da conta antes de configurar os containers.
Gabarito — Cenário 4
Resposta: A
A sequência correta segue a lógica de diagnóstico progressivo: do mais simples e abrangente para o mais específico.
Passo 5 primeiro: confirmar que a storage account existe e está disponível elimina a hipótese mais básica antes de qualquer investigação de rede.
Passo 4 em seguida: verificar mudanças recentes é fundamental porque o acesso era funcional no dia anterior. Uma alteração recente é a causa mais provável e deve ser identificada cedo.
Passo 1 depois: verificar o Service Endpoint na sub-rede é o pré-requisito técnico para que as regras de VNet funcionem.
Passo 2 na sequência: confirmar se a sub-rede ou IP está listado nas regras do firewall valida a configuração específica.
Passo 3 por último: usar o Storage Explorer com credenciais elevadas testa o acesso de forma isolada e confirma se o problema é de rede ou de outra natureza, servindo como validação final.
A alternativa B comete o erro de começar pelo teste prático antes de verificar o estado básico do recurso. A alternativa C ignora completamente a verificação de mudanças recentes, que é a pista mais relevante dado o contexto. A alternativa D começa por mudanças recentes, mas pula a verificação de existência da conta e mistura a ordem das etapas de rede sem lógica progressiva.
Árvore de Troubleshooting: Create and Configure Storage Accounts
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta de diagnóstico |
| Laranja | Validação ou verificação intermediária |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
Diante de um problema real, comece pelo nó raiz e responda cada pergunta com base no que é observável no portal ou via CLI. Cada ramificação elimina uma classe de hipóteses. Quando chegar a um nó vermelho, a causa está identificada; o nó verde correspondente indica a ação corretiva. Se o caminho percorrido não levar a uma resolução, retorne ao nó anterior e reavalie a resposta da pergunta de diagnóstico com base em evidências adicionais.