Amazon SAP-C02: Distribuzione, automazione e DevOps — Guida allo studio

By Laurynas Brazys · 31 July 2026 · #amazon #sap-c02 #certification #exam-prep #study-guide

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

Infrastruttura come Codice e Gestione degli Ambienti

Tratta l’infrastruttura come codice (IaC) come l’unica fonte di verità per gli ambienti, incorporando reti, IAM e topologia applicativa in artefatti riutilizzabili e versionati. Scegli CloudFormation per un controllo rigoroso e dichiarativo e una profonda integrazione con AWS, e usa l’AWS Cloud Development Kit (CDK) quando costrutti di livello superiore e astrazioni native del linguaggio migliorano la produttività degli sviluppatori; forza sempre la CI a sintetizzare il CDK in template e a memorizzare gli artefatti in un bucket S3 crittografato e versionato. Usa i CloudFormation StackSets per un’istanziazione coerente degli stack tra account e regioni diverse e abilita il rilevamento delle deviazioni (drift detection) combinato con la remediation automatizzata tramite Systems Manager quando il drift indica un’entropia di configurazione. Crea “golden image” con EC2 Image Builder o Packer e pubblica le AMI su account e regioni tramite pipeline automatizzate; questo supporta deployment immutabili e riduce il drift di configurazione post-lancio. Sii deliberato con i change set di CloudFormation, la protezione dalla terminazione e le policy di aggiornamento per evitare la sostituzione involontaria di risorse che può causare la perdita di dati. Le trappole comuni includono l’incorporamento di segreti nei template, l’affidarsi a modifiche manuali superficiali che compromettono il rilevamento del drift, o la concessione di ruoli di esecuzione di CloudFormation eccessivamente ampi—limita i ruoli di esecuzione al principio del privilegio minimo (least privilege) e conserva la cronologia di CloudTrail e Config per la verificabilità (auditability). I compromessi (trade-off) sono chiari: il CDK accelera lo sviluppo ma richiede una CI/CD disciplinata per evitare stack di runtime non sincronizzati; CloudFormation puro è più rigido ma immediatamente verificabile.

Pipeline CI/CD e Strategie di Deployment

Progetta pipeline che separano le fasi di build, test e deploy e rendono automatiche le decisioni di rollback. AWS CodePipeline, CodeBuild e CodeDeploy forniscono un percorso completamente gestito per i flussi dal codice sorgente alla produzione, mentre sistemi di terze parti (GitHub Actions, Jenkins, GitLab) si integrano con i servizi AWS per l’archiviazione degli artefatti (S3), i registri dei container (ECR) e gli hook di deployment. Per le strategie di runtime, preferisci i deployment immutabili o blue/green per i servizi stateful o sessionful per eliminare il drift di configurazione in-place; usa i deployment canary con spostamento del traffico (traffic shifting) per una riduzione incrementale del rischio. Per Lambda, usa alias e spostamento del traffico ponderato con allarmi CloudWatch o CodeDeploy per il rollback automatizzato. Per ECS/EKS, combina i controller di deployment (CodeDeploy, AWS App Mesh o strategie native di Kubernetes) con il draining dei target group dell’ALB e gli hook del ciclo di vita per garantire uno spegnimento controllato (graceful shutdown). Fai attenzione alle modifiche dello schema del database: progetta migrazioni retrocompatibili e usa feature flag (AWS AppConfig) o “dark launch” per disaccoppiare il rollout del codice dall’evoluzione dello schema. Le considerazioni su costo e velocità sono importanti: i canary rallentano i rollout ma minimizzano il raggio d’impatto (blast radius), mentre il blue/green parallelo raddoppia il costo dell’infrastruttura durante la finestra di transizione (cutover). Integra sempre policy di deployment, controlli di integrità (health check) e rollback automatici nelle pipeline per evitare interventi manuali durante gli incidenti.

Automazione, Conformità della Configurazione e Osservabilità

L’eccellenza operativa dipende dalla remediation automatizzata, da una configurazione coerente e da un’osservabilità olistica. AWS Systems Manager fornisce Parameter Store per la configurazione, documenti di Automation per i runbook, Patch Manager per la manutenzione di base (baseline) e Session Manager per il troubleshooting senza bastion host. Usa EventBridge come bus di eventi centrale per l’automazione disaccoppiata—instrada gli eventi di CloudTrail, Config o delle applicazioni verso Lambda o Step Functions per una remediation orchestrata. Applica “guardrail” con le regole di AWS Config e un Config Aggregator per verificare più account, e implementa playbook di remediation automatizzata tramite Systems Manager o EventBridge per le risorse non conformi. Per l’osservabilità, strumenta i servizi con i parametri (metriche) e i log di CloudWatch, abilita X-Ray o AWS Distro for OpenTelemetry per il tracciamento distribuito (distributed tracing), e centralizza i log con le sottoscrizioni di CloudWatch Logs o Kinesis Firehose in un data lake S3 centralizzato e uno stack di analisi. Le trappole comuni includono una conservazione dei log illimitata che fa lievitare i costi, metriche personalizzate ad alta cardinalità che fanno esplodere i costi delle metriche, ID di correlazione mancanti che rendono inutili le tracce, e la mancata verifica dei runbook di remediation in ambienti non di produzione. I compromessi ruotano attorno alla granularità della telemetria rispetto ai costi di ingestione e archiviazione; il campionamento delle tracce e una breve conservazione riducono i costi ma possono nascondere fallimenti rari e critici. Progetta allarmi e dashboard mirati a segnali che richiedono un’azione (actionable) per mantenere gestibile il carico operativo.

Prestazioni, servizi stateful, sicurezza e considerazioni cross-region

Scegliere i servizi stateful e di storage in base al pattern di accesso, ai requisiti di latenza e di coerenza. Le cache in-memory offrono letture inferiori al millisecondo; ElastiCache (Redis) supporta set ordinati ideali per le classifiche (leaderboard) e fornisce replica, persistenza e Global Datastore per la località di lettura cross-region. DynamoDB è eccellente per lo storage durevole e su larga scala e può essere abbinato a DAX per l’accelerazione delle letture, sebbene DAX sia più indicato per accessi a livello di singolo elemento e memorizzabili nella cache, con compromessi in termini di consistenza finale (eventual consistency). Per le applicazioni legacy basate su file, considerare Amazon FSx for NetApp ONTAP o Amazon EFS con DataSync per la compatibilità in scenari di lift-and-shift; per la semantica SMB/NFS, FSx è spesso l’opzione a più basso rischio. La crittografia e la replica nascondono insidie sottili: le chiavi AWS KMS sono regionali e devono essere gestite per ogni Regione per la replica cross-region di S3, oppure si possono usare chiavi multi-regione per semplificare i pattern di accesso; prestare attenzione alle policy delle chiavi e alle concessioni cross-account. Le funzioni Lambda in un VPC soffrono di cold start a causa della creazione di ENI: mitigare il problema con endpoint VPC, pacchetti di dimensioni ridotte, concorrenza allocata (provisioned concurrency) o utilizzando Lambda al di fuori del VPC con RDS Proxy. Valutare il rapporto tra costi e resilienza: le tabelle globali e la replica cross-region migliorano RTO/RPO a un costo maggiore; la concorrenza allocata riduce la latenza ma aumenta la spesa di base. Nella scelta delle architetture, considerare le esigenze di durabilità dei dati, le tempistiche di DR e i limiti delle risorse per account.

Problema pratico: scenario d’uso

Scenario: SkyForge Games gestisce un ambiente AWS esistente con account di produzione e di staging in due Regioni. L’attuale classifica (leaderboard) è implementata in DynamoDB e servita da API Lambda distribuite tramite CodePipeline; i giocatori si aspettano una latenza di lettura nell’ordine dei microsecondi e un downtime quasi nullo durante i frequenti rilasci di nuove funzionalità.

Sfida: Fornire letture della classifica nell’ordine dei microsecondi, mantenendo la durabilità e costruendo una pipeline CI/CD sicura e automatizzata che supporti implementazioni rapide, con capacità di rollback, tra account e Regioni.

Approccio consigliato:

Effettuare il provisioning di un cluster ElastiCache for Redis con Cluster Mode Enabled nella Regione primaria per l’hot-path della classifica, con repliche distribuite tra le AZ e persistenza Redis (AOF) abilitata; configurare Global Datastore per la località di lettura nella Regione secondaria.
Mantenere DynamoDB come fonte di verità (source of truth); utilizzare DynamoDB Streams + Lambda (o Kinesis Data Streams) per aggiornare Redis in modo asincrono, garantendo la consistenza finale (eventual consistency) e la riproducibilità (replayability) per il ripristino.
Implementare una pipeline basata su CDK (CDK Pipelines o CodePipeline attivata da Git) che sintetizzi i template, crei gli artefatti in S3/ECR crittografati e distribuisca l’infrastruttura tramite CloudFormation StackSets agli account/Regioni di destinazione; includere smoke test automatizzati e fasi di approvazione (approval gates).
Distribuire le modifiche all’applicazione utilizzando una strategia canary/blue-green: usare alias pesati di Lambda o lo spostamento del traffico tra i target group di un ALB con allarmi CloudWatch e rollback automatico; strumentare con CloudWatch, X-Ray e controlli canary sintetici.

Motivazione: Utilizzare Redis per letture realmente inferiori al millisecondo, mantenendo la durabilità e la riproducibilità di DynamoDB; una pipeline CI/CD con CDK e StackSets fornisce implementazioni multi-account coerenti e verificabili, mentre lo spostamento del traffico (traffic-shifting) e l’osservabilità consentono rilasci iterativi sicuri con rollback rapido.

← Ottimizzazione dei costi e governance · Tutti i domini

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