Google ACE: Implementazione, configurazione e automazione — Guida allo studio

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

Fa parte della Google Associate Cloud Engineer — Guida allo studio. Esercitati con risposte verificate nel centro esami Google, oppure fai test cronometrati su ExamRoll.io.

Panoramica

Il deployment, la configurazione e l’automazione su Google Cloud si concentrano sulla delivery di modifiche ripetibile, verificabile e sicura. Le buone pratiche si basano su infrastructure as code (IaC), template dichiarativi, artefatti immutabili e pipeline standardizzate. L’eccellenza operativa deriva dalla progettazione orientata all’idempotenza, dall’anteprima delle modifiche, dall’applicazione delle policy e dalla pianificazione di rollout controllati con chiari percorsi di rollback. Le sezioni seguenti forniscono pattern pratici, esempi di comandi e le motivazioni alla base delle scelte progettuali, includendo errori comuni e compromessi (trade-off).

Fondamenti di Infrastructure as Code e Configurazione

Principi:

I template dichiarativi descrivono lo stato finale desiderato; gli strumenti riconciliano lo stato attuale per farlo corrispondere. Ciò migliora l’idempotenza, la ripetibilità e la verificabilità.
L’infrastruttura immutabile prevede il deployment di nuove istanze o revisioni anziché la modifica di quelle esistenti, semplificando il rollback e riducendo il drift.
Separazione delle responsabilità (separation of concerns): parametrizzare i valori specifici dell’ambiente riutilizzando moduli o template condivisi.

Terraform su Google Cloud:

Configurazione: i file HCL definiscono risorse, variabili e output. Utilizzare i moduli per incapsulare VPC, service account o cluster GKE; pubblicare internamente i moduli condivisi per standardizzare i pattern.
Stato: Mantenere lo stato remoto e versionato. Utilizzare un backend Cloud Storage con il versioning degli oggetti e la conservazione (retention) del bucket, a seconda dei casi.
- Esempio di blocco backend:

undefined

Modalità di fallimento: lo stato locale o i bucket non versionati comportano il rischio di perdita di dati e scritture concorrenti. Applicare l’accesso con privilegi minimi (least-privilege) al bucket di stato; preferire credenziali a breve durata e l’impersonificazione del service account rispetto all’uso di chiavi.
Plan e apply: terraform plan fornisce un’anteprima; bloccare gli apply in CI/CD con un’approvazione umana per l’ambiente di produzione. Usare -target con parsimonia; un uso frequente di target aumenta il rischio di drift.
Moduli: versionare i moduli semanticamente; fissare (pin) le versioni per evitare modifiche non pianificate. Validare con terraform validate e controlli di policy prima dell’apply.
Import e drift: terraform import porta le risorse esistenti sotto gestione; far seguire da un’attenta revisione dello stato. Rilevare il drift eseguendo regolarmente terraform plan.
Esecuzione remota: eseguire Terraform in job di Cloud Build o Cloud Run con Workload Identity Federation per evitare le chiavi dei service account. Mettere in cache i provider per ridurre i tempi di build.

Deployment Manager:

Sebbene molti team standardizzino l’uso di Terraform, potresti incontrare Deployment Manager. Aggiorna un deployment senza downtime aggiornando la configurazione:

undefined

Standard di configurazione:

Nomenclatura: applicare nomi coerenti e analizzabili (parseable) che includano ambiente, regione, scopo e sequenza, ad es., vpc-prod-usw1-core.
Etichette (Labels): associare etichette come env, cost_center, owner e app a tutte le risorse; imporle tramite policy o validazione.
Tag: usare i tag di rete per definire lo scope delle regole firewall; evitare di sovraccaricare i tag per l’identità o la proprietà (le etichette sono più adatte).
Metadati: sfruttare i metadati dell’istanza per script di avvio e configurazione; preferire metadati con checksum o flag di versione per controllare le riesecuzioni. Evitare di inserire segreti nei metadati; usare Secret Manager.

API, abilitazione dei servizi, quote e service account:

Abilitare i servizi richiesti nelle prime fasi dell’automazione:

undefined

Validare il margine di quota (quota headroom) durante la pianificazione; i test di scalabilità dovrebbero includere controlli sulle quote per evitare il throttling.
Utilizzare service account dedicati per ogni workload e ambiente; concedere ruoli IAM con privilegi minimi (least-privilege) allo scope più ristretto possibile. Preferire l’appartenenza a gruppi per l’accesso umano e l’impersonificazione del service account per l’automazione.

Pipeline di Delivery e Promozione degli Artefatti

Cloud Build:

Definire gli step di Cloud Build per compilare (build), testare e pacchettizzare gli artefatti. Usare le sostituzioni per i valori dinamici e Secret Manager per le credenziali.
Attivare (trigger) le build a partire dalle modifiche al codice sorgente; isolare i service account di build per repository o ambiente e concedere solo i permessi necessari.
Mettere in cache i layer Docker e le dipendenze del linguaggio per ridurre i tempi di build. Prestare attenzione ai limiti di build concorrenti e alle quote dei worker effimeri.

Promozione degli artefatti:

Archiviare le immagini dei container o i pacchetti del linguaggio in Artifact Registry. La promozione avviene tramite:
- Ri-etichettatura (re-tagging) dei digest immutabili per ambiente (es., :qa, :prod) o
- Copia degli artefatti in un repository specifico per l’ambiente.
Compromessi (Trade-off): un singolo repository con tag semplifica l’individuazione (discovery) ma richiede una governance rigorosa; i repository per ambiente rafforzano l’isolamento e l’applicazione delle policy.

Cloud Deploy:

Modellare una pipeline di delivery con target ordinati (es., dev → qa → prod). Le release fanno riferimento a un digest di artefatto specifico e a un manifest di deployment.
Per GKE e Cloud Run, Cloud Deploy utilizza configurazioni Skaffold per il rendering e l’applicazione dei manifest. Configurare approvazioni, verifiche e gate.
Rollout e rollback:
- La strategia Canary con spostamento incrementale del traffico riduce il raggio d’impatto.
- La strategia Blue/green consente un passaggio (cutover) e un rollback rapidi al costo di una capacità aggiuntiva.
- Eseguire il rollback fissando (pinning) l’ultima release funzionante; evitare correzioni sul posto (in-place) che creano drift.
Modalità di fallimento: permessi del cluster non corrispondenti, API mancanti ed errori nello schema del manifest. Rilevarli precocemente eseguendo il rendering dei manifest durante la build e validandoli rispetto alle policy del cluster.

Pianificazione sicura delle modifiche:

Richiedere un’anteprima (plan o render), test automatizzati, validazione delle policy e approvazione umana per la produzione.
Per i gruppi di istanze gestite di Compute Engine, ottimizzare le impostazioni della policy di aggiornamento maxSurge/maxUnavailable e degli health check per evitare il sovradimensionamento (overprovisioning) quando la prontezza (readiness) dell’applicazione è lenta.

Operazioni da Riga di Comando e Gestione dell’Ambiente

Configurazioni di Cloud Shell e gcloud:

Cloud Shell fornisce un ambiente di amministrazione gestito con gcloud pre-autenticato e una home directory persistente.
Utilizza le configurazioni con nome per cambiare rapidamente account, progetti e region: gcloud config configurations create prod gcloud config set project my-prod gcloud config set compute/region us-central1 gcloud config set compute/zone us-central1-a gcloud config configurations activate prod
Ispeziona la configurazione attiva con gcloud config list. Per GKE, acquisisci le credenziali: gcloud container clusters get-credentials my-cluster –region us-central1

Pattern di comandi per Compute:

Crea una VM con un indirizzo IP interno riservato: gcloud compute addresses create license-ip –region=us-central1 –subnet=default –addresses=10.0.3.21 gcloud compute instances create license-server –zone=us-central1-a –subnet=default –private-network-ip=10.0.3.21 –tags=license
Crea una VPC personalizzata, una subnet e una regola firewall: gcloud compute networks create core –subnet-mode=custom gcloud compute networks subnets create core-us –network=core –range=10.0.0.0/20 –region=us-central1 gcloud compute firewall-rules create allow-https –network=core –allow=tcp:443 –target-tags=web

Pattern per IAM:

Concedi un ruolo a livello di progetto: gcloud projects add-iam-policy-binding my-project –member=group:ops@example.com –role=roles/logging.viewer
Copia ruoli personalizzati tra progetti: gcloud iam roles copy myCustomRole –source=my-dev –destination=my-prod

Pattern per lo Storage:

Crea un bucket e carica oggetti: gcloud storage buckets create gs://backups-prod –location=us-central1 –class=coldline –uniform-bucket-level-access gcloud storage cp ./backup.tar.gz gs://backups-prod/
Configura il ciclo di vita tramite file e applicalo con gcloud storage buckets update –lifecycle-file=policy.json

Abilitazione e verifica delle API:

Abilita Pub/Sub per un’applicazione: gcloud services enable pubsub.googleapis.com
Elenca i servizi abilitati: gcloud services list –enabled

Governance, Drift e Automazione

Drift della configurazione e applicazione delle policy:

Rileva il drift eseguendo terraform plan a intervalli regolari; interrompi le build in caso di modifiche inattese.
Applica i vincoli delle policy dell’organizzazione (es. limitare gli IP esterni) e convalida le configurazioni delle risorse con la policy-as-code prima dell’apply.
Per Kubernetes, usa Config Sync e Policy Controller per riconciliare continuamente e bloccare le modifiche non conformi.
Auditabilità: affidati ai log di Admin Activity e Data Access; instradali verso BigQuery per l’analisi. Usa Cloud Asset Inventory per query sullo stato point-in-time e time-travel.

Quote e limiti:

Ispeziona le quote per regione e progetto; pianifica un margine (headroom) per l’autoscaling e i rollout:

undefined

Richiedi aumenti prima di una crescita pianificata o di rollout di grandi dimensioni.

Task operativi automatizzati:

Cloud Scheduler attiva endpoint HTTP, topic Pub/Sub o Workflows secondo una pianificazione cron. Assicurati che gli handler siano idempotenti; configura i tentativi (retry) e i topic dead-letter.
Workflows orchestra l’automazione multi-step attraverso le API di Google con tentativi (retry), passaggi paralleli e logica di compensazione.
I job di Cloud Run eseguono task batch o amministrativi containerizzati on-demand o tramite Scheduler. Preferisci i job per carichi di lavoro una tantum o iterativi; usa i permessi minimi sul service account del job.

Sicurezza dei rollout e osservabilità:

Integra health check e readiness probe nei servizi. Per i MIG con avvio lento, aumenta il ritardo iniziale (initial delay) per prevenire azioni di scaling premature.
Raccogli le metriche di deployment e gli error budget; metti in pausa o interrompi automaticamente i rollout quando gli SLO peggiorano.

Scenario Pratico

Altostrat Media ha la necessità di standardizzare i deployment multi-ambiente per un servizio basato su GKE, eliminando al contempo il drift della configurazione e garantendo un rollback rapido. Deve anche riservare un indirizzo IP interno fisso per un server di licenze legacy senza riconfigurare l’applicazione.

Creare moduli Terraform di base e state remoto

Implementa moduli per VPC, subnet, GKE, service account e regole firewall. Configura un backend Cloud Storage con versioning e una policy di conservazione (retention policy) per il bucket dello state.
Motivazione: La modularizzazione promuove il riutilizzo e la coerenza; uno state remoto e versionato abilita la collaborazione, la recuperabilità e il locking.

Abilitare i servizi richiesti e definire identità di automazione con il principio del privilegio minimo (least-privilege)

Abilita compute.googleapis.com, container.googleapis.com, clouddeploy.googleapis.com, artifactregistry.googleapis.com.
Crea service account per ogni ambiente per Terraform, Cloud Build e Cloud Deploy; concedi ruoli minimi (es. roles/container.admin a chi effettua il deploy, non a chi fa la build).
Motivazione: L’abilitazione preventiva e la definizione mirata dei ruoli (role scoping) riducono i fallimenti di deployment e limitano il raggio d’impatto (blast radius).

Effettuare il provisioning del networking e riservare l’IP legacy

Con Terraform, crea una VPC custom, subnet regionali e regole firewall basate su network tag.
Riserva l’IP interno:

undefined

Motivazione: Il networking dichiarativo garantisce la ripetibilità; riservare l’IP preserva gli assunti dell’applicazione.

Creare gli artefatti con Cloud Build e pubblicarli su Artifact Registry

Definisci cloudbuild.yaml per eseguire test, creare il container, scansionarlo e inviare (push) un digest immutabile ad Artifact Registry.
Motivazione: Artefatti immutabili e scansionati sono la base per promozioni sicure e per la tracciabilità (provenance).

Configurare la pipeline di Cloud Deploy con target dev → qa → prod

Definisci una delivery pipeline e i suoi target; fai riferimento alla configurazione di Skaffold per generare (render) i manifest. Richiedi l’approvazione manuale per prod e configura le verifiche.
Motivazione: Una promozione strutturata impone controlli; le policy per-target evitano deployment accidentali in produzione.

Effettuare il rollout degli aggiornamenti GKE con una strategia canary e controlli di integrità (health gates)

Usa una policy di rollout canary per spostare il 10%, poi il 50%, e infine il 100% del traffico, subordinatamente ai controlli su SLO e tasso di errore.
Motivazione: Il rilascio progressivo (progressive delivery) riduce il rischio e fornisce punti di rollback naturali.

Eliminare il drift con plan pianificati e controlli di policy

Un job notturno esegue terraform plan e un validatore di policy-as-code; invia alert in caso di differenze (diff) o violazioni inattese.
Motivazione: Il rilevamento precoce impedisce al drift di accumularsi e di compromettere le future operazioni di apply.

Operazionalizzare la VM del server di licenze con l’IP riservato

Crea la VM associandola all’indirizzo riservato e ai tag appropriati:

undefined

Motivazione: Garantisce la raggiungibilità senza modificare l’applicazione; i tag mantengono le regole firewall strettamente circoscritte.

Automatizzare i task ricorrenti con Scheduler, Workflows e job

Cloud Scheduler attiva un Workflow per la rotazione delle chiavi dei service account, dove inevitabile, e per avviare un job di Cloud Run per i task settimanali di vacuum del database.
Motivazione: La pianificazione centralizzata unita all’orchestrazione produce affidabilità e osservabilità, con tentativi (retry) e compensazione.

Pianificare i rollback e validare le soglie di readiness

Definisci playbook di rollback per ri-promuovere l’ultima release valida. Ottimizza le readiness probe e, per eventuali carichi di lavoro basati su MIG, aumenta i ritardi iniziali degli health check per adeguarli al tempo di riscaldamento (warm-up) dell’app.
Motivazione: Un rollback pre-pianificato e health check ottimizzati prevengono fallimenti a cascata e overprovisioning durante gli incidenti.

Questo approccio allinea artefatti immutabili, infrastruttura dichiarativa, promozioni controllate (gated) e automazione basata sul principio del privilegio minimo per fornire operazioni sicure, auditabili e ripetibili su Google Cloud.

← Archiviazione · Tutti i domini · Monitoraggio →

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