Amazon DVA-C02: CloudFormation e Infrastruttura come Codice (SAM, CDK) — Guida allo studio

By Laurynas Brazys · 27 July 2026 · #amazon #dva-c02 #certification #exam-prep #study-guide

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

Pattern principali di CloudFormation e best practice per i template

I template CloudFormation dovrebbero essere scritti come descrizioni dichiarative e idempotenti delle risorse, privilegiando stack piccoli e mirati e stack annidati per architetture complesse. Utilizzare la sezione Resources con ID logici espliciti e preferire funzioni intrinseche come !Ref, !GetAtt, !Sub, Fn::FindInMap e Fn::If per la composizione e il riutilizzo. Validare i template con

undefined

o gli equivalenti SAM/CDK (

undefined

) prima di creare i ChangeSet. Utilizzare i ChangeSet (

undefined

) per la revisione e per evitare sostituzioni impreviste; usare

undefined

per ispezionare le azioni che lo stack eseguirà. Mantenere il corpo del template entro i limiti di CloudFormation spostando il codice inline di grandi dimensioni su S3 e referenziandolo (

undefined

), oppure suddividere in stack annidati con

undefined

. Applicare regolarmente il rilevamento della deriva (drift detection) usando

undefined

. Utilizzare

undefined

per proteggere le risorse che contengono dati e abilitare la protezione dalla terminazione (termination protection) sugli stack critici. Integrare

undefined

nella CI/CD per individuare precocemente problemi strutturali e violazioni delle policy. Per un’iterazione rapida, sfruttare i ChangeSet e le strategie di aggiornamento a livello di risorsa per minimizzare il raggio d’impatto (blast radius); per le funzioni Lambda, utilizzare deployment versionati per rendere gli aggiornamenti sicuri e reversibili.

Parametrizzazione, mappature, segreti e dati sensibili

Parametrizzare le differenze tra ambienti con i

undefined

e i

undefined

di CloudFormation, usando

undefined

per fallire rapidamente. Evitare di inserire segreti o credenziali in chiaro nei

undefined

; utilizzare invece

undefined

di SSM Parameter Store o Secrets Manager e referenziarli tramite riferimenti dinamici come

undefined

o usare i tipi

undefined

. Contrassegnare i parametri sensibili con

undefined

per mascherare i valori nella console, ma tenere presente che

undefined

non crittografa i dati a riposo (at rest) — usare Secrets Manager per l’audit e la rotazione. Utilizzare

undefined

per valori deterministici e specifici per ambiente (ID di AMI per regione) e

undefined

per il calcolo delle zone di disponibilità. Per i riferimenti a risorse tra stack nella stessa regione/account, esportare gli output e importarli tramite

undefined

; ricordare che le importazioni non possono avvenire tra account o regioni diverse. Proteggere i principal IAM utilizzati da CloudFormation definendo ruoli con il privilegio minimo (least privilege); preferire i permessi gestiti dal servizio per gli StackSet o fornire esplicitamente un ruolo di amministrazione con ambito limitato. Quando si passano variabili d’ambiente a container o Lambda, preferire il riferimento ad ARN di Secrets Manager o SSM Parameter e recuperare i valori a runtime nel codice, oppure usare le funzionalità di SAM/CDK per iniettare valori sicuri nell’ambiente con crittografia tramite KMS.

Deployment cross-account/region, pattern multi-account con CDK e SAM

I deployment tra account e regioni diverse (cross-account/cross-region) richiedono un’orchestrazione che va oltre gli export di un singolo stack. Per i deployment multi-account/multi-regione, scegliere CloudFormation StackSets (

undefined

) con permessi gestiti dal servizio per Organizations o autogestiti con un ruolo di esecuzione negli account di destinazione. Per gli artefatti del codice applicativo, utilizzare bucket S3 centralizzati con replica tra account o policy del bucket, oppure lasciare che gli strumenti pubblichino gli asset per regione: CDK utilizza stack di bootstrap e asset pubblicati tramite

undefined

e richiede

undefined

in ogni account/regione; CDK Pipelines (modulo

undefined

) o la CLI

undefined

con

undefined

supportano la promozione tra account. SAM utilizza

undefined

, che carica gli artefatti in un bucket S3; per il multi-account, usare la CI/CD per impacchettare e inviare gli artefatti ai bucket degli account di destinazione ed eseguire i deploy con le credenziali appropriate. Evitare i context lookup di CDK (

undefined

, ecc.) che richiedono permessi specifici dell’account al momento della sintesi (synth time); passare invece esplicitamente gli identificatori come parametri per mantenere la sintesi riproducibile. Utilizzare AWS CodePipeline o GitHub Actions con ruoli assunti (

undefined

) per eseguire i deploy negli account di destinazione, assicurandosi che esistano il bootstrap e i ruoli collegati al servizio (service-linked roles) necessari. Ricordare che gli export di CloudFormation sono regionali; preferire gli StackSet o i deployment guidati da pipeline per la distribuzione tra account diversi.

Risorse personalizzate, protezione dello stack e acceleratori per il deployment locale e incrementale

Utilizzare le risorse personalizzate quando a CloudFormation manca un tipo di risorsa nativo, implementando provider basati su Lambda che rispettano il protocollo di risposta di CloudFormation per gli eventi Create/Update/Delete. Creare handler idempotenti, rispondere con cfn-response o con il framework della CLI di CloudFormation e gestire le azioni a lunga esecuzione con eventi di progresso o archiviando lo stato in DynamoDB. Prestare attenzione ai timeout delle risorse personalizzate: CloudFormation ha un timeout massimo per le operazioni dello stack e le risorse basate su Lambda devono completarsi entro tale finestra temporale o causeranno il rollback dello stack. Proteggere le risorse critiche con le policy di stack (SetStackPolicy) per bloccare la sostituzione o gli aggiornamenti di ID logici specificati durante gli aggiornamenti dello stack, e abilitare la protezione dalla terminazione per gli ambienti che non ci si può permettere di eliminare. Per lo sviluppo locale e incrementale, utilizzare la CLI di AWS SAM (sam build, sam local invoke, sam local start-api) e sam sync per aggiornamenti rapidi del solo codice, e cdk watch o cdk deploy con gli asset per aggiornare solo le risorse modificate; questi strumenti calcolano gli hash degli asset (lambda asset hashing) in modo che solo il codice modificato venga ripubblicato. Integrare i Change Set di CloudFormation, il versioning di Lambda (AutoPublishAlias in SAM o lambda.Version in CDK) e lo spostamento del traffico di CodeDeploy per deployment sicuri. Le trappole comuni includono il superamento dei limiti del template o dei parametri, l’uso scorretto delle importazioni cross-account e l’inizializzazione di client SDK pesanti all’interno degli handler, causando latenze di cold start — preferire client globali, inizializzati in modo lazy (lazy-initialized), con timeout e comportamento di retry configurabili.

Problema Pratico: Scenario d’Uso

Scenario: AcmeMedia gestisce un’organizzazione AWS multi-account con account separati per Dev, Staging e Prod nella regione us-east-1. Un servizio serverless di elaborazione immagini (Lambda + S3 + DynamoDB) deve essere distribuito in modo coerente su tutti gli account, con una configurazione sensibile condivisa e archiviata centralmente.

Sfida: Eseguire il deployment dello stesso stack CloudFormation/SAM/CDK su più account e garantire che gli artefatti del codice Lambda siano disponibili in modo sicuro in ogni account di destinazione, mantenendo i segreti fuori dai template.

Approccio Raccomandato:

Usare AWS CloudFormation StackSets con permessi gestiti dal servizio (aws cloudformation create-stack-set –stack-set-name ImageProcessor –template-body file://template.yaml) e poi aws cloudformation create-stack-instances per puntare agli account e alle regioni di destinazione, oppure configurare CDK Pipelines per eseguire il synth e il deploy per ogni account con ruoli specifici.
Impacchettare gli asset Lambda utilizzando la pubblicazione degli asset di CDK (cdk bootstrap in ogni account/regione) o sam package in un bucket S3 in ogni account di destinazione; automatizzare la copia degli asset tramite CI (CodeBuild usando aws s3 cp o la replica S3) e usare cdk deploy o sam deploy con le credenziali dell’account di destinazione.
Archiviare la configurazione sensibile in AWS Secrets Manager in ogni account, facendovi riferimento nel template tramite riferimenti dinamici ({{resolve:secretsmanager:arn:aws:secretsmanager:us-east-1:123456789012:secret:ImageProcSecret:SecretString:apiKey}}) o distribuire un segreto replicato tramite la funzionalità di replica di Secrets Manager, evitando i parametri NoEcho.
Usare i Change Set (create-change-set, execute-change-set), abilitare la protezione dalla terminazione sugli stack di produzione e usare le policy di stack per prevenire la sostituzione accidentale delle tabelle DynamoDB o dei bucket S3 durante gli aggiornamenti.

Motivazione: Gli StackSet e i deployment guidati da pipeline forniscono una propagazione sicura e verificabile su più account e regioni, mentre la pubblicazione degli asset e i segreti per-account mantengono le credenziali locali e verificabili. I Change Set, la protezione dalla terminazione e le policy di stack riducono il rischio durante i deployment iterativi.

← Amazon DynamoDB e Progettazione NoSQL · Tutti i domini · Distribuzione e CI →

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