O design de governança e conformidade do AZ-305 vai muito além da memorização — exige a capacidade de julgar qual ferramenta se encaixa em cada situação. O design de hierarquias de Management Group, a seleção do efeito correto no Azure Policy, a governança de custos, as estratégias de tags e a infraestrutura como código (IaC) são conceitos profundamente interligados que aparecem juntos nas questões da prova. Este artigo analisa 37 questões reais do exame e destila os padrões mais frequentes e os critérios de decisão mais importantes.
---
Management Groups e design de hierarquia de assinaturas
Um Management Group é um contêiner que agrupa seu ambiente Azure do ponto de vista da governança. A hierarquia tem a seguinte estrutura:
As políticas e os papéis atribuídos em um nível superior são herdados automaticamente por todos os níveis inferiores. Se você aplicar a política "Permitir apenas Korea Central" ao Production Management Group, todas as três assinaturas abaixo dele serão governadas por essa política. O Development Management Group, que é um nó irmão (sibling), não será afetado.
Quando aparecer uma questão sobre hierarquia de Management Groups na prova, a primeira coisa a verificar é: "A assinatura alvo é descendente do nó de atribuição da política?" Mesmo que duas assinaturas pertençam ao mesmo tenant, se estiverem em ramos diferentes da árvore de Management Groups, as políticas não se propagarão entre elas.
Os seletores de recursos não ampliam o escopo de uma política; eles filtram quais recursos, dentro do escopo já definido, serão avaliados. O escopo de atribuição do Azure Policy se limita a três níveis: Management Group, Assinatura ou Grupo de recursos. Não é possível atribuir uma política a um recurso individual ou a um tenant do Entra ID como unidade.
---
Azure Policy e iniciativas
O Azure Policy é um sistema que aplica regras automaticamente. Se o RBAC controla "quem pode fazer o quê", o Policy controla "onde, como e sob quais condições as implantações podem ocorrer".
Os cinco efeitos do Policy
| Efeito | Comportamento | Caso de uso principal | |--------|--------------|----------------------| | Deny | Rejeita imediatamente a solicitação de implantação no nível do ARM | Bloquear regiões ou tipos de recursos não autorizados | | Audit | Registra a não conformidade sem bloquear | Avaliar o escopo do impacto no início do rollout de uma política | | Append | Adiciona novos valores junto aos existentes (sem sobrescrever) | Adição simples de tags preservando os valores atuais | | Modify | Adiciona ou altera propriedades e tags existentes + suporte a remediação | Corrigir tags automaticamente, herdar tags do grupo de recursos | | DeployIfNotExists | Implanta automaticamente um recurso relacionado quando uma configuração está ausente | Habilitar TDE automaticamente, instalar agentes automaticamente |
Modify e Append são fáceis de confundir. Sempre que você ver "modificar tags de recursos existentes e aplicar retroativamente", escolha Modify. O Append não consegue sobrescrever valores existentes e não suporta tarefas de remediação.
As políticas com DeployIfNotExists precisam incluir . Isso concede à Managed Identity o papel de RBAC necessário para modificar o recurso alvo. A entidade que executa a remediação é a System-assigned Managed Identity vinculada à atribuição da política — não uma conta de usuário. Para tarefas com privilégios mínimos, como alterações de tags, basta atribuir apenas o papel Tag Contributor.
Uma iniciativa agrupa várias políticas em um único pacote. Se você combinar uma "política de restrição de regiões" e uma "política de restrição de tamanho de VM" em uma iniciativa, ao atribuir essa iniciativa uma única vez a uma assinatura, ambas as políticas são aplicadas simultaneamente.
As avaliações de políticas são executadas automaticamente a cada 24 horas por padrão. Para avaliação imediata, use pela REST API ou execute . Para notificações instantâneas acionadas por eventos de não conformidade, combine o Azure Event Grid com o Logic Apps.
!Os 5 efeitos do Azure Policy
Governança de custos e Cost Management
Se você precisa rastrear custos por projeto em 20 ou mais assinaturas sem reestruturar o layout de assinaturas, adicione tags a todos os recursos com chaves como , e , e depois filtre os custos por valor de tag no Microsoft Cost Management.
O recurso de orçamento (Budget) no Cost Management envia alertas automáticos por e-mail ou por Action Groups quando os custos reais ou previstos atingem um limite configurado. Você pode definir até cinco limites. O Azure Advisor oferece recomendações de economia de custos, mas não fornece alertas por excesso de orçamento.
Para cargas de trabalho que operam 24/7, considere as Reserved Instances. Com um compromisso de um ou três anos, é possível economizar até 72% em comparação com os preços de pagamento por uso em VMs, SQL Database, App Service e outros serviços, sem afetar a disponibilidade nem o SLA. As Spot VMs podem reduzir os custos em até 90%, mas o Azure pode encerrá-las a qualquer momento, tornando-as inadequadas para cargas de trabalho de produção sempre ativas.
---
Estratégia de tags e bloqueios de recursos
As tags funcionam como post-its colados aos recursos. Você associa pares chave-valor como e para carregar metadados. Um comportamento importante a lembrar: as tags não são herdadas automaticamente de níveis superiores para inferiores. Adicionar uma tag a um grupo de recursos não adiciona automaticamente essa tag aos recursos dentro dele.
Para impor tags obrigatórias em todos os recursos, use tanto o efeito Deny (bloquear novas implantações sem a tag) quanto o efeito Modify (corrigir retroativamente os recursos existentes). A política interna "Inherit a tag from the resource group" também usa o efeito Modify para propagar tags automaticamente.
Os Resource Locks protegem os recursos de produção contra exclusões ou modificações acidentais.
Bloqueio Delete: impede apenas a exclusão; alterações de configuração ainda são possíveis. Bloqueio ReadOnly: bloqueia todas as operações de escrita — nem modificações nem exclusões são possíveis.
Os Resource Locks são independentes do RBAC. Mesmo um usuário com permissões de Owner não pode excluir ou modificar um recurso bloqueado. Se você precisar impedir uma ação específica em um recurso (por exemplo, bloquear a atribuição de um IP público) mesmo para Contributors, use Azure Policy Deny em vez de um bloqueio.
---
Tabelas comparativas de serviços
Guia de seleção do efeito do Policy
| Cenário | Efeito escolhido | Motivo | |---------|-----------------|--------| | Bloquear implantações em regiões não autorizadas | Deny | Controle preventivo no nível do ARM | | Identificar recursos não conformes sem bloquear | Audit | Somente detecção, sem aplicação | | Herdar tags do grupo de recursos para recursos filhos | Modify | Modifica propriedades existentes + remediação | | Aplicar retroativamente tags ausentes a recursos existentes | Modify | Suporta tarefas de remediação | | Auto-instalar agente de diagnóstico na criação de VM | DeployIfNotExists | Implanta automaticamente o recurso/configuração ausente | | Habilitar TDE automaticamente no SQL Database | DeployIfNotExists | Implanta configuração ausente + remediação | | Bloquear implantação de recursos sem tags | Deny | Controle preventivo |
Comparativo de ferramentas de governança
| Ferramenta | Função principal | Limitação | |------------|----------------|-----------| | Azure Policy | Avaliar e aplicar conformidade (controle de condições) | Não pode atribuir papéis nem implantar templates ARM | | Azure RBAC | Controlar permissões de operação de usuários e grupos | Não pode restringir condições de implantação (região, SKU) | | Azure Blueprints | Pacote de Policy + papéis + ARM + RG | Não pode ser compartilhado entre tenants | | Resource Lock | Bloquear exclusão e modificação (incluindo Owners) | Não pode detectar não conformidade nem auto-remediar | | Cost Management | Rastreamento de custos, orçamentos e alertas | Não pode controlar a implantação de recursos |
---
Pontos de decisão que confundem com frequência na prova
Cenário 1: Uma política de localização para o grupo de recursos foi configurada, mas os recursos ainda são implantados em outras regiões
A política de localização do grupo de recursos controla apenas em qual região o próprio grupo de recursos é criado. Serviços como App Service ou SQL Database podem ser implantados em uma região diferente à do seu grupo de recursos. Você precisa adicionar uma política Deny separada com escopo no nível da assinatura que tenha como alvo a localização do recurso. A política interna "Allowed locations" controla simultaneamente tanto a localização do grupo de recursos quanto a dos recursos individuais.
Cenário 2: Calcular o número mínimo de definições e atribuições no Blueprints
N tenants + definições mínimas → N definições (Blueprints não pode cruzar limites de tenant) M assinaturas + atribuições mínimas → M atribuições (cada atribuição se aplica 1:1 por assinatura)
Dentro de um único tenant, uma definição pode ter múltiplas atribuições apontando para assinaturas diferentes. Em tenants diferentes, você precisa criar uma definição separada para cada tenant.
Cenário 3: Controle preventivo vs. detecção reativa
Quando você ver "impedir a própria implantação", escolha Azure Policy Deny. O painel de conformidade do Microsoft Defender for Cloud é uma ferramenta reativa — exibe as violações depois que a implantação já ocorreu. Para bloquear algo antes de ser implantado (preventivo), Azure Policy Deny é a única opção.
Cenário 4: Gerenciamento centralizado de múltiplos tenants de clientes
Quando um MSP precisa gerenciar recursos de múltiplos tenants de clientes a partir de um único console no próprio tenant, use o Azure Lighthouse. Ele permite o acesso entre tenants via delegação do Azure Resource Manager, sem instalação de agentes. O Azure Arc