Een gebruiker heeft per ongeluk een database-eigenschap gewijzigd in een CloudFormation-template en een stack-update uitgevoerd, wat resulteerde in downtime van de applicatie. Het DevOps-team moet nog steeds stacks kunnen deployen, maar onbedoelde wijzigingen aan bepaalde kritieke resources moeten worden geblokkeerd. Welke wijziging in het deploymentproces voldoet aan deze vereiste?

De correcte optie is het implementeren van CloudFormation stacks met een stack policy die expliciet alle resources toestaat, maar expliciet Update: weigert op de beschermde resources. Een stack policy is een JSON-document dat definieert welke update-acties zijn toegestaan op specifieke resources in een stack. Door een stack policy te configureren die updates op kritieke resources weigert, voorkom je onbedoelde wijzigingen die downtime kunnen veroorzaken, terwijl je nog steeds updates op andere delen van de stack toestaat. De andere opties zijn minder effectief of complexer: Een AWS Config-regel die triggert op elke CloudFormation stack-wijziging en een Lambda-functie die de operatie annuleert, is reactief en kan de update niet voorkomen voordat deze begint. Een EventBridge-regel voor CloudFormation API-aanroepen met een Lambda-functie die updates afbreekt, is ook reactief en kan de wijziging niet voorkomen voordat deze wordt geïnitieerd. Bovendien kan het afbreken van een lopende update leiden tot een inconsistente stack-status. Een IAM policy die CloudFormation stack-updates verbiedt, geconditioneerd op de ARNs van de beschermde resources, is te breed. Dit zou alle updates op de stack verbieden als deze beschermde resources bevatten, zelfs als de update geen invloed heeft op die specifieke resources. Stack policies bieden fijnmazigere controle.