Pular para o conteúdo principal

Laboratório de Troubleshooting: Configure management groups

Cenários de Diagnóstico​

Cenário 1 — Causa Raiz​

Um administrador de plataforma relata que acabou de aplicar uma Azure Policy com efeito Deny para bloquear a criação de recursos fora da região Brazil South. A policy foi atribuída ao grupo de gerenciamento MG-Corporativo, que contém três grupos filhos: MG-App, MG-Dados e MG-Segurança.

Dois dias após a aplicação, a equipe de dados abre um chamado informando que conseguiu criar com sucesso um Storage Account na região East US 2 dentro de uma assinatura pertencente a MG-Dados. O administrador verifica o portal e confirma que a policy aparece como ativa e atribuída corretamente ao grupo MG-Corporativo.

Informações coletadas durante a investigação:

Policy assignment scope : /providers/Microsoft.Management/managementGroups/MG-Corporativo
Policy effect          : Deny
Compliance state       : Not started
Last evaluated         : Never
Assignment date        : 2024-11-01T09:00:00Z
Current date/time      : 2024-11-01T09:47:00Z

O administrador também verifica que o grupo MG-Dados não possui nenhuma exclusão de escopo configurada e que a assinatura está corretamente listada como membro de MG-Dados.

Qual é a causa raiz do comportamento observado?

A) A assinatura dentro de MG-Dados possui uma policy de efeito Audit que está sobrescrevendo o Deny herdado do grupo pai.

B) A policy ainda não foi avaliada pelo ciclo de conformidade do Azure, que pode levar até 30 minutos após a atribuição para processar recursos existentes e novas criações.

C) O escopo da atribuição está incorreto; policies atribuídas a grupos de gerenciamento não se propagam automaticamente para grupos filhos sem configuração adicional.

D) A criação do Storage Account ocorreu durante uma janela de manutenção do Azure Policy, durante a qual avaliações de conformidade ficam suspensas temporariamente.

Cenário 2 — Decisão de Ação​

A equipe de governança identificou a causa de um problema recorrente: assinaturas de novos projetos estão sendo criadas diretamente sob o Tenant Root Group em vez de serem movidas para o grupo de gerenciamento MG-Projetos logo após o provisionamento. Isso acontece porque os criadores das assinaturas têm a role Owner na assinatura recém-criada, mas não têm permissão para mover assinaturas para grupos de gerenciamento.

O ambiente possui as seguintes restrições:

  • A empresa tem uma política interna que proíbe a concessão de roles com escopo no Tenant Root Group para usuários que não sejam da equipe de plataforma central.
  • Existe um processo de onboarding de projetos que já é executado por um service principal dedicado, chamado sp-onboarding, usado para automações pós-provisionamento.
  • A equipe de plataforma é composta por apenas duas pessoas e não pode revisar manualmente cada novo projeto.
  • A solução deve funcionar sem intervenção manual a partir da próxima semana.

Qual é a ação correta a tomar neste momento?

A) Conceder a role Management Group Contributor no Tenant Root Group a todos os Owners de assinaturas, para que possam mover suas próprias assinaturas autonomamente.

B) Atribuir a role Management Group Contributor no grupo MG-Projetos ao sp-onboarding e adicionar a etapa de movimentação de assinatura ao processo automatizado de onboarding já existente.

C) Criar um alerta no Azure Monitor para notificar a equipe de plataforma sempre que uma nova assinatura aparecer diretamente sob o Tenant Root Group, para que a movimentação seja feita manualmente.

D) Atribuir a role Owner no grupo MG-Projetos ao sp-onboarding, garantindo que ele tenha permissão completa para gerenciar todos os recursos dentro do grupo de destino.

Cenário 3 — Causa Raiz​

Um administrador recebe o seguinte erro ao tentar mover o grupo de gerenciamento MG-Regional para dentro do grupo MG-Global via portal do Azure:

Error: MoveManagementGroupFailed
Message: The management group 'MG-Global' cannot be a descendant of 'MG-Regional'.
Code: ParentChangeNotAllowed

O ambiente possui a seguinte estrutura hierárquica no momento da tentativa:

Tenant Root Group
└── MG-Regional
    ├── MG-Global          <-- grupo que será o novo pai
    │   └── MG-EMEA
    └── MG-Americas

O administrador informa que tem a role Management Group Contributor em ambos os grupos e que verificou que nenhum lock de gerenciamento está ativo. Ele também menciona que tentou a operação fora do horário comercial para evitar impacto, e que o grupo MG-EMEA está vazio no momento.

Qual é a causa raiz do erro?

A) A role Management Group Contributor não é suficiente para operações de movimentação de grupos de gerenciamento; a operação exige a role Owner no Tenant Root Group.

B) Grupos de gerenciamento com grupos filhos ativos não podem ser movidos; o grupo MG-Global precisa estar vazio antes da movimentação.

C) A operação criaria um ciclo na hierarquia, pois MG-Global é atualmente um descendente de MG-Regional, tornando MG-Regional descendente de seu próprio filho.

D) O horário da operação coincidiu com um processo de sincronização de hierarquia do Azure, que bloqueia movimentações de grupos temporariamente.

Cenário 4 — Sequência de Diagnóstico​

Um administrador recebe o seguinte relato: "Apliquei uma mudança na hierarquia de grupos de gerenciamento ontem e agora algumas equipes não conseguem mais acessar recursos que acessavam normalmente."

O administrador precisa investigar a causa. Os seguintes passos de investigação estão disponíveis, mas em ordem incorreta:

  1. Verificar o log de atividades do Azure para identificar quais alterações foram feitas na hierarquia nas últimas 24 horas.
  2. Confirmar se as role assignments herdadas do grupo de gerenciamento anterior ainda estão ativas no novo escopo.
  3. Identificar em qual grupo de gerenciamento as assinaturas afetadas estavam antes e onde estão agora.
  4. Verificar se as equipes afetadas estão conseguindo autenticar no Microsoft Entra ID sem erros.
  5. Comparar as role assignments efetivas dos usuários afetados antes e depois da mudança hierárquica.

Qual é a sequência correta de investigação?

A) 4 → 1 → 3 → 2 → 5

B) 1 → 3 → 2 → 5 → 4

C) 1 → 4 → 3 → 5 → 2

D) 3 → 1 → 4 → 2 → 5

Gabarito e Explicações​

Gabarito — Cenário 1​

Resposta: B

Explique:

  • A pista definitiva está na saída coletada: Last evaluated: Never e Compliance state: Not started. Esses campos indicam que o ciclo de avaliação do Azure Policy ainda não processou a atribuição. O Azure Policy não é instantâneo: após uma nova atribuição, o mecanismo de avaliação pode levar entre 5 e 30 minutos para processar o escopo completo.
  • O tempo decorrido entre o assignment (09:00) e a investigação (09:47) é de menos de uma hora, e a saída confirma que nenhuma avaliação ocorreu ainda. O recurso foi criado dentro dessa janela.
  • A informação sobre MG-Dados não ter exclusões de escopo e a assinatura estar corretamente listada são dados relevantes que eliminam problemas de configuração de escopo, direcionando o diagnóstico para latência de avaliação.
  • A alternativa A representa um erro conceitual clássico: uma policy de efeito Audit não bloqueia nem substitui um Deny herdado. As duas coexistem.
  • A alternativa C é falsa: a propagação para grupos filhos é automática e não requer configuração adicional.
  • A alternativa D descreve um comportamento que não existe na plataforma: o Azure Policy não possui janelas de manutenção que suspendem avaliações.
  • O distrator mais perigoso é o C, porque levaria o administrador a alterar o escopo da policy desnecessariamente, potencialmente quebrando a configuração correta que já estava em vigor.

Gabarito — Cenário 2​

Resposta: B

Explique:

  • A restrição central do cenário é que a solução deve ser automatizada, funcionar sem intervenção manual e não violar a política interna que proíbe roles com escopo no Tenant Root Group para usuários fora da equipe de plataforma.
  • O sp-onboarding já existe, já é confiável e já executa automações pós-provisionamento. Conceder a ele a role Management Group Contributor especificamente no grupo MG-Projetos atende às três restrições simultaneamente: é automatizado, não concede acesso ao Tenant Root Group e não depende de revisão manual.
  • A alternativa A viola diretamente a política interna da empresa ao conceder acesso com escopo no Tenant Root Group a usuários que não são da equipe de plataforma.
  • A alternativa C atende parcialmente (cria visibilidade), mas mantém a dependência de ação manual da equipe de plataforma, contradizendo o requisito de escala e o prazo.
  • A alternativa D concede a role Owner ao sp-onboarding no grupo MG-Projetos, o que é excessivo: a movimentação de assinatura requer apenas Management Group Contributor no destino, não Owner. Seguir o princípio de menor privilégio é parte da decisão correta aqui.

Gabarito — Cenário 3​

Resposta: C

Explique:

  • A mensagem de erro The management group 'MG-Global' cannot be a descendant of 'MG-Regional' e o código ParentChangeNotAllowed descrevem precisamente um problema de ciclo hierárquico. A estrutura atual mostra que MG-Global já é filho de MG-Regional. Tornar MG-Regional filho de MG-Global criaria uma referência circular, o que é estruturalmente impossível em uma hierarquia de árvore.
  • A informação sobre o horário da operação e o grupo MG-EMEA estar vazio são dados irrelevantes introduzidos propositalmente. Eles não têm nenhuma relação com o erro e servem para desviar o diagnóstico para causas de disponibilidade ou estado dos filhos.
  • A alternativa A é plausível como equívoco de permissão, mas o erro não é de autorização (AuthorizationFailed); é de lógica estrutural (ParentChangeNotAllowed). As permissões não são o problema aqui.
  • A alternativa B confunde o conceito de grupo vazio com pré-requisito de movimentação. Grupos de gerenciamento podem ser movidos com filhos; o impedimento é topológico, não sobre o estado dos filhos.
  • O distrator mais perigoso é o A, pois levaria o administrador a escalar permissões desnecessariamente, gastando tempo e potencialmente criando riscos de segurança, enquanto o problema real permanece sem solução.

Gabarito — Cenário 4​

Resposta: B

Explique:

  • A sequência correta segue a lógica de diagnóstico progressivo do mais amplo para o mais específico, sem desviar para hipóteses desnecessárias antes de confirmar a mudança que causou o problema.
  • Passo 1 (log de atividades): confirmar o que foi alterado é sempre o ponto de partida quando há um evento recente declarado. Sem saber o que mudou exatamente, qualquer investigação subsequente é especulação.
  • Passo 3 (localização das assinaturas): após confirmar a mudança, identificar quais assinaturas foram movidas e para onde é a etapa que conecta a alteração ao impacto relatado.
  • Passo 2 (role assignments herdadas): com a movimentação confirmada e as assinaturas identificadas, verificar se as role assignments do grupo anterior ainda são efetivas no novo escopo é a hipótese mais provável para perda de acesso.
  • Passo 5 (comparação de effective permissions): após levantar a hipótese de perda de herança, comparar as permissões efetivas antes e depois confirma ou refuta a hipótese com evidência concreta.
  • Passo 4 (autenticação no Entra ID): verificar autenticação é um passo válido em troubleshooting de acesso em geral, mas neste contexto, com uma mudança hierárquica declarada como evento recente, a autenticação é a hipótese menos provável e deve ser investigada por último, apenas se os passos anteriores não explicarem a falha.
  • A sequência A (começando pelo passo 4) representa o erro de investigar a camada de identidade antes de investigar a camada de autorização e estrutura, que é onde a mudança ocorreu.

Árvore de Troubleshooting: Configure management groups​

100%
Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Legenda:

CorSignificado
Azul escuroSintoma inicial (ponto de entrada)
AzulPergunta diagnóstica (nó de decisão)
VermelhoCausa identificada
LaranjaValidação ou verificação intermediária

Para usar esta árvore diante de um problema real, comece pelo nó raiz e responda cada pergunta de decisão com base no que você observa diretamente no ambiente, sem presumir a causa. Siga o caminho indicado pela sua resposta até alcançar um nó vermelho de causa identificada. Se chegar a um nó laranja de validação, execute a verificação sugerida antes de continuar. Ao identificar a causa, use a descrição do nó como ponto de partida para a ação corretiva.