Un'azienda ha utilizzato IaC per creare due istanze EC2 che sono rimaste invariate per anni. La rapida crescita del business ha portato il team operativo a introdurre un gruppo Auto Scaling, che sostituisce le istanze durante i picchi. La politica aziendale richiede aggiornamenti di sicurezza del sistema operativo mensili che a volte richiedono un riavvio. Dopo una recente patch che ha richiesto un riavvio, il gruppo Auto Scaling ha terminato le istanze con patch e ha avviato nuove istanze senza patch. Quale combinazione di azioni dovrebbe raccomandare l'architetto di soluzioni per evitare che ciò accada di nuovo? (Scegliere due.)

La soluzione più efficace per evitare che le istanze con patch vengano terminate e sostituite con istanze non patchate è automatizzare il processo di patching e integrare le AMI patchate nel ciclo di vita di Auto Scaling. Automatizzare l'applicazione di patch a un'AMI, creando script che costruiscono un'AMI con patch, aggiornando la configurazione di avvio per usarla e richiamando un aggiornamento dell'istanza Auto Scaling, garantisce che tutte le nuove istanze avviate siano già patchate. Modificare il gruppo Auto Scaling impostando la policy di aggiornamento in modo che abbia come target la configurazione di avvio più vecchia per la sostituzione (o un'altra strategia di aggiornamento graduale) consente di aggiornare le istanze in modo controllato, sostituendo gradualmente le istanze obsolete con quelle basate sulla nuova AMI patchata. Creare un secondo gruppo Auto Scaling non risolve il problema delle istanze non patchate. Posizionare un Elastic Load Balancer è una buona pratica per la disponibilità, ma non impedisce la terminazione di istanze patchate o l'avvio di istanze non patchate. Abilitare la protezione dalla terminazione sulle singole istanze impedirebbe ad Auto Scaling di funzionare correttamente e non è una soluzione scalabile o automatizzata.