APRENDER. PRATICAR. EVOLUIR.Conceito e mecanismo
Azure Policy avalia regras organizacionais sobre recursos e pedidos, enquanto RBAC trata autorização do principal. Uma pessoa autorizada a criar recursos pode ter um pedido negado por escolher uma região não permitida. Uma atribuição de Policy pode incluir âmbito, parâmetros e exclusões; qualquer exceção precisa de justificação e controlo. O resultado de conformidade descreve avaliação, não prova por si que um recurso existente foi corrigido. Efeitos como modify e deployIfNotExists podem exigir tarefas de remediação com identidade e permissões adequadas para tratar recursos já existentes.
Aplicação guiada
Resource locks protegem operações de gestão abrangidas, mas não equivalem a uma política de retenção dos dados. Antes de aplicar um lock, avalia também operações legítimas que podem ser afetadas. Tags ajudam a atribuir proprietário e custo, desde que existam convenções e manutenção. Um budget com notificação cria um sinal de gestão; não é um limite rígido de faturação nem uma autorização automática para parar produção. Define quem investiga desvios, que informação compara e que ações pode tomar. A otimização deve considerar janelas críticas, retenção e compromissos de serviço.
Um storage account com CanNotDelete continua a precisar de proteção de blobs. O lock de gestão não substitui versioning, retenção e permissões de dados adequadas.
Armadilhas comuns
Usar Owner para tentar ignorar Policy; confundir não conformidade com remediação; tratar um alerta financeiro como cap.
Tópicos relacionados: Storage, delegação e recuperação · Deploys declarativos e máquinas virtuais
Define que risco cada controlo trata e que evidência demonstra o seu efeito.
Referência: Azure Policy · AZ-104; skills measured 2026-04-17