Um usuário modificou acidentalmente uma propriedade de banco de dados em um modelo do CloudFormation e executou uma atualização de stack, causando tempo de inatividade do aplicativo. A equipe de DevOps ainda deve ser capaz de implantar stacks, mas alterações acidentais em recursos críticos específicos devem ser bloqueadas. Qual alteração no processo de implantação satisfará esse requisito?

A política de stack do CloudFormation é a solução mais direta e eficaz. Ela permite definir quais operações de atualização são permitidas ou negadas em recursos específicos dentro de uma stack, mesmo que o usuário tenha permissões do IAM para realizar a ação. Ao negar explicitamente Update: nos recursos protegidos, você impede que alterações acidentais causem tempo de inatividade, enquanto ainda permite outras operações de stack. Regras do AWS Config ou EventBridge com funções Lambda adicionam complexidade e latência, pois a alteração já teria sido iniciada antes da intervenção. Uma política do IAM condicionada aos ARNs dos recursos protegidos não é aplicável diretamente a atualizações de stack do CloudFormation, pois as permissões do IAM operam em um nível diferente da política de stack.