Amazon SOA-C02: Distribuzione, provisioning e automazione — Guida allo studio

By Laurynas Brazys · 2 August 2026 · #amazon #soa-c02 #certification #exam-prep #study-guide

Fa parte della AWS SysOps Administrator Associate SOA-C02 — Guida allo studio. Esercitati con risposte verificate nel centro esami Amazon, oppure fai test cronometrati su ExamRoll.io.

Questo dominio copre i metodi e gli strumenti utilizzati per il provisioning, l’aggiornamento e la gestione dell’infrastruttura e dei deployment applicativi su AWS in modo affidabile e ripetibile. Enfatizza il provisioning dichiarativo e idempotente, le pipeline automatizzate per i rilasci e l’automazione operativa che riduce il lavoro manuale ripetitivo, preservando al contempo l’auditabilità e la sicurezza. Gli operatori devono bilanciare la sicurezza (rollback, policy di modifica) con la velocità (immagini immutabili, patching automatizzato) e scegliere pattern che supportino la conformità e la recuperabilità.

CloudFormation e pattern di Infrastructure as Code

Utilizzare CloudFormation (o CDK/Terraform) per dichiarare l’infrastruttura come codice (IaC) in modo che gli stack siano idempotenti: un template descrive lo stato desiderato e il motore converge le risorse verso tale stato. Preferire risorse e parametri dichiarativi rispetto a script imperativi. Pattern CLI tipici:

Creare e ispezionare un change set: aws cloudformation create-change-set –stack-name my-stack –template-body file://template.yaml –parameters ParameterKey=Env,ParameterValue=prod –change-set-name cs1
Rivedere ed eseguire: aws cloudformation describe-change-set –change-set-name cs1 && aws cloudformation execute-change-set –change-set-name cs1
Deployment semplificato: aws cloudformation deploy –template-file template.yaml –stack-name my-stack –parameter-overrides Key=Value –capabilities CAPABILITY_NAMED_IAM

Decisioni di progettazione:

Utilizzare stack annidati (nested stack) o moduli per il riutilizzo e per gestire i limiti; spostare segreti mutabili e file binari di grandi dimensioni fuori dai template (utilizzando SSM Parameter Store / Secrets Manager).
Utilizzare stack policy, protezione dalla terminazione (termination protection) e trigger di rollback per la sicurezza; abilitare il rilevamento delle deviazioni (drift detection) con aws cloudformation detect-stack-drift e aws cloudformation describe-stack-drift-detection-status.
Concedere al ruolo di servizio (service role) di CloudFormation una policy IAM con ambito limitato (scoped) per creare le risorse; evitare di concedere a CloudFormation permessi di amministratore generici.

Nel confrontare gli approcci IaC:

CloudFormation/CDK: nativo, integrato con i change set e il drift detection di AWS, richiede CAPABILITY_NAMED_IAM per le risorse IAM.
Terraform: agnostico rispetto al provider, richiede la gestione di un file di stato (state file), ideale per ambienti multi-cloud.
Script imperativi (CLI/SDK): adatti per operazioni una tantum (one-off) ma non idempotenti e più difficili da sottoporre ad audit.

Pratiche di CI/CD e automazione del deployment

Implementare fasi di pipeline ripetibili: source -> build -> test -> deploy. Utilizzare AWS CodePipeline integrando CodeBuild, CodeDeploy o strumenti di terze parti (Jenkins, GitHub Actions). Configurazioni chiave:

CodeBuild: definire il file buildspec.yml per le fasi e gli artefatti; concedere al ruolo del progetto (project role) il principio del privilegio minimo (least privilege) (s3:GetObject per gli input, s3:PutObject per gli artefatti).
CodeDeploy: utilizzare gruppi di deployment (deployment group) e il file AppSpec.yml; scegliere il tipo di deployment: in-place o blue/green. Per EC2/ASG, preferire il blue/green per ridurre il rischio.
ECR + ECS/EKS: eseguire il push delle immagini dalla CI, assegnare tag immutabili (semantici o ID di build) e fare riferimento al tag o al digest dell’immagine nelle definizioni di task (task definition).

Criteri decisionali per le strategie di deployment:

Utilizzare strategie blue/green o canary con spostamento del traffico (traffic shifting) quando si necessita di tempi di inattività quasi nulli e di un rollback sicuro; lo spostamento del peso (weight shift) di CodeDeploy o dell’Application Load Balancer (ALB) supporta questo approccio.
Utilizzare aggiornamenti rolling o in-place per flotte più piccole e stateless dove la capacità può essere ridotta durante l’aggiornamento.
Assicurarsi che i ruoli della pipeline abbiano un ambito limitato (scoped): il ruolo di esecuzione della pipeline, il ruolo di servizio di CodeBuild e il ruolo di deployment (instance profile) devono avere ciascuno permessi minimi.

Gestire segreti e parametri in modo sicuro: archiviare i parametri in SSM Parameter Store (come SecureString) o in AWS Secrets Manager; concedere ai ruoli della pipeline i permessi kms:Decrypt e ssm:GetParameter o secretsmanager:GetSecretValue secondo necessità.

Creazione di AMI (baking), immagini immutabili e gestione delle AMI

Infrastruttura immutabile significa creare una nuova AMI con tutte le patch del sistema operativo e dell’applicazione già integrate (“baked in”), per poi sostituire le istanze invece di modificarle (mutating). Utilizzare EC2 Image Builder o Packer nella CI per produrre AMI automaticamente:

Le pipeline di EC2 Image Builder possono essere eseguite a intervalli pianificati, installare pacchetti, eseguire test e produrre AMI con convenzioni di denominazione e tag versionati.
Packer si integra nella CI (CodeBuild/Jenkins) per eseguire script di build e restituire gli ID delle AMI; archiviare l’AMI più recente in SSM Parameter Store (es. /ami/app-prod) come riferimento.

Gestire il ciclo di vita delle AMI:

Taggare le immagini con metadati di build e una data di scadenza; automatizzare la deregistrazione dell’AMI e la cancellazione dello snapshot dopo il periodo di conservazione (retention).
Utilizzare Launch Template/ASG con un aggiornamento di versione per distribuire (roll out) le nuove AMI; per i deployment immutabili, creare un nuovo ASG che fa riferimento alla nuova versione del Launch Template e scambiare i target group.

Confronto tra mutabile e immutabile:

Immutabile (nuova AMI/nuovo ASG): più sicuro, rollback più semplice passando all’ASG o all’AMI precedente, ciclo di vita coerente.
Mutabile (patch sul posto): più veloce per applicare piccole correzioni ma con un rischio maggiore di deviazione (drift) e più difficile da riprodurre; da usare solo quando i vincoli lo richiedono.

Automazione, Run Command e patching con AWS Systems Manager

Systems Manager (SSM) centralizza le attività operative: Run Command per comandi ad-hoc, State Manager per lo stato desiderato, Patch Manager per il patching pianificato del sistema operativo e Automation per flussi di lavoro complessi. Pattern CLI comuni:

Invio ad-hoc:

undefined

Avvio di un’automazione predefinita:

undefined

Utilizzare le associazioni di State Manager per applicare la configurazione (es. configurazione dell’agente SSM, processi cron) e le baseline di Patch Manager per le regole di approvazione e le scansioni di conformità.

Dettagli di configurazione e punti decisionali:

Utilizzare Patch Manager con Baseline e Maintenance Windows per un patching prevedibile e conforme; scegliere i giorni per l’approvazione automatica e rifiutare le immagini AMI non approvate se si utilizza una strategia immutabile.
Per istanze senza l’agente SSM o con rete limitata, considerare Session Manager con endpoint VPC per evitare di aprire le porte SSH.
Richiedere sempre un profilo di istanza con la policy AmazonSSMManagedInstanceCore per l’accesso a SSM; definire l’ambito delle autorizzazioni aggiuntive secondo necessità.

Gestione delle modifiche, rilevamento del drift e rollback

Implementare un controllo delle modifiche che integri esecuzioni della pipeline, tag e approvazioni. Utilizzare i change set di CloudFormation per visualizzare in anteprima le differenze (diff) e le policy dello stack per rifiutare aggiornamenti distruttivi. Pattern CLI:

Rilevare il drift:

undefined

Utilizzare una policy dello stack per proteggere le risorse critiche durante gli aggiornamenti e impostare RollbackConfiguration con trigger di rollback per notificare gli aggiornamenti falliti.

Strategie di rollback:

Per CloudFormation: il rollback automatico in caso di fallimento è l’impostazione predefinita; utilizzare i trigger di rollback e conservare le risorse quando necessario.
Per le applicazioni: preferire implementazioni blue/green o canary con spostamento del traffico (traffic shifting) per consentire un rollback istantaneo ripesando i pesi su ALB/Route 53 o ripristinando i set di task precedenti.
Mantenere artefatti immutabili (ID AMI, immagini di container) e conservare le versioni precedenti nei registri/SSM in modo che i rollback siano deterministici.

Criteri decisionali:

Se sono coinvolte migrazioni di dati stateful, includere script di migrazione reversibili o utilizzare feature flag per separare il rilascio del codice dalla migrazione dello schema.
Utilizzare controlli di integrità (health check) della distribuzione e smoke test automatizzati come gate della pipeline per attivare tempestivamente i rollback.

Errori Comuni e Criteri Decisionali

Apportare modifiche manuali fuori banda dalla console che causano un drift rispetto allo stato IaC: imporre il rilevamento del drift (

undefined

) e richiedere che le correzioni vengano applicate tramite i template IaC; utilizzare i controlli IAM per limitare le modifiche dalla console.

Nessun piano di rollback sicuro per i rilasci: adottare deployment blue/green o canary e mantenere disponibili gli artefatti/AMI precedenti per un ripristino istantaneo.
IAM eccessivamente permissivo per pipeline e ruoli: applicare il principio del privilegio minimo (least privilege); suddividere i ruoli (ruolo di servizio della pipeline, ruolo di build, profilo di istanza) e concedere solo l’accesso necessario a

undefined

e S3.

Memorizzare segreti direttamente nei template o in testo semplice: spostare i segreti in Secrets Manager o nel Parameter Store di SSM come SecureString e farvi riferimento al momento del deployment con le autorizzazioni di decrittazione appropriate.
Applicare patch in produzione direttamente (in-place) senza testare: creare (bake) le AMI in CI con pacchetti aggiornati e smoke test, quindi distribuire le immagini immutabili tramite ASG o pipeline blue/green.
Ignorare il drift e la protezione delle risorse stateful: utilizzare le policy dello stack e rilevare regolarmente il drift; per le risorse stateful, richiedere l’approvazione manuale e la creazione di snapshot prima di modifiche distruttive.

Problema Pratico: Scenario d’Uso

Acme Payments deve distribuire un servizio API conforme a PCI, applicare patch mensili al sistema operativo ed essere in grado di effettuare un rollback rapido se una distribuzione causa errori durante l’orario di lavoro.

Implementare una pipeline immutabile: utilizzare CodePipeline/CodeBuild per creare (bake) le AMI con EC2 Image Builder (o Packer), aggiungere tag alle AMI e pubblicare l’ID dell’AMI nel SSM Parameter Store.
Distribuire tramite template di CloudFormation che fanno riferimento al parametro SSM per l’AMI e creano una nuova versione di ASG + Launch Template per ogni rilascio; utilizzare i change set per una revisione preliminare (pre-flight).
Utilizzare CodeDeploy o lo spostamento del traffico (traffic shifting) blue/green del gruppo target di un ALB con controlli di integrità (health check) e smoke test automatizzati; configurare il rollback automatico in caso di fallimento degli health check.
Pianificare Patch Manager tramite le Maintenance Windows di Systems Manager per l’applicazione delle patch al di fuori delle ore di punta; eseguire il processo di bake-and-deploy per le immagini aggiornate per evitare il patching in-place della produzione.
Applicare il principio del privilegio minimo (least-privilege) IAM per i ruoli della pipeline, memorizzare i segreti in Secrets Manager e abilitare il rilevamento del drift di CloudFormation e le policy dello stack per le risorse critiche.

Motivazione: La creazione (baking) di immagini e la distribuzione immutabile separano le fasi di build e di esecuzione (run), fornendo artefatti riproducibili e percorsi di rollback sicuri; il patching automatizzato tramite SSM, unito a distribuzioni immutabili, minimizza i rischi e supporta la conformità mantenendo la recuperabilità.

← Alta disponibilità · Tutti i domini · Sicurezza →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →