Laboratório de Troubleshooting: Implement and manage Azure Policy

Cenários de Diagnóstico

Cenário 1 — Causa Raiz

Um administrador criou uma política personalizada com efeito Deny para impedir a criação de contas de armazenamento fora das regiões brazilsouth e eastus2. A política foi publicada como definição no escopo da assinatura e, em seguida, atribuída ao grupo de gerenciamento raiz da organização.

Durante os testes, o time de desenvolvimento reporta que está conseguindo criar contas de armazenamento na região westeurope sem receber nenhuma mensagem de erro ou bloqueio.

O administrador verifica os seguintes fatos:

• A definição da política está visível no portal, com status Enabled
• A atribuição aparece listada no grupo de gerenciamento raiz
• O modo de avaliação da política está configurado como Default
• A assinatura onde os testes ocorrem foi criada há três semanas
• O time de desenvolvimento usa uma conta com a role Contributor na assinatura

az policy assignment list --scope "/providers/Microsoft.Management/managementGroups/mg-root"

[
  {
    "name": "restrict-regions",
    "enforcementMode": "DoNotEnforce",
    "policyDefinitionId": "/subscriptions/.../policyDefinitions/restrict-regions",
    "scope": "/providers/Microsoft.Management/managementGroups/mg-root"
  }
]

Qual é a causa raiz do comportamento observado?

A) A política foi definida no escopo da assinatura e não pode ser aplicada a partir de um grupo de gerenciamento. B) A atribuição está com enforcementMode configurado como DoNotEnforce, o que impede qualquer bloqueio. C) A role Contributor dos desenvolvedores tem permissão implícita para contornar políticas com efeito Deny. D) O modo de avaliação Default introduz um atraso de até 30 minutos antes de a política entrar em vigor.

---

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

A equipe de governança identificou que uma política com efeito DeployIfNotExists foi atribuída corretamente à assinatura de produção há cinco dias. A política deveria instalar automaticamente o agente do Azure Monitor em todas as VMs Windows. Novas VMs criadas após a atribuição estão recebendo o agente corretamente.

No entanto, o painel de conformidade mostra que 47 VMs existentes antes da atribuição ainda estão marcadas como não conformes, e nenhuma delas recebeu o agente.

A causa já foi confirmada: recursos pré-existentes não são tratados automaticamente pelo efeito DeployIfNotExists sem uma ação explícita do administrador.

O ambiente é de produção ativa, com janela de manutenção disponível apenas aos domingos. Hoje é quinta-feira. A equipe de segurança exige que a conformidade seja atingida antes do próximo domingo.

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

A) Reatribuir a política com o parâmetro enforcementMode definido como Default para forçar a reavaliação imediata de todos os recursos existentes. B) Criar uma remediation task para a atribuição existente, com escopo limitado às VMs não conformes, e monitorar o progresso de implantação. C) Excluir a atribuição atual e recriá-la para que o ciclo de avaliação inicial trate as VMs existentes como novos recursos. D) Aguardar a janela de manutenção de domingo para executar a remediação, pois a instalação de extensões em VMs de produção exige janela aprovada.

---

Cenário 3 — Causa Raiz

Um time de segurança atribuiu uma iniciativa contendo 12 políticas ao grupo de gerenciamento mg-corp. Uma das políticas da iniciativa exige que todas as contas de armazenamento tenham minimumTlsVersion igual a TLS1_2.

Três dias após a atribuição, o time percebe que contas de armazenamento com TLS1_0 ainda estão sendo criadas com sucesso em grupos de recursos dentro de mg-corp. O painel de conformidade mostra essas contas como não conformes, mas nenhuma criação foi bloqueada.

O administrador investiga e encontra os seguintes dados:

• A iniciativa está atribuída e visível no escopo correto
• O enforcementMode da atribuição da iniciativa é Default
• Todas as 12 políticas têm suas definições com status Enabled
• O grupo de recursos rg-storage-legacy possui uma exclusão configurada na atribuição da iniciativa
• As contas sendo criadas com TLS1_0 estão todas no grupo de recursos rg-storage-new

az policy assignment show \
  --name "security-initiative-assignment" \
  --scope "/providers/Microsoft.Management/managementGroups/mg-corp"

{
  "enforcementMode": "Default",
  "notScopes": [
    "/subscriptions/xxx/resourceGroups/rg-storage-legacy"
  ]
}

Qual é a causa raiz do comportamento observado?

A) A exclusão configurada em rg-storage-legacy está se propagando incorretamente para rg-storage-new devido a um bug de herança de escopo. B) O efeito da política de TLS dentro da iniciativa é Audit e não Deny, o que explica o registro sem bloqueio. C) Iniciativas não suportam o efeito Deny em políticas individuais; todas as políticas dentro de uma iniciativa são tratadas como Audit. D) O enforcementMode Default na atribuição da iniciativa desabilita o efeito Deny para políticas com parâmetros personalizados.

---

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

Um administrador recebe o seguinte relato: recursos estão sendo criados sem as tags obrigatórias, apesar de uma política com efeito Modify ter sido atribuída à assinatura para adicioná-las automaticamente.

O administrador precisa investigar a causa. Os passos disponíveis para diagnóstico são:

1. Verificar se a managed identity associada à atribuição possui a role necessária no escopo correto
2. Confirmar que o efeito da política na definição é realmente Modify e não Append ou Audit
3. Verificar se a atribuição existe no escopo esperado e está com enforcementMode igual a Default
4. Analisar o log de atividades de um recurso criado recentemente para identificar se a política foi avaliada e qual foi o resultado
5. Verificar se o recurso criado pertence a um tipo coberto pela condição if da definição da política

Qual é a sequência correta de diagnóstico?

A) 2, 3, 5, 1, 4 B) 3, 2, 5, 1, 4 C) 1, 2, 3, 4, 5 D) 4, 3, 2, 5, 1

---

Gabarito e Explicações

Gabarito — Cenário 1

Resposta: B

A saída do comando az policy assignment list mostra explicitamente "enforcementMode": "DoNotEnforce". Esse modo instrui o Azure Policy a avaliar os recursos e registrar conformidade, mas a nunca bloquear criações ou modificações, independentemente do efeito configurado na política. O efeito Deny é completamente neutralizado quando DoNotEnforce está ativo.

A pista determinante está no bloco de código do enunciado. O administrador que o lê com atenção encontra a causa sem precisar de nenhuma outra informação.

A informação sobre a assinatura ter sido criada há três semanas é irrelevante e foi incluída propositalmente para simular o ruído real de um diagnóstico, onde detalhes de contexto nem sempre têm relação com o problema.

O distrator mais perigoso é a alternativa D: o atraso de avaliação do ciclo Default existe, mas afeta a marcação de conformidade no painel, não a capacidade de bloqueio em tempo real de uma operação de criação. Agir com base nesse distrator levaria o administrador a aguardar um problema que nunca se resolveria sozinho.

---

Gabarito — Cenário 2

Resposta: B

A causa já foi declarada no enunciado: o efeito DeployIfNotExists não age retroativamente sem intervenção. A única forma de corrigir recursos pré-existentes é criando uma remediation task para a atribuição. Isso pode ser feito imediatamente, sem janela de manutenção, e o progresso pode ser monitorado em tempo real pelo portal ou via CLI.

A alternativa D parece prudente, mas ignora uma restrição crítica: a equipe de segurança exige conformidade antes de domingo, e aguardar a janela seria perder o prazo. Além disso, a criação de uma remediation task não é uma operação de manutenção que exige janela; ela agenda implantações gerenciadas pelo próprio Azure Policy, que respeita os estados das VMs.

A alternativa A descreve uma ação que não tem o efeito descrito: alterar o enforcementMode não provoca reavaliação retroativa de recursos existentes. A alternativa C excluir e recriar a atribuição não transforma recursos existentes em "novos" para fins de avaliação de DeployIfNotExists.

---

Gabarito — Cenário 3

Resposta: B

O enunciado descreve um comportamento de registro sem bloqueio: as contas são criadas com sucesso e aparecem como não conformes no painel. Esse padrão é a assinatura do efeito Audit. Se o efeito fosse Deny, a criação seria rejeitada com erro. A causa raiz é que a política de TLS dentro da iniciativa está configurada com efeito Audit, não Deny.

A exclusão em rg-storage-legacy é a informação irrelevante inserida propositalmente. Ela aparece no bloco de código de forma visível e pode atrair o diagnóstico para a alternativa A, mas o comportamento está ocorrendo em rg-storage-new, que não está na lista notScopes. A exclusão não tem relação com o problema.

A alternativa C é tecnicamente falsa: iniciativas suportam políticas com qualquer efeito, incluindo Deny. A alternativa D também é falsa: enforcementMode Default não interfere no efeito individual de políticas dentro de uma iniciativa; ele controla se a atribuição como um todo bloqueia ou não, e Default significa que o bloqueio está ativo.

O distrator mais perigoso é A, porque leva o administrador a investigar herança de escopo e exclusões, consumindo tempo e desviando do problema real, que está na definição da política em si.

---

Gabarito — Cenário 4

Resposta: B

A sequência correta é 3, 2, 5, 1, 4, que representa um diagnóstico progressivo do mais amplo para o mais específico:

Passo 3 confirma que a atribuição existe e está ativa no escopo esperado. Sem isso, todos os outros passos são irrelevantes.

Passo 2 valida que o efeito configurado é realmente Modify. Um erro na definição da política pode fazer com que o comportamento observado seja esperado, e não um problema.

Passo 5 verifica se o tipo de recurso está coberto pela condição if. Uma política de tags pode ter condições que excluem determinados tipos de recurso.

Passo 1 verifica a managed identity. O efeito Modify exige que a managed identity associada à atribuição tenha a role Contributor (ou equivalente) no escopo para poder modificar recursos. Sem essa permissão, a política avalia mas não consegue executar a modificação.

Passo 4 é o passo de confirmação final: o log de atividades mostra o que realmente aconteceu durante a criação, incluindo se a política foi avaliada, qual foi o resultado e se houve erro de permissão na tentativa de modificação.

A sequência A inverte a ordem lógica ao verificar o efeito antes de confirmar que a atribuição existe. A sequência C começa pela permissão da managed identity antes de confirmar que a atribuição e o efeito estão corretos, o que desperdiça investigação em um componente que pode nem estar envolvido. A sequência D começa pelo log, que é válido para confirmar, mas ineficiente como primeiro passo quando ainda não se sabe se a atribuição existe.

---

Árvore de Troubleshooting: Implement and manage Azure Policy

100%

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

Legenda:

Cor	Significado
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 com Azure Policy, comece pelo nó raiz e responda cada pergunta com base no que você consegue observar diretamente: a atribuição existe? O modo de execução está correto? O efeito configurado corresponde ao comportamento esperado? Cada resposta fecha um caminho e direciona para o próximo nível de investigação. O objetivo é chegar a um nó vermelho de causa identificada pelo menor número de passos possível, evitando ações corretivas prematuras antes de confirmar o diagnóstico.