Użytkownik przypadkowo zmodyfikował właściwość bazy danych w szablonie CloudFormation i wykonał aktualizację stosu, co spowodowało przestój aplikacji. Zespół DevOps musi nadal mieć możliwość wdrażania stosów, ale przypadkowe zmiany w niektórych krytycznych zasobach muszą być blokowane. Jaka zmiana w procesie wdrażania spełni ten wymóg?

Polityki stosu CloudFormation (CloudFormation Stack Policies) są przeznaczone do zapobiegania przypadkowym aktualizacjom lub usunięciom określonych zasobów w stosie. Tworząc politykę stosu, która jawnie zezwala na wszystkie zasoby, a następnie jawnie odmawia akcji Update: dla krytycznych zasobów, zespół DevOps może nadal wdrażać aktualizacje, ale CloudFormation zablokuje zmiany w chronionych zasobach. Pozostałe opcje są mniej efektywne lub nieprawidłowe: Reguła AWS Config lub EventBridge z funkcją Lambda działałaby po próbie aktualizacji, co może być za późno, a ich implementacja jest bardziej złożona niż polityka stosu. Polityka IAM na roli DevOps jest nieodpowiednia, ponieważ polityki IAM kontrolują uprawnienia użytkownika do wykonywania operacji na CloudFormation, a nie to, jakie zasoby w ramach stosu mogą być modyfikowane przez CloudFormation.