Fundamentação Teórica: Configure Management Groups

1. Intuição Inicial

Imagine uma empresa multinacional com subsidiárias em vários países. Cada subsidiária tem suas próprias operações, seus próprios times e seus próprios projetos. A matriz precisa garantir que determinadas políticas corporativas sejam seguidas por todos: conformidade fiscal, padrões de segurança, restrições regulatórias por país. Fazer isso subsidiária por subsidiária seria inviável em escala.

No Azure, quando você tem múltiplas subscriptions, o problema é exatamente esse: como aplicar governança em escala sobre dezenas ou centenas de subscriptions sem precisar configurar RBAC, Policies e Locks individualmente em cada uma?

A resposta é o Management Group: um contêiner que agrupa subscriptions (e outros Management Groups) em uma hierarquia, permitindo aplicar governança uma única vez no nível adequado com herança automática para tudo abaixo.

Um Management Group com uma Policy atribuída propaga essa Policy para todas as subscriptions dentro dele, que propagam para todos os Resource Groups, que propagam para todos os recursos. Uma ação, impacto em milhares de recursos.

2. Contexto

Onde Management Groups se encaixam na hierarquia Azure

100%

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

Esta estrutura é o Azure Landing Zone, a arquitetura de referência da Microsoft para organizações enterprise. Cada nível da hierarquia tem um propósito específico.

Por que Management Groups existem

Antes dos Management Groups, cada subscription era uma ilha de governança isolada. Para aplicar as mesmas 50 policies de segurança em 20 subscriptions, era necessário criar 1.000 policy assignments individuais. Qualquer mudança exigia 20 atualizações. Qualquer nova subscription começava sem governança até ser configurada manualmente.

Management Groups resolvem esse problema: uma única atribuição de Policy ou RBAC no Management Group cobre automaticamente todas as subscriptions abaixo, presentes e futuras. Novas subscriptions adicionadas ao MG herdam toda a governança imediatamente.

O que depende de Management Groups

Governance corporativa em escala (Azure Policy no nível de MG)
RBAC centralizado para múltiplas subscriptions
Relatórios consolidados de custo via Cost Management
Compliance reports do Microsoft Defender for Cloud em escala
O próprio padrão Azure Landing Zone é baseado em Management Groups

3. Construção dos Conceitos

3.1 O Tenant Root Group

Quando um Azure AD Tenant é criado, o Azure cria automaticamente um Tenant Root Group (também chamado de Root Management Group). Este é o Management Group raiz da hierarquia, o ancestral de todos os outros Management Groups e subscriptions.

Características do Tenant Root Group:

Característica	Detalhe
Nome padrão	Tenant Root Group
ID	Igual ao ID do Azure AD Tenant
Pode ser renomeado	Sim
Pode ser deletado	Não
Pai	Não tem (é a raiz)
Quem tem acesso por padrão	Global Administrator (com elevação)

O Tenant Root Group é especial porque qualquer Policy ou RBAC atribuído aqui afeta absolutamente todos os recursos do tenant. Por esse motivo, a atribuição de qualquer coisa no Root Group deve ser feita com extrema cautela e revisão cuidadosa.

3.2 Quem pode gerenciar o Root Group

Por padrão, ninguém tem acesso ao Tenant Root Group ao criar o tenant, nem mesmo o Global Administrator do Azure AD. Para ter acesso ao Root Group, o Global Administrator precisa primeiro elevar seu próprio acesso:

No Azure AD > Properties
Ativar "Access management for Azure resources"
Isso concede ao Global Administrator a role User Access Administrator no Root Group
A partir daí, pode gerenciar o Root Group e delegar acesso a outros

Esta elevação é intencional: protege o Root Group de acesso acidental e obriga uma ação consciente para acessá-lo.

3.3 Estrutura de um Management Group

100%

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

Regras estruturais:

Um Management Group pode ter como filhos: outros Management Groups e Subscriptions
Um Management Group (exceto o Root) tem exatamente um pai
Uma Subscription pode pertencer a apenas um Management Group por vez
A profundidade máxima da hierarquia é 6 níveis abaixo do Root Group (Root não conta)
Um tenant pode ter no máximo 10.000 Management Groups

3.4 Herança de governança

A herança é o mecanismo central dos Management Groups. Funciona exatamente como a herança de RBAC e Policy em escopos menores, mas em escala:

100%

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

A Policy "Regiões permitidas Brasil" atribuída no Root Group se aplica a Sub1 e Sub2 (e a todas as outras subscriptions do tenant) sem nenhuma ação adicional.

3.5 Movimentação de subscriptions entre Management Groups

Uma subscription pode ser movida de um Management Group para outro. No momento da movimentação:

As policies e role assignments do MG de origem deixam de se aplicar imediatamente
As policies e role assignments do MG destino passam a se aplicar imediatamente
Os recursos dentro da subscription não são afetados tecnicamente
Recursos podem ficar temporariamente non-compliant se policies do novo MG forem mais restritivas

100%

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

4. Visão Estrutural

Padrão Azure Landing Zone em detalhe

O padrão de referência da Microsoft organiza Management Groups em camadas com propósitos específicos:

100%

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

Por que o MG Decommissioned? Quando uma subscription precisa ser descomissionada, movê-la para este MG aplica automaticamente políticas que bloqueiam novos recursos e restringem acesso. Isso padroniza o processo de offboarding de subscriptions.

Políticas típicas por nível de hierarquia

Nível	Exemplos de Policy	Justificativa
Root	Regiões permitidas, security baseline, logging obrigatório	Vale para toda a organização sem exceção
Platform	Configurações de rede específicas, monitoramento avançado	Apenas infraestrutura compartilhada
Landing Zones	Tags obrigatórias, backup policies	Todas as aplicações
Corp	Private endpoints, VNet integration obrigatória	Apps com conectividade corporativa
Online	WAF obrigatório, certificados TLS	Apps expostas à internet
Sandbox	SKUs limitados, sem dados confidenciais	Experimentação controlada

5. Funcionamento na Prática

Criação e configuração de um Management Group

O processo de configuração de Management Groups segue uma ordem lógica:

100%

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

Comportamentos não óbvios

Management Groups não têm custos diretos. Criar um Management Group não gera cobrança. O custo é apenas dos recursos dentro das subscriptions. MGs são objetos de gerenciamento sem overhead financeiro.

Renomear um Management Group não muda seu ID. O nome (displayName) é editável. O ID (usado em scripts, policies, API calls) é definido na criação e imutável. Sempre use o ID em automação, nunca o nome.

Deletar um Management Group remove apenas o contêiner, não as subscriptions. Se você deletar um MG que contém subscriptions, o Azure não deleta as subscriptions. Elas são movidas para o MG pai. Mas um MG com subscriptions não pode ser deletado diretamente: primeiro você precisa mover ou remover todas as subscriptions e MGs filhos.

Policies no Root Group afetam até as subscriptions de plataforma da Microsoft. Algumas subscriptions internas da Microsoft para gerenciamento do Azure ficam visíveis no Root Group de alguns tenants. Policies muito restritivas no Root Group podem afetar essas subscriptions. Por isso, verificar impacto no Root Group antes de aplicar qualquer Deny.

Uma subscription sem MG explícito vai para o Root Group. Ao criar uma nova subscription (especialmente em contas PAYG ou dev), ela é automaticamente colocada no Tenant Root Group se não houver processo de vending que a coloque no MG correto. Isso significa que ela herda políticas do Root Group mas não herda as políticas mais específicas dos MGs de aplicação.

6. Formas de Implementação

Portal do Azure

Quando usar: configuração inicial da hierarquia, movimentação pontual de subscriptions, visualização da estrutura

Acessar Management Groups:

Portal > Management Groups (buscar no search ou no menu All services)
Visualizar a hierarquia atual
Clicar em um MG para ver detalhes, subscriptions e políticas

Criar um Management Group:

Portal > Management Groups > + Create
Definir Management Group ID (alfanumérico, hifens, underscores, máximo 90 caracteres)
Definir Display Name (nome legível, editável posteriormente)
Selecionar o pai (Root ou outro MG existente)
Submit

Mover subscription para um Management Group:

Portal > Management Groups > selecionar o MG destino
Aba Subscriptions > + Add
Selecionar a subscription
Confirmar

Ou via a própria subscription:

Portal > Subscriptions > selecionar subscription
Change management group
Selecionar o MG destino

Limitação: não reproduzível, sem controle de versão, lento para estruturas complexas.

Azure CLI

# Elevar acesso ao Root Group (feito no portal, não via CLI diretamente)
# Mas verificar se o acesso foi elevado:
az role assignment list \
  --scope "/" \
  --query "[?roleDefinitionName=='User Access Administrator']" \
  --output table

# Criar Management Group
az account management-group create \
  --name "mg-landing-zones" \
  --display-name "Landing Zones"

# Criar MG filho de outro MG
az account management-group create \
  --name "mg-corp" \
  --display-name "Corporativo" \
  --parent "mg-landing-zones"

# Listar todos os Management Groups
az account management-group list --output table

# Ver hierarquia completa (recursivo)
az account management-group show \
  --name "mg-landing-zones" \
  --expand \
  --recurse \
  --output json

# Mover subscription para um Management Group
az account management-group subscription add \
  --name "mg-corp" \
  --subscription "<sub-id>"

# Remover subscription de um Management Group
# (subscription vai para o MG pai)
az account management-group subscription remove \
  --name "mg-corp" \
  --subscription "<sub-id>"

# Mover Management Group para outro pai
az account management-group update \
  --name "mg-corp" \
  --parent-id "mg-landing-zones-v2"

# Renomear um Management Group (apenas o displayName)
az account management-group update \
  --name "mg-corp" \
  --display-name "Corporativo - Americas"

# Deletar Management Group (deve estar vazio)
az account management-group delete --name "mg-temp"

# Atribuir Policy em um Management Group
az policy assignment create \
  --name "regioes-permitidas-brasil" \
  --display-name "Apenas regioes brasileiras" \
  --policy "e56962a6-4747-49cd-b67b-bf8b01975c4c" \
  --scope "/providers/Microsoft.Management/managementGroups/mg-landing-zones" \
  --params '{"listOfAllowedLocations": {"value": ["brazilsouth", "brazilsoutheast"]}}'

# Atribuir RBAC em Management Group
az role assignment create \
  --assignee "grupo-auditoria@empresa.com" \
  --role "Reader" \
  --scope "/providers/Microsoft.Management/managementGroups/mg-landing-zones"

# Listar policies atribuídas em um MG
az policy assignment list \
  --scope "/providers/Microsoft.Management/managementGroups/mg-landing-zones" \
  --output table

# Listar role assignments em um MG
az role assignment list \
  --scope "/providers/Microsoft.Management/managementGroups/mg-landing-zones" \
  --output table

Azure PowerShell

# Criar Management Group
New-AzManagementGroup `
  -GroupId "mg-landing-zones" `
  -DisplayName "Landing Zones"

# Criar MG filho
New-AzManagementGroup `
  -GroupId "mg-corp" `
  -DisplayName "Corporativo" `
  -ParentId "/providers/Microsoft.Management/managementGroups/mg-landing-zones"

# Listar Management Groups
Get-AzManagementGroup | Select-Object Name, DisplayName, ParentId

# Mover subscription para MG
New-AzManagementGroupSubscription `
  -GroupId "mg-corp" `
  -SubscriptionId "<sub-id>"

# Ver hierarquia recursiva
Get-AzManagementGroup `
  -GroupId "mg-landing-zones" `
  -Expand `
  -Recurse

# Atribuir Policy em MG
$policyDef = Get-AzPolicyDefinition -Name "e56962a6-4747-49cd-b67b-bf8b01975c4c"

New-AzPolicyAssignment `
  -Name "regioes-brasil" `
  -DisplayName "Apenas regioes brasileiras" `
  -Scope "/providers/Microsoft.Management/managementGroups/mg-landing-zones" `
  -PolicyDefinition $policyDef `
  -PolicyParameterObject @{
    listOfAllowedLocations = @{
      value = @("brazilsouth", "brazilsoutheast")
    }
  }

# Atribuir RBAC em MG
New-AzRoleAssignment `
  -ObjectId "<group-object-id>" `
  -RoleDefinitionName "Reader" `
  -Scope "/providers/Microsoft.Management/managementGroups/mg-landing-zones"

# Remover subscription de MG
Remove-AzManagementGroupSubscription `
  -GroupId "mg-corp" `
  -SubscriptionId "<sub-id>"

# Deletar MG vazio
Remove-AzManagementGroup -GroupId "mg-temp"

Bicep para Management Groups como código

Como Management Groups existem acima do nível de Subscription, o deployment requer targetScope = 'tenant':

// arquivo: management-groups.bicep
targetScope = 'tenant'

// MG raiz de Landing Zones
resource mgLandingZones 'Microsoft.Management/managementGroups@2021-04-01' = {
  name: 'mg-landing-zones'
  properties: {
    displayName: 'Landing Zones'
  }
}

// MG filho: Corporativo
resource mgCorp 'Microsoft.Management/managementGroups@2021-04-01' = {
  name: 'mg-corp'
  properties: {
    displayName: 'Corporativo'
    details: {
      parent: {
        id: mgLandingZones.id
      }
    }
  }
}

// MG filho: Online
resource mgOnline 'Microsoft.Management/managementGroups@2021-04-01' = {
  name: 'mg-online'
  properties: {
    displayName: 'Online'
    details: {
      parent: {
        id: mgLandingZones.id
      }
    }
  }
}

// Associar subscription ao MG Corporativo
resource subAssociation 'Microsoft.Management/managementGroups/subscriptions@2021-04-01' = {
  parent: mgCorp
  name: '<subscription-id>'
}

Para deploy de template no nível de tenant:

az deployment tenant create \
  --location "brazilsouth" \
  --template-file "management-groups.bicep"

Terraform

# Management Group principal
resource "azurerm_management_group" "landing_zones" {
  display_name = "Landing Zones"
  name         = "mg-landing-zones"
  # parent_management_group_id omitido = filho do Root Group
}

# MG filho
resource "azurerm_management_group" "corp" {
  display_name               = "Corporativo"
  name                       = "mg-corp"
  parent_management_group_id = azurerm_management_group.landing_zones.id
}

resource "azurerm_management_group" "online" {
  display_name               = "Online"
  name                       = "mg-online"
  parent_management_group_id = azurerm_management_group.landing_zones.id
}

# Associar subscription a um MG
resource "azurerm_management_group_subscription_association" "prod" {
  management_group_id = azurerm_management_group.corp.id
  subscription_id     = "/subscriptions/<sub-id>"
}

# Policy assignment no MG
resource "azurerm_management_group_policy_assignment" "allowed_regions" {
  name                 = "allowed-regions-brazil"
  management_group_id  = azurerm_management_group.landing_zones.id
  policy_definition_id = "/providers/Microsoft.Authorization/policyDefinitions/e56962a6-4747-49cd-b67b-bf8b01975c4c"
  display_name         = "Apenas regioes brasileiras"

  parameters = jsonencode({
    listOfAllowedLocations = {
      value = ["brazilsouth", "brazilsoutheast"]
    }
  })
}

# RBAC no MG
resource "azurerm_role_assignment" "reader_audit" {
  scope                = azurerm_management_group.landing_zones.id
  role_definition_name = "Reader"
  principal_id         = "<group-object-id>"
}

7. Controle e Segurança

Quem pode gerenciar Management Groups

Ação	Permissão necessária
Criar MG filho	Management Group Contributor no MG pai, ou Owner
Mover subscription para MG	Management Group Contributor no MG destino + Owner na subscription
Deletar MG	Management Group Contributor no MG (e MG deve estar vazio)
Atribuir Policy no MG	Resource Policy Contributor no escopo do MG
Atribuir RBAC no MG	Owner ou User Access Administrator no MG
Acessar o Root Group	User Access Administrator no Root (via elevação do Global Admin)

Built-in roles específicas para Management Groups

Role	Descrição
Management Group Contributor	Cria, move e deleta Management Groups; não atribui roles
Management Group Reader	Visualiza hierarquia e configurações; sem modificações

Estas roles existem especificamente para delegar gerenciamento da estrutura de MGs sem conceder Owner ou Contributor nos recursos.

Proteção contra mudanças não autorizadas na hierarquia

Configure um Activity Log Alert para detectar mudanças na hierarquia de Management Groups:

az monitor activity-log alert create \
  --name "Alerta-MG-Modificado" \
  --resource-group "rg-monitoramento" \
  --condition \
    category=Administrative \
    operationName=Microsoft.Management/managementGroups/write \
  --scope "/" \
  --action-group "/subscriptions/<sub-id>/resourceGroups/rg-monitoramento/providers/microsoft.insights/actionGroups/ag-alertas-criticos"

Qualquer criação, renomeação ou movimentação de Management Group gerará um alerta imediato.

8. Tomada de Decisão

Quando criar um Management Group vs. usar apenas Resource Groups

Situação	Solução	Motivo
Organização com 1-3 subscriptions	Resource Groups + Policy por subscription	Overhead de MGs não se justifica
4+ subscriptions com governança comum	Management Groups	Uma atribuição cobre múltiplas subscriptions
Diferentes requisitos de compliance por divisão	MGs por divisão de negócio	Isolamento de políticas por divisão
Ambientes prod/dev com governança diferente	MGs por tipo de ambiente	Políticas diferentes, herança isolada
Novas subscriptions frequentemente criadas	MGs obrigatório	Governança automática para novas subs

Design da hierarquia: profundidade vs. largura

Abordagem	Vantagens	Desvantagens
Hierarquia rasa (2-3 níveis)	Simples de entender, fácil de gerenciar	Menos granularidade para policies específicas
Hierarquia profunda (5-6 níveis)	Altíssima granularidade	Difícil de depurar herança, complexidade operacional
Hierarquia balanceada (3-4 níveis, recomendada)	Granularidade adequada sem complexidade excessiva	Requer planejamento inicial cuidadoso

Quantidade de Management Groups

Cenário	Recomendação
Startup ou PME	0 MGs (apenas Root + subscriptions)
Empresa média	4-8 MGs (Platform, Landing Zones, Sandbox + 1-2 filhos)
Enterprise	10-30 MGs seguindo o padrão Azure Landing Zone
Conglomerado multinacional	30-100 MGs com hierarquia por região e divisão

9. Boas Práticas

Planeje a hierarquia antes de implementar. Mudanças na hierarquia de MGs têm impacto imediato na governança de todas as subscriptions afetadas. Redesenhar a hierarquia depois que 50 subscriptions já estão posicionadas é trabalhoso e arriscado. Defina a estrutura no papel, valide com stakeholders e implemente via IaC.

Use IaC (Bicep/Terraform) para criar e gerenciar Management Groups. Management Groups são parte da infraestrutura organizacional e devem ser versionados como código. Isso garante reproduzibilidade, auditoria de mudanças e processo de revisão antes de aplicar alterações.

Nunca atribua Deny policies no Root Group sem testes extensivos. Uma Policy Deny no Root Group afeta 100% dos recursos do tenant, incluindo subscriptions de plataforma e qualquer subscription criada no futuro. Teste sempre em um MG filho antes de promover ao Root.

Mantenha o Root Group com apenas políticas verdadeiramente universais. O Root Group deve ter apenas o que vale para toda a organização sem exceção: regiões permitidas por regulação, logging mínimo obrigatório, tags de identificação de tenant. Tudo mais vai em MGs específicos.

Crie um MG Sandbox com políticas permissivas para experimentação. Desenvolvedores precisam de liberdade para experimentar. Um MG Sandbox com políticas relaxadas (sem Deny de regiões, sem requisitos de tags estritos, mas com limite de SKUs caros) permite inovação sem risco para produção.

Crie um MG Decommissioned para offboarding de subscriptions. Subscriptions que precisam ser descomissionadas devem ser movidas para um MG com policies que bloqueiam novos recursos e restringem acesso. Isso padroniza o processo e evita que subscriptions esquecidas acumulem custos.

Documente cada Management Group com propósito, owner e restrições. Um Management Group sem documentação de por que existe, quem é responsável e quais restrições impõe torna-se um mistério operacional. Use a descrição do MG e um documento de design para registrar essas informações.

Use grupos do Azure AD para RBAC em Management Groups. Atribuições de role em MGs devem ser feitas a grupos, não usuários individuais. Quando alguém entra ou sai da empresa, basta atualizar o grupo.

10. Erros Comuns

Erro	Por que acontece	Como evitar
Atribuir Deny policy no Root Group sem teste	Urgência, falta de processo	Testar sempre em MG filho com apenas uma subscription de teste
Não definir hierarquia antes de criar subscriptions	Começar rápido sem planejar	Definir estrutura de MGs como pré-requisito para qualquer subscription nova
Criar muitos níveis de hierarquia	Tentar mapear a estrutura organizacional 1:1	Limitar a 3-4 níveis; MGs são para governance, não organograma
Usar nome do MG em scripts em vez do ID	Nome é mais legível	O ID é imutável; o nome pode mudar
Não monitorar movimentações de subscriptions entre MGs	Acreditar que é raro acontecer acidentalmente	Activity Log Alert para operações em Management Groups
Esquecer que nova subscription vai para o Root	Falta de processo de vending	Automatizar o placement de novas subscriptions no MG correto
Deletar MG pai sem mover subscriptions filhas	Não saber que é bloqueado	O Azure bloqueia; mas saber disso evita surpresas
Aplicar RBAC muito permissivo no Root Group	Conveniência	Usar menor privilégio; Root Group herda para tudo

O erro mais impactante

Atribuir uma Policy Deny no Tenant Root Group com uma condição mal configurada. Por exemplo, uma Policy que nega recursos sem uma tag específica, mas a tag é case-sensitive e metade dos recursos usa "Environment" e metade usa "environment". O resultado: deployments falham em toda a organização até a Policy ser corrigida ou removida.

11. Operação e Manutenção

Auditoria da hierarquia

# Ver hierarquia completa do tenant
az account management-group list \
  --query "[].{Name:name, Display:displayName, Parent:properties.parent.name}" \
  --output table

# Ver todas as subscriptions e em qual MG estão
az account management-group entities list \
  --query "[?type=='Microsoft.Management/managementGroups/subscriptions'].{Name:displayName, ID:name, Parent:parent.displayName}" \
  --output table

# Verificar policies atribuídas em todos os MGs
for mg_id in $(az account management-group list --query "[].name" -o tsv); do
  echo "=== MG: $mg_id ==="
  az policy assignment list \
    --scope "/providers/Microsoft.Management/managementGroups/$mg_id" \
    --query "[].{Name:displayName, Policy:policyDefinitionId}" \
    --output table
done

# Verificar RBAC atribuído em todos os MGs
az role assignment list \
  --scope "/providers/Microsoft.Management/managementGroups/mg-landing-zones" \
  --include-inherited \
  --output table

Monitorar mudanças na hierarquia

# Ver histórico de mudanças em Management Groups
az monitor activity-log list \
  --resource-provider "Microsoft.Management" \
  --query "[?operationName.value=='Microsoft.Management/managementGroups/write' || operationName.value=='Microsoft.Management/managementGroups/subscriptions/write']" \
  --output table

Limites importantes de Management Groups

Limite	Valor
Management Groups por tenant	10.000
Níveis de profundidade (excluindo Root)	6
Subscriptions por Management Group	Sem limite documentado
Filhos diretos de um Management Group	Sem limite documentado
Role assignments por Management Group	500
Policy assignments por Management Group	500

O limite de 500 role assignments por Management Group é separado do limite de 4.000 por subscription. Atribuições no MG consomem do limite do MG, não das subscriptions abaixo.

12. Integração e Automação

Subscription Vending com posicionamento automático em MG

100%

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

Azure Landing Zone Accelerator

A Microsoft disponibiliza o Azure Landing Zone como código pronto para uso:

# Clonar o repositório do Azure Landing Zone (Terraform)
git clone https://github.com/Azure/terraform-azurerm-caf-enterprise-scale

# Configurar variáveis principais
cat > terraform.tfvars << EOF
root_id   = "empresa"
root_name = "Empresa Corp"
root_parent_id = "tenant-root-group-id"
EOF

# Deploy completo da hierarquia de MGs
terraform init
terraform plan
terraform apply

Isso cria toda a hierarquia de Management Groups (Platform, Landing Zones, Sandbox, Decommissioned e seus filhos), com policies e role assignments baseline já configurados.

Integração com Microsoft Defender for Cloud

O Defender for Cloud agrega scores de segurança por Management Group, dando uma visão consolidada de postura de segurança de todas as subscriptions:

# Ver secure score agregado por Management Group
az security secure-score list \
  --query "[].{Name:displayName, Score:currentScore.current, Max:currentScore.max, Percent:currentScore.percentage}" \
  --output table

Com Management Groups bem configurados, você consegue ver "o MG de Produção tem Secure Score de 78%" versus "o MG de Desenvolvimento tem 45%", permitindo priorizar investimentos de segurança onde mais importa.

13. Resumo Final

Pontos essenciais:

Management Groups são contêineres que agrupam subscriptions (e outros MGs) em uma hierarquia de governança
O Tenant Root Group é criado automaticamente para cada tenant e é o ancestral de toda a hierarquia
Herança é o mecanismo central: Policy e RBAC atribuídos em um MG aplicam-se a todas as subscriptions e recursos abaixo
A profundidade máxima da hierarquia é 6 níveis abaixo do Root Group
O limite máximo é de 10.000 Management Groups por tenant
Para acessar o Root Group, um Global Administrator precisa elevar seu acesso explicitamente

Diferenças críticas:

MG vs. Subscription: MG é contêiner de governança sem custo direto; Subscription é unidade de cobrança e recursos
MG vs. Resource Group: MG agrupa subscriptions; RG agrupa recursos dentro de uma subscription
ID vs. DisplayName do MG: ID é imutável (use em scripts); DisplayName é editável (nome legível)
Role assignment limit no MG (500) vs. na Subscription (4.000): contadores separados e independentes

O que precisa ser lembrado para o AZ-104:

Todo tenant tem um Tenant Root Group criado automaticamente com o mesmo ID do tenant
O Root Group não pode ser deletado
Uma subscription pertence a exatamente um MG por vez; pode ser movida entre MGs
O scope string de um MG é: /providers/Microsoft.Management/managementGroups/{managementGroupId}
Para criar um deployment que cria MGs, o targetScope deve ser tenant no Bicep e o comando é az deployment tenant create
Quando uma subscription é movida de MG, as policies e RBAC do MG de origem são removidos imediatamente e os do destino são aplicados imediatamente
Subscriptions novas sem placement explícito vão automaticamente para o Tenant Root Group
O limite de 500 role assignments por MG é diferente e independente do limite de 4.000 por subscription

1. Intuição Inicial​

2. Contexto​

Onde Management Groups se encaixam na hierarquia Azure​

Por que Management Groups existem​

O que depende de Management Groups​

3. Construção dos Conceitos​

3.1 O Tenant Root Group​

3.2 Quem pode gerenciar o Root Group​

3.3 Estrutura de um Management Group​

3.4 Herança de governança​

3.5 Movimentação de subscriptions entre Management Groups​

4. Visão Estrutural​

Padrão Azure Landing Zone em detalhe​

Políticas típicas por nível de hierarquia​

5. Funcionamento na Prática​

Criação e configuração de um Management Group​

Comportamentos não óbvios​

6. Formas de Implementação​

Portal do Azure​

Azure CLI​

Azure PowerShell​

Bicep para Management Groups como código​

Terraform​

7. Controle e Segurança​

Quem pode gerenciar Management Groups​

Built-in roles específicas para Management Groups​

Proteção contra mudanças não autorizadas na hierarquia​

8. Tomada de Decisão​

Quando criar um Management Group vs. usar apenas Resource Groups​

Design da hierarquia: profundidade vs. largura​

Quantidade de Management Groups​

9. Boas Práticas​

10. Erros Comuns​

O erro mais impactante​

11. Operação e Manutenção​

Auditoria da hierarquia​

Monitorar mudanças na hierarquia​

Limites importantes de Management Groups​

12. Integração e Automação​

Subscription Vending com posicionamento automático em MG​

Azure Landing Zone Accelerator​

Integração com Microsoft Defender for Cloud​

13. Resumo Final​

1. Intuição Inicial

2. Contexto

Onde Management Groups se encaixam na hierarquia Azure

Por que Management Groups existem

O que depende de Management Groups

3. Construção dos Conceitos

3.1 O Tenant Root Group

3.2 Quem pode gerenciar o Root Group

3.3 Estrutura de um Management Group

3.4 Herança de governança

3.5 Movimentação de subscriptions entre Management Groups

4. Visão Estrutural

Padrão Azure Landing Zone em detalhe

Políticas típicas por nível de hierarquia

5. Funcionamento na Prática

Criação e configuração de um Management Group

Comportamentos não óbvios

6. Formas de Implementação

Portal do Azure

Azure CLI

Azure PowerShell

Bicep para Management Groups como código

Terraform

7. Controle e Segurança

Quem pode gerenciar Management Groups

Built-in roles específicas para Management Groups

Proteção contra mudanças não autorizadas na hierarquia

8. Tomada de Decisão

Quando criar um Management Group vs. usar apenas Resource Groups

Design da hierarquia: profundidade vs. largura

Quantidade de Management Groups

9. Boas Práticas

10. Erros Comuns

O erro mais impactante

11. Operação e Manutenção

Auditoria da hierarquia

Monitorar mudanças na hierarquia

Limites importantes de Management Groups

12. Integração e Automação

Subscription Vending com posicionamento automático em MG

Azure Landing Zone Accelerator

Integração com Microsoft Defender for Cloud

13. Resumo Final