Un utente ha modificato accidentalmente una proprietà del database in un template CloudFormation ed ha eseguito un aggiornamento dello stack, causando un'interruzione dell'applicazione. Il team DevOps deve essere ancora in grado di distribuire gli stack, ma le modifiche accidentali a particolari risorse critiche devono essere bloccate. Quale modifica al processo di deployment soddisferà questo requisito?

La risposta corretta è l'implementazione di una stack policy di CloudFormation. Le stack policy consentono di definire quali azioni possono essere eseguite sulle risorse all'interno di uno stack. Nello specifico, è possibile consentire esplicitamente tutte le risorse e negare esplicitamente le azioni di aggiornamento (Update:) su risorse critiche specifiche. Questo impedisce modifiche accidentali a tali risorse durante gli aggiornamenti dello stack, pur consentendo al team DevOps di distribuire e aggiornare altre parti dello stack. Le altre opzioni sono meno efficaci o più complesse: Una regola AWS Config o EventBridge con una funzione Lambda (opzioni A e B) introdurrebbe una logica reattiva che annullerebbe l'operazione dopo che è stata tentata, il che potrebbe comunque causare un breve periodo di instabilità o un errore visibile. Le stack policy agiscono in modo preventivo. Una policy IAM (opzione D) agisce a livello di utente/ruolo e non a livello di risorsa specifica all'interno di uno stack CloudFormation. È più difficile da gestire per bloccare aggiornamenti specifici a risorse all'interno di uno stack mantenendo la flessibilità per altre risorse.