Azure Policy Exemptions sem bagunça: como criar exceções temporárias, auditáveis e com dono

Em ambientes Azure bem governados, exceção sempre vai existir.

A aplicação precisa subir antes da correção definitiva. Um workload legado ainda não suporta determinado padrão. Um time precisa de prazo para ajustar tags, criptografia, zona de disponibilidade, SKU, rede ou configuração de segurança. O problema não é ter exceção. O problema é permitir exceções sem prazo, sem dono, sem justificativa e sem revisão.

Quando isso acontece, a governança deixa de ser controle e vira ruído operacional.

Azure Policy Exemptions é o recurso que ajuda justamente nesse ponto: permitir que uma exceção exista sem apagar sua rastreabilidade. Ela não deve ser usada como atalho para “limpar” não conformidades, mas como parte de um modelo operacional maduro para tratar desvios conhecidos, aceitos e acompanhados. A documentação da Microsoft define a exemption como um objeto que isenta uma hierarquia ou recurso individual da avaliação de uma policy ou initiative, mantendo rastreabilidade no estado de compliance.

A decisão em poucas linhas

Antes de criar uma exemption, responda três perguntas:

Por que essa exceção existe?
Quem é o dono da correção ou da aceitação do risco?
Quando essa exceção deve acabar?

Se essas três respostas não estiverem claras, o problema não é técnico. É governança.

Azure Policy Exemption faz sentido quando o recurso continua dentro do escopo de governança, mas existe uma justificativa temporária ou uma mitigação alternativa para ele não ser avaliado por determinada policy. Diferente de notScopes, que exclui escopos da atribuição, exemptions permitem manter a exceção rastreável nos relatórios de compliance. A própria Microsoft recomenda, de forma geral, usar exclusões para cenários permanentes ou amplos e exemptions para cenários mais específicos, temporários e rastreáveis.

Onde Azure Policy Exemptions se encaixa

Azure Policy costuma ser usado para auditar, negar, modificar ou corrigir configurações em recursos Azure. Em ambientes enterprise, as policies costumam estar organizadas em initiatives aplicadas em management groups, subscriptions ou resource groups.

A lógica é simples: definir padrões e avaliar recursos contra esses padrões.

O desafio começa quando uma política está correta, mas um recurso específico ainda não consegue atendê-la. Exemplos comuns:

uma VM produtiva ainda não está em zona de disponibilidade;
uma aplicação legada precisa de prazo para adequar tags obrigatórias;
um Key Vault tem configuração aceita temporariamente por causa de uma dependência técnica;
uma subscription de transição precisa operar com um desvio documentado;
uma iniciativa de segurança possui uma policy específica que não se aplica a um workload em migração.

Nesses casos, remover a policy ou editar a initiative para acomodar exceções pontuais costuma ser uma má decisão. Você enfraquece o controle para todos por causa de poucos recursos.

A exemption permite um caminho mais controlado: a política continua existindo, a iniciativa continua aplicada e o desvio passa a ser tratado como uma exceção formal.

O que uma exemption precisa carregar

Uma exemption não deveria ser apenas um objeto técnico criado no Azure.

Ela precisa carregar contexto operacional.

Na estrutura do Azure Policy Exemption, há elementos como displayName, description, metadata, policyAssignmentId, policyDefinitionReferenceIds, exemptionCategory e expiresOn. O campo expiresOn define quando a exemption deixa de ser honrada; a Microsoft também informa que o objeto não é apagado automaticamente quando a data chega, ficando preservado para registro.

Na prática, isso é bom para auditoria. Mas também cria uma responsabilidade: alguém precisa revisar exemptions vencidas, porque elas podem continuar aparecendo no ambiente como objetos históricos.

Um modelo mínimo de metadata deveria incluir:

dono técnico;
área ou squad responsável;
justificativa;
ticket ou change;
data de aprovação;
aprovador;
data planejada de correção;
criticidade do recurso;
categoria do risco;
plano de ação.

Sem isso, a exemption vira apenas um “silenciador” de compliance.

Waiver ou Mitigated: não trate como detalhe

Toda exemption precisa deixar claro qual tipo de decisão está sendo tomada.

No Azure Policy, existem duas categorias principais:

Waiver
Use quando a organização aceita temporariamente a não conformidade.

Exemplo: uma aplicação precisa de prazo para adequar tags obrigatórias, ajustar criptografia ou corrigir uma configuração fora do padrão.

Mitigated
Use quando a intenção da policy é atendida por outro meio.

Exemplo: o recurso não atende exatamente à regra definida na policy, mas existe um controle compensatório aprovado por segurança ou arquitetura.

A diferença parece pequena, mas muda a conversa de risco.

Waiver significa: “sabemos que está fora do padrão e aceitamos por um período”.

Mitigated significa: “o padrão não foi atendido da forma esperada pela policy, mas existe outra forma de mitigação”.

Esse cuidado evita confusão em auditoria, segurança e governança. Nem toda exceção é um risco aceito sem controle. E nem toda mitigação deve virar uma liberação sem prazo.

Um exemplo técnico curto

O exemplo abaixo é simplificado. Em ambientes corporativos, o ideal é que esse tipo de exemption seja criado por pipeline, IaC ou processo controlado, e não manualmente pelo terminal.

Ainda assim, o comando ajuda a entender quais informações são importantes na criação de uma exemption:

az policy exemption create \
  --name "ex-waiver-tags-rg-app-prod-2026-06" \
  --display-name "Exceção temporária para tags obrigatórias - RG App Prod" \
  --description "Exceção aprovada para adequação de tags obrigatórias durante plano de correção." \
  --scope "/subscriptions/<subscription-id>/resourceGroups/<resource-group>" \
  --policy-assignment "/subscriptions/<subscription-id>/providers/Microsoft.Authorization/policyAssignments/<assignment-name>" \
  --exemption-category "Waiver" \
  --expires-on "2026-06-30T23:59:59Z" \
  --metadata "{\"owner\":\"squad-app-prod\",\"ticket\":\"CHG000000\",\"approvedBy\":\"cloud-governance\",\"reason\":\"Adequação planejada de tags\"}"

A CLI oficial possui comandos para criar, listar, exibir, atualizar e excluir exemptions, incluindo parâmetros como categoria, assignment, escopo, data de expiração, metadata e policy definition reference IDs.

O ponto principal não é decorar o comando. É padronizar o que precisa existir antes de alguém executar esse comando.

Exemption não é a mesma coisa que notScopes

Apesar de resolverem problemas parecidos, exemption e notScopes não devem ser tratados como sinônimos.

Use notScopes quando um escopo realmente não deve participar da avaliação daquela policy ou initiative.

Use exemption quando o recurso continua dentro da governança, mas existe uma justificativa específica para ele não ser avaliado naquele momento.

Essa diferença é importante porque a exemption aparece como isenta nos relatórios de compliance, enquanto uma exclusão por notScopes remove o recurso da avaliação.

Na prática, notScopes costuma fazer mais sentido para exclusões estruturais e planejadas. Exemption faz mais sentido para exceções específicas, temporárias e rastreáveis.

Quando usar exemptions

Azure Policy Exemptions costuma fazer sentido em cenários como:

exceção temporária para correção planejada;
migração de workload legado;
adequação gradual de landing zone;
iniciativa aplicada em larga escala com exceções pontuais;
controle compensatório aprovado por segurança;
divergência temporária entre padrão corporativo e capacidade técnica do workload;
recurso crítico que não pode ser alterado imediatamente sem impacto operacional.

Em ambientes regulados, a exemption pode ser útil justamente por não esconder a exceção. Ela permite que a organização reconheça o desvio, documente a decisão e acompanhe o prazo.

Quando evitar

Evite Azure Policy Exemptions quando a intenção real for abandonar o controle.

Também evite quando a exceção for ampla demais. Se uma subscription inteira precisa ficar fora de determinada policy de forma permanente, talvez o problema esteja no escopo da atribuição, na definição da initiative ou no desenho do modelo de governança.

Outro erro é usar exemption para corrigir policy mal escrita. Se a policy gera falso positivo com frequência, o caminho correto é revisar a definição, os parâmetros, os aliases, o efeito ou o escopo. Exemption não deve mascarar problema de desenho.

Diagrama técnico comparando escopo de atribuição, exclusão por notScopes e Azure Policy Exemption em uma initiative.

Exemption não remove a governança; ela registra uma exceção controlada dentro do escopo.

Nota avançada: cuidado com escopos amplos

Em cenários mais avançados, resourceSelectors podem ajudar a restringir melhor o alcance de uma exemption, por exemplo por região, tipo de recurso ou localização específica.

Não é algo que precisa ser usado em toda exceção, mas pode ser útil quando o objetivo é evitar exemptions amplas demais.

A regra prática continua a mesma: aplique a exceção no menor escopo possível e documente claramente o motivo.

Erros comuns que criam bagunça

Criar exemption sem data de expiração

Tecnicamente pode existir exceção sem expiração, mas operacionalmente isso deve ser raro. Quando não há prazo, a exceção tende a virar regra paralela.

Como evitar: defina uma política interna exigindo expiresOn, exceto em casos formalmente aprovados.

Usar exemption para tudo

Se toda semana surgem dezenas de exemptions para a mesma policy, talvez a policy esteja mal calibrada, aplicada cedo demais ou sem processo de onboarding.

Como evitar: analise padrões recorrentes e ajuste a estratégia de adoção.

Não definir dono

Exceção sem dono não tem caminho de resolução. Em algum momento, a equipe de governança vai cobrar, mas ninguém vai se reconhecer como responsável.

Como evitar: registre owner técnico, área, aprovador e ticket no metadata.

Exemptar escopo grande demais

Uma exemption em resource group ou subscription pode atingir mais recursos do que o necessário.

Como evitar: aplique no menor escopo possível e revise impacto antes da aprovação.

Não revisar exemptions vencidas

A exemption vencida deixa de ser honrada, mas o objeto pode permanecer como registro. Isso é bom para histórico, mas exige limpeza e análise operacional.

Como evitar: crie rotina de revisão mensal e relatório de exemptions vencidas, próximas do vencimento e sem metadata suficiente.

Modelo operacional recomendado

Um bom processo de Azure Policy Exemptions não começa no portal. Começa no fluxo de governança.

Abaixo está um modelo prático para ambientes corporativos:

1. Solicitação
O time responsável informa recurso, policy, justificativa, impacto, prazo e plano de correção.

2. Classificação
A governança define se a exceção será tratada como Waiver ou Mitigated.

3. Avaliação de risco
Segurança, arquitetura ou plataforma avaliam se o desvio é aceitável para aquele cenário.

4. Aprovação
A decisão deve ficar registrada em change, ticket, backlog, ferramenta ITSM ou fluxo corporativo equivalente.

5. Criação controlada
Sempre que possível, a exemption deve ser criada via IaC, pipeline ou script padronizado, evitando ações manuais sem rastreabilidade.

6. Monitoramento
O ambiente deve ter relatório de exemptions ativas, vencidas, próximas do vencimento e sem metadata suficiente.

7. Revisão antes do vencimento
Antes da data de expiração, o dono confirma se a correção foi feita, se a exemption precisa ser renovada ou se deve ser encerrada.

8. Encerramento
Após a correção ou fim da necessidade, a exemption deve ser removida ou mantida apenas como registro histórico, conforme o padrão interno da organização.

Automação e Policy as Code

Para ambientes pequenos, criar exemptions manualmente pode parecer aceitável. Em escala enterprise, isso não sustenta.

A própria documentação de Azure Policy as Code recomenda tratar definições, iniciativas e exemptions como arquivos versionados, com revisão e implantação por mecanismos centralizados, como GitHub Actions ou Azure Pipelines.

Um padrão interessante é manter um repositório com:

policy/
  assignments/
  initiatives/
  exemptions/
    prod/
    nonprod/

Cada exemption pode ter um arquivo JSON com metadata obrigatória e aprovação via pull request. Isso cria histórico, revisão por pares e rastreabilidade.

Também permite validar regras antes da implantação, como:

bloquear exemption sem expiresOn;
exigir owner;
exigir ticket;
limitar prazo máximo por categoria;
impedir exemption em escopos amplos sem aprovação especial;
alertar exemptions próximas do vencimento.

Observabilidade: o que acompanhar

Azure Policy gera dados de compliance acessíveis pelo portal, linha de comando, Azure Monitor Logs e Azure Resource Graph.

Em termos práticos, se você quiser começar simples, acompanhe pelo menos quatro indicadores:

– exemptions ativas;
– exemptions vencidas;
– exemptions próximas do vencimento;
– exemptions sem owner.

Depois, evolua para uma visão mais completa:

quantidade de exemptions ativas;
exemptions por management group, subscription e resource group;
exemptions por categoria;
exemptions vencidas;
exemptions vencendo nos próximos 30 dias;
exemptions sem owner;
exemptions sem ticket;
policies com maior volume de exceções;
renovações recorrentes para o mesmo recurso.

Esses indicadores ajudam a separar exceção legítima de fragilidade estrutural na governança.

O que levar para a prática

Exemption não deve ser usada para esconder não conformidade.
Toda exceção precisa ter justificativa, dono, prazo e revisão.
Waiver e Mitigated representam decisões diferentes de risco.
O menor escopo possível reduz impacto acidental.
Policy as Code melhora rastreabilidade e reduz decisões manuais.
Exemptions vencidas precisam entrar em rotina operacional.

Fluxo operacional para criação, aprovação, monitoramento e encerramento de Azure Policy Exemptions.

O valor da exemption está no ciclo de vida, não apenas na configuração.

Checklist final

Antes de aprovar uma Azure Policy Exemption, valide:

A policy ou initiative está correta?
A exemption é realmente necessária?
O escopo é o menor possível?
A categoria foi definida como Waiver ou Mitigated?
Existe data de expiração?
O dono técnico está registrado?
Existe ticket, change ou evidência de aprovação?
O risco foi avaliado?
Existe plano de correção ou controle compensatório?
A exemption será monitorada?
Existe revisão antes do vencimento?
O processo está documentado?

Leituras relacionadas

Conclusão

Azure Policy Exemptions é um recurso simples, mas o impacto dele depende do modelo operacional ao redor.

Em ambientes Azure enterprise, exceções precisam existir com controle. A diferença entre maturidade e bagunça está em tratar cada desvio como uma decisão rastreável: com motivo, responsável, prazo, aprovação e revisão.

Quando bem usado, o Azure Policy Exemption não enfraquece a governança. Ele ajuda a tornar a governança mais realista, auditável e sustentável.

No fim, a pergunta não é apenas “podemos criar uma exemption?”. A pergunta certa é: “essa exceção tem dono, prazo e caminho de encerramento?”

Como sua organização controla exceções de Azure Policy hoje: por processo formal, por script, por portal ou ainda de forma manual e pouco rastreável?