Laboratório de Troubleshooting: Manage data by using Azure Storage Explorer and AzCopy
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Um administrador configura um job automatizado em um servidor Linux para sincronizar arquivos de log de uma pasta local para um contêiner Blob todas as noites às 23h. O script foi testado manualmente com sucesso no dia anterior.
Na primeira execução agendada, o job falha. O administrador verifica o log de saída:
$ azcopy sync /var/logs/app \
'https://storageaccount.blob.core.windows.net/logs-container' \
--recursive
INFO: Scanning...
ERRO: failed to perform copy command due to error:
AuthenticationErrorDetail: Signature fields not well formed.
Status: 403
O administrador confirma que:
- O contêiner existe e está acessível pelo portal do Azure
- O servidor Linux tem conectividade com a internet
- O script usa uma URL com token SAS gerada três dias atrás com validade de 48 horas
- O horário do sistema operacional no servidor está correto
- O AzCopy está na versão mais recente
Qual é a causa raiz da falha?
A) O AzCopy não suporta o comando sync com URLs SAS; apenas copy é compatível com esse método de autenticação.
B) O token SAS expirou antes da execução agendada, tornando a assinatura inválida no momento da requisição.
C) O contêiner de destino não possui a política de acesso público habilitada, bloqueando requisições externas.
D) A flag --recursive causa conflito com tokens SAS no nível de contêiner, exigindo um SAS de nível de conta.
Cenário 2 — Decisão de Ação
A equipe de operações identificou que um pipeline de dados está falhando porque o AzCopy está sendo executado em um servidor de build sem identidade gerenciada configurada. A causa foi confirmada: o processo tenta usar azcopy login interativo, o que não é possível em ambiente headless.
O ambiente possui as seguintes restrições:
- O servidor de build está em produção e não pode ser reiniciado agora
- A equipe de segurança proibiu o uso de chaves de conta de armazenamento (account keys) em scripts automatizados
- Uma identidade gerenciada atribuída pelo sistema pode ser habilitada na VM sem reinicialização
- O pipeline precisa voltar a funcionar dentro de 30 minutos
- Existe uma SAS token válida por 72 horas já gerada para o contêiner específico
Qual é a ação correta a tomar neste momento?
A) Habilitar a identidade gerenciada na VM e configurar o AzCopy para usar azcopy login --identity, pois essa é a abordagem mais segura e não exige reinicialização.
B) Usar a SAS token já disponível embutida na URL do AzCopy para restaurar o pipeline imediatamente, respeitando a restrição de não usar account keys.
C) Solicitar à equipe de segurança uma exceção temporária para usar a account key até que a identidade gerenciada seja configurada corretamente.
D) Reescrever o pipeline para usar o Azure Storage Explorer em modo CLI, que suporta execução headless sem necessidade de autenticação adicional.
Cenário 3 — Causa Raiz
Uma analista usa o Azure Storage Explorer conectado via Microsoft Entra ID a uma assinatura corporativa. Ela consegue navegar por todos os contêineres de uma conta de armazenamento e visualizar arquivos normalmente.
Ao tentar baixar um arquivo de 2 GB, o Storage Explorer inicia a transferência, exibe progresso por alguns segundos e então apresenta o seguinte erro:
The operation was canceled.
Error: InteropError: Failed to complete download.
Network timeout after 30 seconds of inactivity.
O administrador verifica:
- A conta de armazenamento tem firewall configurado para permitir o IP corporativo
- A conta de armazenamento está na região East US
- O papel Storage Blob Data Contributor está atribuído à analista
- O arquivo existe e tem 2 GB conforme exibido no Storage Explorer
- Outros usuários no mesmo escritório relatam o mesmo problema com arquivos grandes
- Downloads de arquivos pequenos (abaixo de 50 MB) funcionam normalmente para todos
Qual é a causa raiz do problema?
A) O papel Storage Blob Data Contributor não inclui permissão de download; é necessário o papel Storage Blob Data Reader especificamente para leitura.
B) O firewall da conta de armazenamento está bloqueando os IPs usados pelo Storage Explorer após a autenticação inicial.
C) Há um problema de conectividade de rede no ambiente local que interrompe transferências longas antes da conclusão, evidenciado pelo timeout após inatividade e pelo padrão restrito a arquivos grandes.
D) O Storage Explorer tem um limite interno de 1 GB por download e fragmenta arquivos maiores, o que causa falha quando o contêiner não tem versionamento habilitado.
Cenário 4 — Sequência de Diagnóstico
Um administrador recebe um alerta de que um job AzCopy que copia dados entre duas contas de armazenamento parou de funcionar após uma mudança de configuração realizada ontem. O erro reportado é genérico:
ERRO: Status 403 Forbidden
O administrador precisa diagnosticar a causa. Os seguintes passos estão disponíveis, mas fora de ordem:
- Passo P: Verificar se o token SAS ou as credenciais usadas pelo AzCopy ainda são válidas e não expiraram
- Passo Q: Executar o comando manualmente no terminal para reproduzir o erro com saída detalhada usando
--log-level=DEBUG - Passo R: Revisar o histórico de mudanças realizadas ontem na conta de armazenamento, incluindo alterações em firewall, RBAC e chaves
- Passo S: Confirmar que as contas de armazenamento de origem e destino estão acessíveis e que os contêineres existem
- Passo T: Se credenciais estiverem válidas, verificar se houve alteração nas regras de firewall ou nas atribuições de papel RBAC após a mudança reportada
Qual é a sequência de diagnóstico mais lógica?
A) R, S, Q, P, T
B) Q, S, P, T, R
C) S, Q, P, R, T
D) Q, R, P, T, S
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
O token SAS foi gerado com validade de 48 horas, três dias antes da execução. No momento do job agendado, o token já havia expirado há pelo menos 24 horas. A mensagem Signature fields not well formed com status 403 é exatamente o retorno do Azure para SAS tokens inválidos ou expirados.
A pista decisiva no enunciado é a combinação entre o tempo de validade declarado (48 horas) e o momento da criação (três dias atrás). O horário correto do servidor foi mencionado propositalmente como informação irrelevante para induzir o leitor a investigar problemas de clock skew, que é um distrator clássico em erros de assinatura.
A alternativa A é falsa: azcopy sync é totalmente compatível com SAS. A alternativa C confunde política de acesso público com autenticação por SAS. A alternativa D inventa uma incompatibilidade inexistente entre --recursive e SAS. O distrator mais perigoso é o D, pois levaria o administrador a gastar tempo investigando flags e escopo do token em vez de simplesmente regenerar o token expirado.
Gabarito — Cenário 2
Resposta: B
O enunciado apresenta restrições claras e simultâneas: a account key está proibida, a identidade gerenciada pode ser habilitada sem reinicialização, mas o prazo é de 30 minutos. A configuração da identidade gerenciada, embora tecnicamente correta a longo prazo, envolve habilitar o recurso na VM, atribuir papel RBAC, propagar permissões e reconfigurar o pipeline, o que dificilmente ocorre dentro do prazo estabelecido.
A SAS token válida já está disponível, não é uma account key, e pode ser usada imediatamente no AzCopy embutida na URL, sem nenhuma reconfiguração de infraestrutura. Ela atende ao prazo e respeita a restrição de segurança.
A alternativa A é a solução correta para o longo prazo, mas ignora a restrição de 30 minutos. A alternativa C viola explicitamente a restrição de segurança. A alternativa D é incorreta: o Storage Explorer não é uma ferramenta CLI equivalente ao AzCopy para pipelines automatizados e não elimina a necessidade de autenticação. O distrator mais perigoso é o A, pois representa a decisão tecnicamente ideal fora de contexto, levando o administrador a perder o prazo de restauração.
Gabarito — Cenário 3
Resposta: C
O padrão diagnóstico decisivo é que downloads de arquivos pequenos funcionam normalmente para todos os usuários, mas arquivos grandes falham com timeout após inatividade. Isso indica uma limitação de rede no ambiente local que interrompe conexões TCP de longa duração antes da conclusão da transferência, não um problema de permissão ou configuração na conta de armazenamento.
A informação sobre a conta estar na região East US é irrelevante e foi incluída propositalmente. A alternativa A é tecnicamente falsa: Storage Blob Data Contributor inclui permissões de leitura e download. A alternativa B é descartável pelo próprio enunciado, que confirma que o firewall está configurado para permitir o IP corporativo e que o Storage Explorer acessa os contêineres normalmente. A alternativa D inventa uma limitação que não existe no Storage Explorer.
O distrator mais perigoso é o B, pois levaria o administrador a investigar e modificar regras de firewall na conta de armazenamento sem necessidade, possivelmente expondo a conta desnecessariamente.
Gabarito — Cenário 4
Resposta: B
A sequência correta é: Q, S, P, T, R.
O raciocínio progressivo parte do mais imediato para o mais investigativo:
- Q — Reproduzir o erro com saída detalhada é o primeiro passo: sem informação detalhada, qualquer hipótese é especulação.
- S — Confirmar que os recursos existem e estão acessíveis elimina causas básicas de infraestrutura antes de entrar em autenticação.
- P — Verificar validade das credenciais é o próximo passo natural dado o erro 403.
- T — Se as credenciais estiverem válidas, investigar mudanças em firewall e RBAC como causa do 403.
- R — Revisar o histórico completo de mudanças confirma ou refina o diagnóstico já orientado.
A alternativa A começa pelo histórico de mudanças antes de reproduzir o erro, o que é ineficiente: sem saber exatamente qual operação falha, o histórico pode ser enorme e não orientado. A alternativa C começa com a confirmação de existência dos contêineres antes de sequer reproduzir o erro com detalhe, o que inverte a lógica. A alternativa D salta da reprodução direto para o histórico, pulando a validação de credenciais, que é a causa mais comum de 403 em AzCopy.
Árvore de Troubleshooting: Manage data by using Azure Storage Explorer and AzCopy
Legenda:
- Azul escuro: sintoma ou falha inicial (ponto de entrada)
- Azul: pergunta de diagnóstico, respondida com sim, não ou estado observável
- Laranja: etapa de validação ou verificação intermediária antes de prosseguir
- Vermelho: causa identificada
- Verde: ação recomendada ou resolução
Para usar esta árvore diante de um problema real, comece pelo nó raiz e siga as ramificações respondendo cada pergunta com base no que você observa no ambiente, não no que você suspeita. Sempre execute a etapa de reprodução com log detalhado antes de avançar para hipóteses de causa. Ao chegar a um nó vermelho, você tem a causa; ao chegar a um nó verde, você tem a ação. Nunca pule etapas de validação laranja, pois elas evitam diagnósticos prematuros sob pressão.