Laboratório de Troubleshooting: Create and manage an Azure Container Registry
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de desenvolvimento relata que imagens enviadas ao registry funcionam normalmente em ambiente de homologação, mas o ambiente de produção, localizado em outra região do Azure, apresenta latência elevada e ocasionalmente falha no pull com timeout. O registry foi criado há três semanas na região East US. A SKU contratada é Premium. A equipe confirma que o registry está acessível publicamente e que as credenciais utilizadas em produção são as mesmas do ambiente de homologação. O time de redes informa que não há regras de firewall bloqueando a comunicação entre a região de produção e East US.
Nos logs do pipeline de produção, o erro observado é:
Error response from daemon: Get "https://meuregistry.azurecr.io/v2/":
net/http: request canceled while waiting for connection (Client.Timeout exceeded)
O que está causando esse comportamento?
A) As credenciais usadas em produção expiraram e precisam ser renovadas via az acr credential renew
B) O registry não possui uma réplica na região de produção, forçando todo o tráfego a atravessar regiões com latência acumulada
C) A SKU Premium tem um limite de requisições simultâneas que está sendo atingido pela carga de produção
D) O endpoint público do registry está sendo bloqueado por uma política de Microsoft Entra Conditional Access aplicada à assinatura
Cenário 2 — Decisão de Ação
A equipe de segurança identificou que o admin account do registry está habilitado e as credenciais foram comprometidas. A causa está confirmada. O registry é utilizado por três aplicações em produção que autenticam via usuário e senha do admin account. As aplicações rodam em instâncias de Azure Container Instances e Azure Kubernetes Service. O time de identidade confirma que as managed identities já estão configuradas nas instâncias, mas nunca foram usadas para autenticação no registry. Não há janela de manutenção programada nas próximas 8 horas.
Qual é a ação correta a tomar neste momento?
A) Desabilitar imediatamente o admin account e reconfigurar as aplicações para usar managed identity, aceitando a interrupção temporária de produção
B) Rotacionar as credenciais do admin account via az acr credential renew e, em paralelo, iniciar a migração para managed identity sem interromper produção
C) Excluir o registry e recriar com admin account desabilitado, restaurando as imagens a partir de um backup externo
D) Revogar o token comprometido no Microsoft Entra ID e aguardar a janela de manutenção para qualquer alteração no registry
Cenário 3 — Causa Raiz
Um engenheiro executa o seguinte comando para verificar as imagens disponíveis no registry:
az acr repository list --name meuregistry --output table
O retorno é uma lista vazia, sem erros. Em seguida, o mesmo engenheiro executa um build local e faz push manualmente:
docker build -t meuregistry.azurecr.io/api:v2 .
docker push meuregistry.azurecr.io/api:v2
O push é concluído com sucesso. Ao listar novamente, a imagem api:v2 aparece. O engenheiro confirma que builds anteriores via az acr task foram executados sem erro nas últimas 24 horas e os logs das tasks mostram status Succeeded. O registry está na SKU Standard e não possui nenhuma política de retenção configurada.
Qual é a causa raiz da lista vazia antes do push manual?
A) A SKU Standard não suporta o comando az acr repository list; é necessário usar a API REST diretamente
B) As tasks executadas via az acr task publicaram as imagens em um registry diferente do esperado, configurado incorretamente na definição da task
C) A política de quarentena estava ativa e retinha as imagens antes da liberação
D) O comando az acr repository list falhou silenciosamente por um problema de permissão do usuário na camada de leitura do repositório
Cenário 4 — Sequência de Diagnóstico
Um pipeline de CI/CD falha ao tentar fazer push de uma imagem para o registry. O erro retornado é:
unauthorized: authentication required, visit https://aka.ms/acr/authorization for more information.
O pipeline roda em um agente hospedado no Azure DevOps e usa uma service connection configurada há seis meses. As imagens anteriores foram enviadas com sucesso até ontem. Nenhuma alteração foi feita no pipeline. O registry está operacional e acessível.
Os seguintes passos de investigação estão disponíveis, fora de ordem:
- Verificar se a role AcrPush ainda está atribuída à service principal usada pela service connection
- Executar
az acr login --name meuregistryno agente para testar autenticação interativa - Consultar o log de auditoria do registry para identificar qual identidade tentou autenticar
- Verificar a data de expiração do segredo da service principal associada à service connection
- Confirmar se o registry sofreu alterações de configuração de rede ou firewall nas últimas 24 horas
Qual é a sequência correta de investigação?
A) 5, 3, 1, 4, 2
B) 2, 1, 4, 3, 5
C) 3, 5, 1, 4, 2
D) 1, 2, 3, 4, 5
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista central no enunciado é a combinação de SKU Premium com registry em uma única região (East US) e ambiente de produção em outra região. A SKU Premium oferece replicação geográfica, mas ela não é habilitada automaticamente; é necessário criar uma réplica explicitamente na região de produção. Sem a réplica, todo o tráfego de pull atravessa regiões, resultando em alta latência e timeouts.
A informação sobre ausência de regras de firewall é deliberadamente irrelevante: ela elimina um suspeito, mas não aponta a causa. O erro de timeout indica problema de conectividade ou distância, não de autenticação.
A alternativa A pode ser descartada porque o erro não é de autenticação. A alternativa C é um distrator plausível, mas limites de throughput do Premium são extremamente altos e raramente atingidos. A alternativa D seria um erro de autenticação HTTP 401, não um timeout de conexão.
O distrator mais perigoso é D: um operador ansioso poderia abrir chamados com a equipe de identidade e perder tempo investigando políticas de acesso condicional enquanto o problema real é de topologia de replicação.
Gabarito — Cenário 2
Resposta: B
O contexto de restrições é determinante aqui: não há janela de manutenção, as managed identities já estão configuradas mas nunca foram testadas como mecanismo de autenticação no registry, e as aplicações estão em produção. Desabilitar o admin account sem validar que a autenticação via managed identity funciona corretamente causaria interrupção imediata e potencialmente prolongada.
A ação correta é rotacionar as credenciais para neutralizar o comprometimento imediato e, em paralelo, migrar para managed identity de forma controlada e validada antes de desabilitar o admin account.
A alternativa A ignora a restrição crítica de que as managed identities nunca foram usadas para autenticar no registry; assumir que funcionarão sem validação em produção é um risco alto. A alternativa C é destrutiva e desnecessária. A alternativa D é incorreta porque credenciais do admin account do registry não são tokens gerenciados pelo Microsoft Entra ID; são credenciais locais do serviço, e revogar algo no Entra ID não as invalida.
Gabarito — Cenário 3
Resposta: B
A pista que confirma essa causa é o fato de que as tasks reportaram Succeeded mas nenhuma imagem aparecia no registry consultado. Se houvesse problema de permissão (alternativa D), o comando retornaria erro, não lista vazia. Se a quarentena estivesse ativa (alternativa C), as imagens existiriam no repositório em estado retido, e o az acr repository list as listaria, pois o comando lista repositórios, não apenas imagens liberadas.
A informação sobre a SKU Standard e ausência de política de retenção é irrelevante e foi incluída para desviar o foco: SKU Standard suporta plenamente o az acr repository list, e retenção de imagens não explicaria a ausência de repositórios.
A causa real é que a definição da task aponta para um registry diferente. Isso é um erro de configuração silencioso e comum quando há múltiplos registries em uma organização (dev, staging, prod). O distrator mais perigoso é D, pois levaria o engenheiro a investigar permissões e potencialmente alterar roles desnecessariamente.
Gabarito — Cenário 4
Resposta: A
A sequência correta é: 5, 3, 1, 4, 2.
O raciocínio diagnóstico correto parte do que mudou no ambiente antes de investigar a identidade. O passo 5 descarta rapidamente mudanças de rede ou firewall que poderiam explicar a falha. O passo 3 usa o log de auditoria para identificar qual identidade está tentando autenticar, evitando suposições. Com a identidade confirmada, o passo 1 verifica se a role ainda está atribuída. O passo 4 verifica a expiração do segredo, que é a causa mais provável dado que nenhuma alteração foi feita no pipeline e ele funcionava até ontem. O passo 2 é o último porque testa autenticação interativa no agente, o que tem utilidade limitada para diagnosticar falha de service principal.
A alternativa D (1, 2, 3, 4, 5) representa o erro de pular direto para a hipótese mais conhecida sem validar o contexto primeiro. A alternativa B começa com autenticação interativa, que não diagnostica o problema da service connection. A causa mais provável é o segredo expirado da service principal, e a sequência correta chega a esse ponto de forma progressiva e eliminativa.
Árvore de Troubleshooting: Create and manage an Azure Container Registry
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta diagnóstica |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
| Laranja | Validação ou verificação intermediária |
Para usar esta árvore diante de um problema real, identifique o sintoma observado e localize o nó de entrada correspondente na raiz. A partir daí, responda cada pergunta diagnóstica com base no que é verificável no ambiente: logs, configurações, atribuições de role, estado do registry. Siga o caminho até um nó vermelho de causa identificada e, a partir dele, tome a ação recomendada no nó verde correspondente. Nós laranjas indicam que uma validação deve ser feita antes de considerar o problema encerrado.