Laboratório de Troubleshooting: Manage Resource Groups
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Um administrador recebe um chamado relatando que a equipe de desenvolvimento não consegue criar novos recursos dentro do resource group rg-dev-aplicacoes. O grupo existe, está visível no portal, e os desenvolvedores conseguem listar os recursos já existentes sem problemas. A subscription está ativa e sem alertas de quota.
O administrador verifica que os desenvolvedores possuem a role Contributor atribuída diretamente no resource group. Durante a investigação, nota que uma Azure Policy foi recentemente atribuída na subscription, mas o time de governança informa que ela tem efeito Audit, não Deny. O administrador também confirma que a região eastus está disponível e que não há problemas de conectividade com o portal.
Ao tentar criar uma Storage Account pelo portal, o desenvolvedor recebe:
AuthorizationFailed: The client does not have authorization to perform
action 'Microsoft.Storage/storageAccounts/write' over scope
'/subscriptions/xxxx/resourceGroups/rg-dev-aplicacoes'.
Qual é a causa raiz do problema?
A) A Azure Policy com efeito Audit está bloqueando a criação de recursos porque o modo de enforcement foi alterado para Enabled sem que o efeito fosse atualizado.
B) Um lock do tipo ReadOnly foi aplicado no resource group, impedindo operações de escrita no plano de gerenciamento mesmo para usuários com role Contributor.
C) A role Contributor foi atribuída com uma condição ABAC que restringe o escopo de escrita a um tipo de recurso específico, excluindo Storage Accounts.
D) A subscription atingiu o limite de recursos do tipo Microsoft.Storage e o Azure Resource Manager está retornando erro de autorização em vez de quota exceeded.
Cenário 2 — Decisão de Ação
A equipe de operações identificou que um lock do tipo CanNotDelete foi aplicado incorretamente no resource group rg-homologacao, impedindo que recursos de testes obsoletos sejam removidos ao final de cada ciclo. A causa está confirmada e documentada.
O resource group contém 14 recursos ativos. Quatro deles estão sendo usados em testes de integração que terminam em 40 minutos. A janela de manutenção programada para limpeza começa em 1 hora. O administrador possui a role Owner na subscription.
Nenhum dos recursos no grupo possui locks individuais. A equipe de governança confirmou que o lock foi criado por engano e que sua remoção está aprovada.
Qual é a ação correta a tomar neste momento?
A) Remover o lock imediatamente e iniciar a exclusão dos recursos obsoletos antes que os testes de integração terminem, para otimizar o tempo da janela de manutenção.
B) Aguardar o encerramento dos testes de integração, remover o lock e executar a exclusão dos recursos obsoletos dentro da janela de manutenção programada.
C) Excluir o resource group inteiro agora, pois o lock CanNotDelete não impede a exclusão quando a role Owner está presente na subscription.
D) Criar um novo resource group, mover os recursos ativos para ele e excluir o rg-homologacao com todos os recursos obsoletos de uma vez.
Cenário 3 — Causa Raiz
Um administrador está analisando um relatório de Cost Analysis e percebe que vários recursos do rg-financas não aparecem quando o filtro departamento: financas é aplicado. O resource group possui a tag departamento: financas aplicada corretamente. Os recursos estão em execução e gerando custos visíveis no relatório geral, sem o filtro.
O administrador verifica que não há Azure Policy configurada para herança de tags no ambiente. A subscription tem 8 resource groups e apenas o rg-financas apresenta o problema. Os recursos foram criados via templates ARM há 3 meses, e os templates não incluíam o bloco de tags.
Ao inspecionar dois recursos do grupo pelo CLI, o administrador obtém:
$ az resource show --ids /subscriptions/xxxx/resourceGroups/rg-financas/providers/Microsoft.Compute/virtualMachines/vm-fin-01 --query tags
{}
$ az resource show --ids /subscriptions/xxxx/resourceGroups/rg-financas/providers/Microsoft.Compute/virtualMachines/vm-fin-02 --query tags
{}
Qual é a causa raiz do comportamento observado no Cost Analysis?
A) O Cost Analysis apresenta falha de sincronização e não reflete tags aplicadas em resource groups criados há mais de 90 dias.
B) Os recursos individuais não possuem a tag departamento: financas aplicada, pois tags de resource groups não são herdadas automaticamente pelos recursos filhos.
C) Os templates ARM sobrescrevem as tags do resource group nos recursos filhos durante o deploy, removendo qualquer tag previamente configurada.
D) O filtro de tags no Cost Analysis opera apenas no escopo de subscription e não reconhece tags aplicadas em escopos de resource group.
Cenário 4 — Sequência de Diagnóstico
Um administrador recebe um alerta informando que a operação de mover o recurso vnet-producao do resource group rg-rede para o rg-infraestrutura falhou. Ambos os resource groups estão na mesma subscription. O administrador precisa diagnosticar a falha antes de tentar novamente.
Os passos de investigação disponíveis são:
- Verificar se o tipo de recurso
Microsoft.Network/virtualNetworksconsta na lista de recursos que suportam a operação Move - Confirmar se existem locks do tipo
ReadOnlyouCanNotDeletenos resource groups de origem e destino - Verificar se há recursos dependentes da VNet, como NICs ou VMs em execução, que possam impedir a movimentação
- Consultar o Activity Log da subscription para identificar a mensagem de erro exata retornada pelo Azure Resource Manager
- Confirmar se o administrador possui permissão de escrita nos dois resource groups e permissão de exclusão no grupo de origem
Qual é a sequência correta de investigação?
A) 1 -> 5 -> 2 -> 4 -> 3
B) 4 -> 5 -> 2 -> 1 -> 3
C) 4 -> 1 -> 2 -> 5 -> 3
D) 2 -> 4 -> 1 -> 3 -> 5
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A mensagem de erro AuthorizationFailed sobre a ação write indica que algo no plano de gerenciamento está bloqueando a operação, mesmo com a role Contributor atribuída corretamente. Um lock do tipo ReadOnly aplicado no resource group impede qualquer operação que não seja leitura no plano de gerenciamento, sobrepondo-se às permissões RBAC. O Contributor não pode remover locks; apenas Owner ou um papel com Microsoft.Authorization/locks/* pode fazê-lo.
A informação sobre a Azure Policy com efeito Audit é propositalmente irrelevante: políticas com esse efeito registram não conformidades mas não bloqueiam operações. Incluí-la no enunciado simula a pressão real de investigação, onde nem todo dado é uma pista.
O distrator mais perigoso é a alternativa C, pois condições ABAC são reais e plausíveis, mas o erro retornado não indica restrição de tipo de recurso. O distrator A confunde o comportamento de efeitos de policy. O distrator D é improvável porque o erro seria QuotaExceeded, não AuthorizationFailed.
Gabarito — Cenário 2
Resposta: B
A restrição crítica do cenário é que testes de integração estão em execução e terminam em 40 minutos. A janela de manutenção começa em 1 hora, oferecendo margem suficiente para aguardar o encerramento dos testes e agir de forma controlada. Remover o lock e excluir recursos enquanto testes estão ativos (alternativa A) pode comprometer resultados em andamento, mesmo que nenhum dos recursos obsoletos esteja diretamente em uso pelos testes, pois dependências em resource groups compartilhados são comuns.
A alternativa C representa um equívoco clássico: a role Owner permite remover o lock, mas não altera o comportamento do lock em si. Enquanto o lock CanNotDelete existir, nenhuma exclusão é permitida, independentemente da role. A alternativa D introduz uma operação de Move desnecessária e de maior risco do que a ação simples de remover o lock e aguardar a janela. Agir com pressa quando há tempo disponível é o erro que os distratores A e D induzem.
Gabarito — Cenário 3
Resposta: B
A saída do CLI é a pista decisiva: ambas as VMs retornam {} para o campo de tags, confirmando que os recursos individuais não possuem nenhuma tag aplicada. Tags em resource groups são metadados do próprio grupo e não se propagam automaticamente para os recursos filhos, a menos que uma Azure Policy com efeito Modify esteja configurada para fazê-lo. O enunciado confirma explicitamente que não há essa policy no ambiente.
A informação sobre os templates ARM terem sido usados há 3 meses é irrelevante para o diagnóstico: o problema não é quando os recursos foram criados, mas o fato de que os templates não incluíam o bloco de tags e nenhum mecanismo de herança foi configurado posteriormente.
O distrator mais perigoso é a alternativa C, pois soa plausível para quem conhece o comportamento de algumas propriedades em templates ARM. No entanto, tags não são sobrescritas por deploys subsequentes a menos que isso seja explicitamente especificado no template. O distrator D inverte a lógica real do Cost Analysis, que funciona por filtro de tags em qualquer escopo onde a tag esteja presente no recurso.
Gabarito — Cenário 4
Resposta: B
A sequência correta começa pela leitura do Activity Log (passo 4) porque ele fornece a mensagem de erro exata, eliminando hipóteses antes de qualquer verificação adicional. Sem saber o que o ARM retornou, qualquer investigação subsequente é especulativa. Com o erro em mãos, verifica-se permissões (passo 5), pois AuthorizationFailed e LinkedAuthorizationFailed são causas frequentes. Em seguida, verifica-se a existência de locks (passo 2), que bloqueariam a operação independentemente de permissões. Depois, confirma-se se o tipo de recurso suporta Move (passo 1), informação documentada pela Microsoft. Por fim, investigam-se dependências (passo 3), que é a verificação mais trabalhosa e deve ser feita somente após eliminar causas mais simples.
A sequência A inverte a ordem lógica ao verificar o suporte ao Move antes de entender o erro real. A sequência C mistura verificação de suporte ao Move com leitura de log sem uma progressão diagnóstica coerente. A sequência D começa por locks sem ter lido o erro, o que pode levar a ações corretivas desnecessárias.
Árvore de Troubleshooting: Manage Resource Groups
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial, ponto de entrada da investigação |
| Azul médio | Pergunta diagnóstica, ponto de decisão |
| 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, parta do nó raiz descrevendo o sintoma observado e responda cada pergunta de diagnóstico com base no que é verificável diretamente no ambiente, sem assumir causas. Siga o caminho indicado pela resposta até atingir um nó de causa identificada (vermelho) e, a partir dele, aplique a ação correspondente (verde). Se nenhum caminho convergir para uma causa clara, retorne ao nó de validação intermediária (laranja) para consultar o Activity Log e obter o erro exato antes de reiniciar o percurso.