Laboratório de Troubleshooting: Manage Subscriptions
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
A equipe de segurança de uma empresa reporta que recursos estão sendo criados na região westeurope dentro da subscription de produção, violando uma política interna que exige uso exclusivo das regiões brazilsouth e eastus. O administrador verifica que existe uma Azure Policy com efeito deny atribuída ao management group pai da subscription, cobrindo exatamente as duas regiões permitidas. A policy está com status Enabled e o campo enforcementMode está configurado como Default.
O administrador também observa o seguinte ao listar as policy assignments na subscription diretamente:
az policy assignment list --scope /subscriptions/<subscription-id> --output table
Name DisplayName EnforcementMode
-------------------------- --------------------------- ---------------
AllowedLocations-Override Allowed Locations Override DoNotEnforce
A subscription tem 45 dias de existência. O ambiente de homologação, que usa a mesma hierarquia de management group, não apresenta o problema. A equipe de rede confirma que as VNets criadas em westeurope estão sem peering configurado.
Qual é a causa raiz do problema?
A) O efeito deny no management group não se propaga para subscriptions criadas há menos de 60 dias
B) A policy assignment na subscription com EnforcementMode: DoNotEnforce está sobrescrevendo o efeito da policy herdada do management group
C) O status Enabled da policy no management group indica que ela está em modo de auditoria, não de bloqueio efetivo
D) A ausência de peering nas VNets criadas em westeurope indica que a policy de localização não cobre recursos de rede
Cenário 2 — Decisão de Ação
A causa já foi identificada: uma subscription de produção foi transferida acidentalmente para um management group incorreto, chamado MG-Sandbox, que possui uma policy de deny bloqueando a criação de recursos do tipo Microsoft.Compute/virtualMachines. O time de operações precisa implantar uma atualização crítica que envolve a criação de novas VMs em menos de duas horas. Mover a subscription para o management group correto (MG-Production) levaria no máximo 5 minutos e não causa indisponibilidade nos recursos existentes.
No entanto, o administrador que está disponível possui a role Reader na subscription e Contributor no resource group de destino. Ele não possui permissões sobre management groups.
Um segundo administrador com permissões de Management Group Contributor está disponível, mas está em fuso horário diferente e só responderá em aproximadamente 3 horas.
Qual é a ação correta a tomar neste momento?
A) O administrador disponível deve mover a subscription para MG-Production usando o portal do Azure, pois a role Contributor no resource group é suficiente para operações de management group
B) Criar uma policy assignment de exemption na subscription para o tipo Microsoft.Compute/virtualMachines usando as permissões de Contributor no resource group
C) Escalar para o segundo administrador e aguardar, pois nenhuma das ações disponíveis pode ser executada com as permissões atuais sem risco de impacto maior
D) Criar as VMs diretamente via Azure CLI autenticado com as credenciais do administrador disponível, pois o plano de dados não é afetado por policies de management group
Cenário 3 — Causa Raiz
Um desenvolvedor abre um chamado relatando que não consegue visualizar nenhum recurso em uma subscription à qual foi adicionado recentemente. Ao acessar o portal do Azure, ele vê a subscription listada no seletor de diretórios, mas ao clicar nela, a lista de recursos aparece completamente vazia. O desenvolvedor confirma que consegue acessar outras subscriptions normalmente.
O administrador verifica o seguinte:
az role assignment list --assignee <developer-object-id> \
--scope /subscriptions/<subscription-id> --output table
PrincipalName RoleDefinitionName Scope
--------------- -------------------- ------------------------------------------
dev-user Reader /subscriptions/<id>/resourceGroups/rg-app01
O administrador também confirma que a subscription está ativa, que não há locks aplicados, e que o Microsoft Entra ID tenant associado à subscription é o mesmo tenant do usuário. A subscription possui 12 resource groups no total, todos com recursos implantados. O time de rede informa que as VNets da subscription estão com DNS personalizado configurado.
Qual é a causa raiz do problema?
A) A subscription está associada a um tenant diferente do tenant do usuário, impedindo a visualização dos recursos
B) Locks aplicados na subscription estão bloqueando operações de leitura para usuários sem a role Owner
C) O desenvolvedor possui a role Reader com escopo restrito a um único resource group, sem permissão de leitura no nível da subscription
D) A configuração de DNS personalizado nas VNets está impedindo a resolução de nomes necessária para listar recursos no portal
Cenário 4 — Impacto Colateral
Um administrador identifica que uma subscription de produção foi associada ao tenant errado do Microsoft Entra ID durante um processo de reorganização corporativa. Para corrigir o problema, ele executa a transferência da subscription para o tenant correto. A operação é concluída com sucesso e os recursos permanecem disponíveis.
Dois dias depois, vários times reportam que pipelines de CI/CD estão falhando com erros de autenticação, e que aplicações em produção que consumiam APIs internas começaram a retornar erros 401 Unauthorized.
A transferência foi a ação correta e resolveu o problema de associação de tenant. A pergunta é: qual consequência colateral dessa ação causou as falhas reportadas?
A) A transferência de tenant altera o endpoint do Azure Resource Manager, exigindo que todos os clientes atualizem a URL base das chamadas de API
B) As managed identities atribuídas aos recursos foram invalidadas com a transferência, e os service principals associados a pipelines e aplicações deixaram de existir no tenant de origem
C) As role assignments de grupos do Microsoft Entra ID foram preservadas, mas os grupos precisam ser recriados no novo tenant para reativar as permissões
D) As Azure Policies herdadas do management group foram desassociadas durante a transferência, expondo os recursos a criações fora do padrão de governança
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista decisiva está na saída do comando az policy assignment list executado diretamente no escopo da subscription. Ela revela uma policy assignment local chamada AllowedLocations-Override com EnforcementMode: DoNotEnforce. Esse modo desativa a aplicação do efeito da policy (o deny não é executado), mas mantém a avaliação de conformidade. Quando existe uma policy assignment no escopo da subscription com esse modo, ela não sobrescreve a do management group no sentido de remover o efeito herdado, mas a presença de DoNotEnforce em um assignment local indica que alguém criou um assignment específico para suspender a aplicação efetiva naquele escopo.
A informação sobre a ausência de peering nas VNets é a informação irrelevante incluída propositalmente. Peering não tem relação alguma com a avaliação de Azure Policy para localização de recursos.
A alternativa A está errada: não existe regra de carência de 60 dias para propagação de policies. A alternativa C representa um equívoco comum: o campo status: Enabled de uma policy definition é diferente de EnforcementMode; um não controla o outro. A alternativa D é um distrator que tenta desviar o foco para um detalhe de infraestrutura completamente irrelevante para o comportamento de policies.
O erro mais perigoso seria escolher C e ir investigar o status da policy definition no management group, perdendo tempo enquanto o assignment local com DoNotEnforce continua permitindo criações fora das regiões permitidas.
Gabarito — Cenário 2
Resposta: C
A restrição crítica do cenário é de permissão: mover uma subscription entre management groups requer a role Owner ou Management Group Contributor no management group de destino, e no mínimo Owner ou Contributor na subscription. O administrador disponível possui apenas Reader na subscription e Contributor em um resource group, o que é insuficiente para qualquer operação sobre a hierarquia de management groups.
A alternativa A está errada porque Contributor em resource group não concede permissão para operações no plano de gerenciamento de management groups. A alternativa B é tecnicamente válida em outro contexto, mas criar uma policy exemption requer permissão no escopo da subscription, não apenas em um resource group. A alternativa D representa um equívoco conceitual grave: Azure Policy age no plano de controle (ARM), não no plano de dados, mas a criação de VMs é uma operação de plano de controle que será bloqueada pela policy independentemente da ferramenta usada.
A ação correta é escalar e aguardar, documentando o impedimento. Agir fora do escopo de permissões disponíveis causaria erros ou, pior, modificações incorretas na hierarquia de governança.
Gabarito — Cenário 3
Resposta: C
A saída do comando az role assignment list é a pista definitiva. Ela mostra que o desenvolvedor possui a role Reader com escopo em /subscriptions/<id>/resourceGroups/rg-app01, ou seja, em apenas um dos 12 resource groups. No portal do Azure, quando um usuário acessa uma subscription sem role assignment no nível da subscription, o portal lista a subscription mas exibe os recursos apenas dos scopes onde o usuário tem permissão. Se a subscription possui 12 resource groups e o usuário só tem acesso a um, o portal pode apresentar a lista aparentemente vazia dependendo da visão selecionada.
A alternativa A é eliminada pelo próprio enunciado, que confirma que o tenant é o mesmo. A alternativa B é eliminada porque o enunciado confirma a ausência de locks. A alternativa D é a informação irrelevante do cenário: DNS personalizado em VNets não tem qualquer relação com permissões de RBAC ou com a listagem de recursos no portal.
O distrator mais perigoso é A, pois leva o administrador a investigar problemas de tenant e identidade desnecessariamente, quando o problema é de escopo de RBAC visível na primeira saída de comando.
Gabarito — Cenário 4
Resposta: B
Quando uma subscription é transferida entre tenants do Microsoft Entra ID, as managed identities (tanto system-assigned quanto user-assigned) são destruídas, pois elas são objetos do tenant de origem. Os service principals de aplicações registradas no tenant de origem também deixam de ser válidos no contexto da subscription no novo tenant. Pipelines de CI/CD que usam service principals para autenticação no Azure e aplicações que usam managed identities para acessar outros serviços perdem imediatamente a capacidade de se autenticar, resultando nos erros 401 Unauthorized reportados.
A alternativa A está errada: o endpoint do Azure Resource Manager (management.azure.com) é global e não muda com a transferência de tenant. A alternativa C inverte a realidade: role assignments de grupos são removidas na transferência, não preservadas, e grupos não podem ser simplesmente "reativados" no novo tenant sem recriação completa das assignments. A alternativa D é parcialmente verdadeira (policies precisam ser reatribuídas), mas não explica os erros de autenticação 401 em pipelines e aplicações, que são causados por falha de identidade, não de governança.
Árvore de Troubleshooting: Manage Subscriptions
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta de diagnóstico |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
| Laranja | Verificação ou validação intermediária |
Diante de um problema real, inicie pelo nó raiz identificando se o sintoma envolve uma operação bloqueada ou um problema de visibilidade de recursos. Siga as perguntas fechadas respondendo com base no que você pode observar diretamente, por meio de comandos como az policy assignment list e az role assignment list. Os nós laranja indicam pontos onde você precisa coletar informação antes de avançar. Nunca pule para uma causa sem passar pelas verificações intermediárias, especialmente em cenários onde a causa mais óbvia costuma mascarar a causa real.