Amazon DOP-C02: Infrastruttura come Codice e Gestione della Configurazione — Guida allo studio

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

Fa parte della AWS DevOps Engineer Professional DOP-C02 — Guida allo studio. Esercitati con risposte verificate nel centro esami Amazon, oppure fai test cronometrati su ExamRoll.io.

Panoramica

L’Infrastructure as Code (IaC) e la gestione della configurazione su AWS forniscono un provisioning e una configurazione ripetibili, verificabili e governati dell’infrastruttura e delle applicazioni. CloudFormation e l’AWS Cloud Development Kit (CDK) descrivono le risorse in modo dichiarativo o tramite codice che viene sintetizzato in CloudFormation. Livelli di configurazione come AWS OpsWorks e AWS Systems Manager applicano e riportano lo stato desiderato sulle istanze in flotte EC2 e ibride. Segreti, parametri e il baking delle immagini completano il ciclo di vita, consentendo implementazioni immutabili e sicure su larga scala.

Stack CloudFormation, Controllo delle Modifiche e Governance

Gli stack di CloudFormation sono l’unità di deployment. Progetta gli stack attorno ai confini del ciclo di vita e alla proprietà per minimizzare il raggio d’impatto (blast radius). Usa i parametri con parsimonia e preferisci valori predefiniti ragionati (opinionated defaults) con mappature o lookup su SSM. Esporta e importa solo valori stabili e condivisi tramite gli Output e Fn::ImportValue per evitare un accoppiamento stretto.

Gli stack nidificati incapsulano componenti riutilizzabili e mantengono ridotte le dimensioni dei template principali. Uno stack principale può passare parametri agli stack figli e consumarne gli output, abilitando architetture modulari (ad esempio, uno stack nidificato per una rete condivisa, consumato da uno stack applicativo). Mantieni gli stack nidificati focalizzati su un singolo scopo (VPC, livello dati, livello applicativo) e gestiscine le versioni in modo indipendente.

Gli StackSet distribuiscono un singolo template su più account e Regioni. Usa il modello di permessi gestito dal servizio (service-managed) con AWS Organizations per distribuire automaticamente nelle OU e includere automaticamente i nuovi account. Configura le preferenze operative (numero massimo di account/Regioni concorrenti, tolleranza ai fallimenti) per controllare il rollout. Gli override dei parametri per account o Regione consentono di adattare un template standard a vincoli locali. Monitora il drift degli StackSet e delle istanze di stack per rilevare modifiche fuori banda.

I set di modifiche (change set) forniscono aggiornamenti sicuri e revisionabili da un operatore umano. Esegui sempre CreateChangeSet e ispeziona l’impatto risorsa per risorsa, le sostituzioni e la potenziale perdita di dati prima di eseguire ExecuteChangeSet. Integra i set di modifiche in pipeline automatizzate per approvazioni controllate (gated approvals).

Il rilevamento delle deviazioni (drift detection) verifica che le risorse dello stack corrispondano al template. Esegui regolarmente il rilevamento delle deviazioni su stack e StackSet critici; tieni presente che non tutte le proprietà vengono valutate per tutti i tipi di risorsa (le proprietà non supportate vengono segnalate come “non verificate”). Tratta il drift come un incidente: investiga, acquisisci il contesto e correggi tramite un aggiornamento dello stack o codificando la deviazione e riapplicandola.

Le policy dello stack (stack policies) sono documenti JSON che proteggono le risorse critiche durante gli aggiornamenti. Nega gli aggiornamenti a risorse insostituibili (ad esempio, database di produzione, zone Route 53) e usa StackPolicyDuringUpdateBody per aprire temporaneamente un percorso chirurgico per una modifica specifica, per poi ripristinare la policy più restrittiva. Combina questa protezione con la protezione dalla terminazione e la DeletionPolicy (Retain/Snapshot) per avere dei guardrail. Per le risorse con stato esterno (bucket S3), pianifica i comportamenti di eliminazione. Se un bucket deve essere svuotato prima dell’eliminazione, implementa una risorsa personalizzata per eliminare gli oggetti alla cancellazione dello stack.

AWS CDK ed Estensibilità di CloudFormation

AWS CDK modella l’infrastruttura in linguaggi familiari (TypeScript, Python, Java, .NET, Go). I costrutti (constructs) sono i blocchi di base del CDK:

I costrutti L1 (CfnXxx) sono generati dalla specifica di CloudFormation e mappano uno a uno le risorse.
I costrutti L2 aggiungono un intento di alto livello e valori predefiniti sensati (ad esempio, ApplicationLoadBalancedFargateService).
I “pattern” L3 compongono più costrutti L2 per creare architetture pronte all’uso.

Un’app CDK contiene uno o più stack. Durante l’esecuzione di cdk synth, l’app risolve i lookup di contesto (ad esempio, ID di VPC), renderizza gli asset e produce un template CloudFormation. Prima del deployment, cdk bootstrap crea i bucket per gli asset e i ruoli dell’ambiente. Usa cdk diff per visualizzare un’anteprima delle modifiche, poi cdk deploy per inviare template e asset; internamente, il CDK utilizza i set di modifiche e mostrerà e chiederà conferma per le modifiche sensibili alla sicurezza (IAM o sostituzioni di risorse). Applica tag a stack e risorse tramite gli Aspects per imporre una strategia di tagging a livello di organizzazione. Laddove le astrazioni L2 non sono sufficienti, usa gli escape hatch (node.defaultChild) o scendi al livello dei costrutti L1.

Le risorse personalizzate (custom resources) di CloudFormation estendono l’IaC a qualsiasi cosa sia accessibile tramite API. Una risorsa personalizzata basata su Lambda riceve eventi di Create, Update e Delete con un RequestId, un PhysicalResourceId e delle proprietà. La funzione deve:

Essere idempotente e restituire successo/fallimento alla ResponseURL pre-firmata entro la finestra di timeout.
Impostare un PhysicalResourceId stabile per tracciare gli aggiornamenti e guidare la pulizia durante l’evento di Delete.
Gestire i tentativi (retry) e le attese di stabilizzazione per i servizi a valle con consistenza finale (eventual consistency).

Usa ruoli di esecuzione IAM con il minimo privilegio per la Lambda, includi un backoff esponenziale nelle chiamate API e correla i log tramite il RequestId. Per operazioni di grandi dimensioni o di lunga durata, considera l’uso di Step Functions con una risorsa personalizzata che attende un token di esecuzione. Quando applicabile, preferisci il CloudFormation Registry per provider riutilizzabili e versionati.

Segreti e Parametri nell’Infrastructure as Code

Non inserire mai i segreti in modo statico (hardcoding) nei template o nel codice. Utilizzare i riferimenti dinamici per risolvere i valori sensibili in fase di deploy:

Secrets Manager: {{resolve:secretsmanager:secret-id:SecretString:json-key:version-stage}}
SecureString Parameter Store: {{resolve:ssm-secure:parameter-name:version}}

I riferimenti dinamici impediscono che i segreti vengano memorizzati nel template dello stack o negli eventi. Non inserire i segreti negli Outputs o nelle proprietà delle risorse che CloudFormation registra in testo in chiaro. Concedere al ruolo di esecuzione di CloudFormation i permessi per decrittografare o recuperare i valori referenziati e limitare l’ambito delle chiavi KMS CMK ai principal che necessitano l’accesso.

Parameter Store è ideale per la configurazione non segreta (feature flag, ID di AMI, endpoint). Utilizzare parametri SSM versionati per creare rollback sicuri e promozioni atomiche tra ambienti diversi. In CDK, importare i valori con ssm.StringParameter.fromStringParameterName o fromSecureStringParameterAttributes per i valori sicuri, e integrare la lettura dei parametri negli user data o nei bootstrap dell’applicazione.

Secrets Manager è progettato per i controlli del ciclo di vita, la rotazione e l’auditing. Integrare la rotazione con i motori supportati (RDS, Aurora) o con Lambda personalizzate. Fare riferimento ai segreti a runtime piuttosto che incorporarli nelle AMI per evitare la proliferazione di materiale obsoleto. Per i carichi di lavoro containerizzati o serverless, iniettare i segreti tramite variabili d’ambiente supportate da riferimenti a Secrets Manager o montarli tramite i segreti di ECS/TaskDefinition; effettuare la rotazione con tempi di inattività minimi utilizzando pool di connessioni con TTL breve e meccanismi di retry.

Gestione della Configurazione e Infrastruttura Immutabile

AWS OpsWorks fornisce una gestione della configurazione con un approccio prescrittivo (opinionated). OpsWorks Stacks utilizza i cookbook di Chef e gli eventi del ciclo di vita (Setup, Configure, Deploy, Undeploy, Shutdown) per orchestrare la configurazione e i deployment delle applicazioni, e supporta il ripristino automatico (auto-healing) con controlli di integrità che arrestano/avviano o sostituiscono le istanze. Storicamente, OpsWorks offriva anche Chef Automate e Puppet Enterprise gestiti; oggi, molti team standardizzano l’uso di Systems Manager per l’orchestrazione basata su agent o gestiscono autonomamente i piani di controllo di Ansible/Chef/Puppet. Ansible non è integrato nativamente con OpsWorks; si utilizza invece Systems Manager State Manager per eseguire i playbook, oppure AWX/Ansible Automation Platform con connettività SSM Session Manager e inventario dinamico EC2.

AWS Systems Manager è il piano di controllo moderno per la configurazione ibrida:

State Manager impone lo stato desiderato tramite Associazioni che eseguono documenti SSM (YAML/JSON) secondo una pianificazione, un evento o all’avvio di un’istanza. Utilizza AWS-RunShellScript, AWS-ApplyAnsiblePlaybooks, AWS-ConfigureDocker e documenti personalizzati per far convergere la configurazione. Parametrizza le associazioni e definisci i target tramite tag per modifiche a livello di flotta.
La conformità della configurazione mostra lo stato delle associazioni e i risultati di Patch Manager. Utilizza le baseline delle patch per definire le classificazioni approvate, legarle a Finestre di Manutenzione (Maintenance Windows) e tracciare la conformità per tag di istanza, gruppo di patch o gruppo di risorse. Le Attivazioni Ibride (Hybrid Activations) integrano i nodi on-premise come istanze gestite per una governance uniforme.
Inventory registra pacchetti, file e aggiornamenti di Windows; Resource Data Sync esporta i dati su S3 e Athena per il reporting aziendale. Combina la conformità di SSM con le regole di AWS Config e la remediation automatica (runbook di Systems Manager Automation) per chiudere il cerchio dal rilevamento alla correzione.

L’infrastruttura immutabile elimina il drift e accelera il rollback. EC2 Image Builder codifica le pipeline delle immagini con:

Componenti (passaggi di installazione, hardening, validazione) espressi come documenti.
Ricette delle immagini (Image recipes) che compongono componenti e immagini di base.
Configurazioni dell’infrastruttura che definiscono sottoreti, gruppi di sicurezza, profili di istanza e logging.
Configurazioni di distribuzione per replicare le AMI tra Regioni e condividerle con altri account.

Aggiungi componenti di test per convalidare i benchmark CIS, l’integrità degli agent (SSM/CloudWatch) e gli smoke test dell’applicazione. Versiona le immagini ed etichettale con tag semantici. Pubblica gli ID delle AMI su Parameter Store (ad esempio, /app/frontend/ami) e fai riferimento ad essi nei modelli di avvio di Auto Scaling. Esegui il deployment con strategie rolling o blue/green; sostituisci le istanze invece di applicare patch in-place per preservare l’immutabilità. Inserisci i risultati delle scansioni di vulnerabilità (Amazon Inspector) nei gate di promozione della pipeline. Non incorporare segreti nelle immagini; recuperali all’avvio tramite l’Instance Metadata Service v2 e riferimenti a SSM/Secrets Manager.

Scenario di un Problema Pratico

Capital One deve standardizzare i deployment multi-account e multi-regione per una piattaforma rivolta ai clienti, imponendo al contempo una governance rigorosa, una gestione sicura dei segreti ed eliminando il drift della configurazione. L’ambiente si estende su centinaia di account in AWS Organizations, con controlli severi sull’accesso ai database e sull’hardening dei sistemi operativi.

Modellare l’infrastruttura con AWS CDK e sintetizzare in CloudFormation

Implementare costrutti L2/L3 per VPC, ALB, gruppi di Auto Scaling e Aurora. Usare cdk synth e cdk diff nella CI per generare e validare i template e i set di modifiche.
Perché CDK: Elevata capacità di composizione e riutilizzo tramite costrutti, policy programmatiche tramite Aspects per tagging e guardrail a livello di organizzazione, e integrazione nativa con CloudFormation per l’auditabilità.

Distribuire stack di base per la rete e i guardrail tramite CloudFormation StackSets

Creare StackSet gestiti dal servizio (service-managed) che hanno come target le OU di sicurezza e sandbox per distribuire endpoint VPC condivisi, allarmi CloudWatch standard e policy di autorizzazione IAM (boundaries). Abilitare il deployment automatico sui nuovi account con tolleranza ai guasti e controlli di concorrenza.
Perché StackSets: Rollout coerente su scala organizzativa con inclusione automatica dei nuovi account e rilevamento del drift integrato.

Proteggere le risorse critiche con policy dello stack e set di modifiche

Applicare policy dello stack che negano gli aggiornamenti ai cluster Aurora e alle zone Route 53. Richiedere CreateChangeSet e un’approvazione manuale prima di ExecuteChangeSet nella pipeline per l’ambiente di produzione.
Perché policy dello stack/set di modifiche: Impongono mutazioni con il minimo privilegio e forniscono una revisione manuale prima di modifiche ad alto rischio.

Estendere l’IaC con risorse personalizzate supportate da Lambda

Implementare una risorsa Custom::S3BucketCleanup per svuotare i bucket dell’applicazione alla cancellazione dello stack e una Custom::AuroraParameterTuner che applica i parametri del motore dopo la creazione.
Perché le risorse personalizzate: Colmano le lacune funzionali nel provisioning dichiarativo mantenendo il ciclo di vita legato allo stack.

Centralizzare segreti e configurazione con Secrets Manager e Parameter Store

Archiviare le credenziali del database e le chiavi API in Secrets Manager con Lambda per la rotazione; pubblicare gli ID delle AMI, i feature flag e gli endpoint su Parameter Store. Fare riferimento ai valori tramite riferimenti dinamici in CloudFormation e importazioni CDK a runtime per le applicazioni.
Perché questi servizi: Separazione delle responsabilità: segreti con rotazione e audit, parametri per la configurazione non segreta e facile promozione.

Imporre lo stato desiderato e la conformità tramite Systems Manager State Manager

Creare associazioni per installare agent, configurare le impostazioni del sistema operativo e applicare playbook Ansible dove necessario. Usare Patch Manager con Finestre di Manutenzione per l’applicazione di patch fuori orario e dashboard di conformità aggregate tramite Resource Data Sync.
Perché State Manager: Convergenza basata su agent su EC2 e on-premise con reporting continuo della conformità e remediation su larga scala.

Adottare un’infrastruttura immutabile con EC2 Image Builder

Costruire AMI con hardening (hardened) che includono componenti per le baseline CIS, agent SSM/Inspector e dipendenze di runtime dell’applicazione. Eseguire test, pubblicare gli ID delle AMI su Parameter Store e collegare i modelli di avvio di Auto Scaling ai parametri versionati. Eseguire il deployment tramite aggiornamenti rolling; attivare l’aggiornamento delle istanze (instance refresh) agli aggiornamenti delle AMI.
Perché Image Builder: Immagini riproducibili e testabili che eliminano il drift e riducono il tempo medio di ripristino (MTTR) attraverso rollback rapidi.

Orchestrazione e governance della pipeline

Implementare una pipeline multi-fase che esegue cdk synth/diff, crea set di modifiche, si mette in pausa per l’approvazione e poi esegue. Usare EventBridge per attivare gli aggiornamenti degli StackSet a seguito di modifiche nel repository. Aggiungere scansioni notturne per il rilevamento del drift e aprire item in OpsCenter per le discrepanze.
Perché questo approccio: Continuous delivery con promozioni auditabili, rilevamento proattivo del drift e remediation automatizzata attraverso responsabilità dei servizi ben definite.

← Pipeline CI · Tutti i domini · Monitoraggio →

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