Uma política que bloqueia uma implantação pode estar protegendo um requisito importante. Também pode estar impedindo uma exceção legítima porque foi aplicada sem contexto. O desafio não é escolher entre controle e agilidade, mas desenhar controles que indiquem claramente o que deve acontecer e como as equipes podem avançar com segurança.
Azure Policy avalia recursos em relação a regras definidas pela organização. Uma definição pode ser atribuída a diferentes escopos, como grupo de gerenciamento, assinatura ou grupo de recursos. Quando várias definições trabalham em conjunto para um objetivo comum, elas podem ser agrupadas em uma iniciativa.
Primeiro observe, depois aplique
Uma adoção gradual costuma ser mais fácil de operar. Comece relacionando cada política a um motivo compreensível: regiões permitidas, tags necessárias, registro de diagnóstico ou restrições para recursos específicos. Em seguida, avalie o impacto no ambiente existente e identifique quem será afetado.
Um roteiro possível:
- Escolha um requisito concreto e confirme com os responsáveis pela plataforma e pelas aplicações.
- Verifique quais definições internas ou integradas atendem ao requisito.
- Atribua o controle a um escopo adequado e acompanhe os resultados de conformidade.
- Resolva desvios conhecidos ou documente uma exceção com responsável, justificativa e prazo quando aplicável.
- Só então avalie se uma regra precisa impedir novas implantações ou se uma ação de remediação é apropriada.
Exceções não devem virar um caminho permanente para contornar a governança. Elas precisam ter um motivo verificável, escopo limitado e revisão. Da mesma forma, remediação automática requer avaliação: uma correção adequada para um recurso pode não ser segura para outro.
A ideia central: política útil é política que pode ser explicada, medida e revisada. Se as equipes não sabem por que ela existe, provavelmente falta contexto antes de aumentar o nível de imposição.
Escolha o efeito pelo risco da regra
O efeito determina como a regra participa do ciclo de vida do recurso. `Audit` registra desvios sem barrar a criação; `Deny` rejeita operações que não atendem ao requisito; `Modify` pode alterar propriedades em operações compatíveis; e `DeployIfNotExists` pode implantar um recurso relacionado quando condições e permissões estão corretas. Nem todo requisito deve começar bloqueando.
Uma exigência de tag usada para relatórios pode começar em auditoria, para revelar recursos sem classificação. Uma região proibida por decisão de negócio pode justificar bloqueio depois de identificar recursos existentes e exceções. Para remediação automática, revise identidade gerenciada, permissões e impacto antes da atribuição. A documentação recomenda começar com auditoria quando ainda é preciso entender o efeito da regra no ambiente.
Construa um ciclo de implantação seguro
Para cada política, registre o requisito, responsável, escopo inicial, efeito, validação, exceções aprovadas e data de revisão. Expanda por estágios: ambiente de desenvolvimento ou grupo controlado, cargas menos críticas e, por fim, os escopos restantes após avaliar os resultados. Combine cada ampliação com janela de mudança e responsáveis disponíveis.
Na revisão, pergunte se o controle ainda é necessário, se a regra cobre o tipo certo de recurso, se a ação é reversível e se a exceção tem justificativa e prazo. Verifique também alterações na definição ou versão de política. Evite exceções amplas quando uma exclusão específica atende ao caso. O desenho visual acima é conceitual; não mostra uma atribuição real nem comprova conformidade de qualquer ambiente.