Google PCD: Continuous Delivery, configurazione e automazione dell'infrastruttura — Guida allo studio

By Laurynas Brazys · 3 September 2026 · #google #PCD #certification #exam-prep #study-guide

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

Panoramica

La continuous delivery su Google Cloud integra l’automazione delle build, la gestione degli artefatti, l’orchestrazione dei deployment, l’infrastructure as code e una solida governance per distribuire le modifiche in modo ripetuto e sicuro. Pipeline robuste abbinano artefatti immutabili e configurazioni dichiarative con policy e auditabilità. Questa sezione spiega le scelte di progettazione, le pratiche operative e le modalità di fallimento comuni nell’implementazione end-to-end di Cloud Build, Cloud Deploy, Artifact Registry, Terraform, Kubernetes, feature flag e controlli di governance.

Orchestrazione di Build e Deploy

Cloud Build

• Trigger: Collegano le build a eventi del codice sorgente (push su rami, tag, PR) o a pianificazioni. Preferire espressioni regolari (regex) su rami o tag per garantire che solo i ref desiderati attivino la build. I trigger possono essere eseguiti con un service account specifico per applicare il principio del privilegio minimo; non fare affidamento su quello predefinito se le build necessitano di un ampio accesso alle API.
• Passaggi di build (step): Ogni passaggio viene eseguito in un container. Utilizzare builder appositi (docker, gcloud) o builder personalizzati quando la toolchain predefinita non è sufficiente. Separare i passaggi per compilazione, unit test, integration test, linting, scansioni di sicurezza e pacchettizzazione degli artefatti, in modo che i fallimenti siano attribuibili e la cache sia efficace.
• Sostituzioni: Utilizzare variabili predefinite (PROJECT_ID, SHORT_SHA) e sostituzioni personalizzate (con prefisso $_) per build parametrizzate. Mantenere i valori specifici dell’ambiente fuori dalla logica di build; passarli come sostituzioni o risolverli successivamente durante il deploy.
• Service account: Il service account di Cloud Build (PROJECT_NUMBER@cloudbuild.gserviceaccount.com) richiede ruoli espliciti (ad esempio, scrittura su Artifact Registry, amministratore delle release di Cloud Deploy). Assegnare ruoli minimi e limitati per progetto. Per le risorse private, utilizzare pool privati (Private Pool) con connettività VPC.
• Artefatti: Pubblicare immagini immutabili su Artifact Registry e, facoltativamente, caricare artefatti non container su Cloud Storage tramite la sezione artifacts. Taggare le immagini sia con una versione semantica sia con il digest del commit; utilizzare i digest delle immagini nei deployment per evitare il “tag drift” (disallineamento dei tag).

Esempio di configurazione di Cloud Build:

• cloudbuild.yaml: steps:

  • name: gcr.io/cloud-builders/docker args: [“build”,"-t","$REGION-docker.pkg.dev/$PROJECT_ID/app/app:${SHORT_SHA}","."]
  • name: gcr.io/cloud-builders/docker args: [“push”,"$REGION-docker.pkg.dev/$PROJECT_ID/app/app:${SHORT_SHA}"]
  • name: gcr.io/cloud-builders/gcloud args: [“deploy”,“releases”,“create”,“app-${SHORT_SHA}”,"–delivery-pipeline=app-pipeline","–images=app=$REGION-docker.pkg.dev/$PROJECT_ID/app/app@sha256:${COMMIT_SHA}"] substitutions: _REGION: us-central1 serviceAccount: projects/$PROJECT_ID/serviceAccounts/cb-deployer@$PROJECT_ID.iam.gserviceaccount.com

• Esempio di trigger: gcloud builds triggers create cloud-source-repositories –repo=my-repo –branch-pattern=^main$ –build-config=cloudbuild.yaml –service-account=cb-deployer@$PROJECT_ID.iam.gserviceaccount.com

Cloud Deploy

• Le delivery pipeline definiscono una sequenza ordinata di stage e target. I target fanno riferimento a cluster GKE, servizi Cloud Run o altri runtime supportati. Contrassegnare gli stage di produzione con requireApproval per bloccare la promozione automatica.
• I rollout associano una release a un target; la promozione fa avanzare una release attraverso i target. Utilizzare la distribuzione progressiva (canary, blue/green) e gli hook per controlli pre-deployment e post-deployment.
• Modalità di fallimento: L’uso di tag mutabili causa aggiornamenti non intenzionali; fissare sempre i digest. La mancanza di permessi IAM per l’account del deployer blocca i rollout. Manifest non renderizzabili o disallineamenti di configurazione specifici dell’ambiente portano a fallimenti della promozione; validare i manifest durante la build.

Esempio di definizioni per Cloud Deploy:

• delivery-pipeline.yaml: apiVersion: deploy.cloud.google.com/v1 kind: DeliveryPipeline metadata: name: app-pipeline serialPipeline: stages:

  • targetId: dev
  • targetId: prod strategy: standard: verify: true requireApproval: true

• targets.yaml: apiVersion: deploy.cloud.google.com/v1 kind: Target metadata: name: dev gke: cluster: projects/PROJECT/locations/REGION/clusters/DEV_CLUSTER

  Definizione del target di produzione

  apiVersion: deploy.cloud.google.com/v1 kind: Target metadata: name: prod gke: cluster: projects/PROJECT/locations/REGION/clusters/PROD_CLUSTER

• Release e promozione: gcloud deploy releases create app-20260903-1 –delivery-pipeline=app-pipeline –region=us-central1 –images=app=us-central1-docker.pkg.dev/PROJECT/app/app@sha256:IMAGE_DIGEST gcloud deploy releases promote –delivery-pipeline=app-pipeline –release=app-20260903-1 –region=us-central1

Artefatti e Integrità della Supply Chain

Artifact Registry

• Repository: Creare repository separati per team o ambiente per limitare l’ambito di IAM e della pulizia. Utilizzare repository regionali vicini ai builder e ai runtime per ridurre l’egress e la latenza. I formati dei pacchetti includono immagini Docker e pacchetti di linguaggi (Maven, npm, PyPI).
• Conservazione (Retention): Definire policy di pulizia per rimuovere i tag non referenziati o vecchi, mantenendo una finestra di sicurezza per il rollback. Evitare una conservazione aggressiva che rimuova l’ultima versione funzionante nota.
• Provenienza e SBOM: Abilitare la provenienza della build (provenance) in modo che le immagini contengano attestazioni conformi a SLSA. Generare SBOM durante la build e archiviarli come attestazioni, migliorando il triage delle vulnerabilità.
• Scansione delle vulnerabilità: Abilitare l’analisi dei container e interrompere la build o bloccare la promozione quando vengono rilevate CVE ad alta gravità senza fix disponibili o eccezioni alla policy.
• Compromessi: Centralizzare tutti gli artefatti in un unico progetto semplifica la governance ma può creare un ampio raggio d’impatto (blast radius); repository per ambiente o per applicazione riducono il rischio ma aumentano l’overhead di gestione.

Applicazione delle policy sulla supply chain

• Binary Authorization su GKE può richiedere attestazioni (ad esempio, “creato da Cloud Build nel progetto X”, “nessuna CVE critica”). Integrare con i gate di Cloud Deploy per fermare le release non conformi.
• Modalità di fallimento: Fare affidamento su tag mutabili, scansioni disabilitate o pull non autenticati può portare software non verificato in produzione. Fissare i digest e richiedere le attestazioni.

Infrastructure as Code e GitOps

Terraform

• Configurazione e moduli: Scomponi in moduli riutilizzabili con input/output chiari e versioni semantiche. Pubblica i moduli in un repository o registro condiviso; fissa le versioni (pinning) per evitare modifiche impreviste.
• Stato (State): Utilizza il backend GCS per lo stato remoto con IAM a livello di bucket, versioning degli oggetti e CMEK. Proteggi lo stato da modifiche manuali e assicurane la crittografia. Evita di salvare segreti nello stato leggendoli da Secret Manager al momento dell’apply e usando le data source con parsimonia.

undefined

• Pianificazione e applicazione (Plan e Apply): Esegui terraform plan con -out e fai revisionare il diff da un operatore umano o da un gate automatizzato; applica solo il piano precedentemente approvato. Usa -refresh-only o -detailed-exitcode nei job di rilevamento del drift.
• Separazione degli ambienti: Usa progetti, bucket per lo stato e service account separati per ogni ambiente. Per organizzazioni complesse, preferisci una directory per ambiente con file di variabili piuttosto che i workspace. Non condividere mai lo stato tra ambienti diversi.
• Modalità di fallimento: Applicazioni concorrenti corrompono lo stato; imponi la serializzazione tramite CI/CD e locking (GCS usa le precondizioni degli oggetti). Le modifiche manuali dalla console causano drift; limita le mutazioni dirette ed esegui job di plan periodici.

Configurazione dichiarativa di Kubernetes

• Manifest: Mantieni gli oggetti Kubernetes dichiarativi; evita i comandi imperativi di kubectl nei flussi di produzione. Fissa i digest delle immagini e i resource requests/limits.
• Kustomize: Usa una base + overlay per gestire le patch specifiche per ambiente senza creare fork dei chart.

undefined

• Helm: Usa values files separati per ogni ambiente; documenta la precedenza (i valori da riga di comando sovrascrivono i values files, che a loro volta sovrascrivono i default del chart). Esegui il templating e il rendering in CI (skaffold render o helm template) in modo che le configurazioni di deploy siano immutabili.
• GitOps: Memorizza lo stato desiderato in Git. Usa Cloud Deploy o Config Sync per riconciliare i cluster con lo stato in Git. Le Pull Request (PR) diventano la superficie di controllo delle modifiche, con audit trail e controlli di policy. Evita modifiche con kubectl exec che non sono tracciate in Git.

Sicurezza dei Rilasci, Configurazione e Governance

Feature flag e configurazione a runtime

• I feature flag disaccoppiano il deploy dal rilascio; permettono di distribuire codice dormiente e di attivarlo per coorte, percentuale o regione. Memorizzare le definizioni dei flag in un sistema a bassa latenza e ad alta disponibilità (HA) (Firestore, Memorystore) e metterle in cache con TTL brevi. Registrare le valutazioni per la tracciabilità.
• Rollout graduale: Combinare la suddivisione del traffico (Cloud Run) o i sottoinsiemi canary (GKE) con i flag per minimizzare il blast radius. Utilizzare metriche sullo stato di salute e trigger di rollback automatico basati su SLO.
• Rollback sicuro: Preferire disattivazioni rapide tramite feature flag. Per un rollback del binario, promuovere l’ultima release funzionante (known-good) o riapplicare il digest del manifest precedente.

Variabili d’ambiente, precedenza, secret

• La precedenza segue comunemente questo ordine: flag a runtime > variabili d’ambiente > file di configurazione > valori predefiniti nel codice. Documentare e standardizzare questo comportamento tra i vari servizi.
• Iniettare la configurazione con ConfigMap e variabili d’ambiente; usare Secret Manager o Kubernetes Secrets per i valori sensibili. Effettuare la rotazione regolarmente ed evitare di includere i secret direttamente nelle immagini.
• Esempi di iniezione di secret:
  • Variabile d’ambiente in Cloud Run: gcloud run services update api –update-secrets=DB_PASSWORD=projects/PROJECT/secrets/db_password:latest
  • CSI di Secret Manager in GKE: apiVersion: v1 kind: Pod metadata: name: app spec: volumes:
    • name: sm csi: driver: secrets-store.csi.k8s.io readOnly: true volumeAttributes: secretProviderClass: gsm-secrets containers:
    • name: app volumeMounts:
      • name: sm mountPath: /secrets

Quality gate nella CI/CD

• Gli unit test vengono eseguiti a ogni commit; un feedback rapido è fondamentale.
• I test di integrazione vengono eseguiti su ambienti effimeri o sandbox con dati pre-caricati.
• Controlli di sicurezza: SAST, scansione delle dipendenze, scansione delle vulnerabilità dei container, controlli delle policy IaC (Conftest, Policy Controller). Bloccare i merge o le promozioni in caso di rilievi critici.
• Controlli di deployment: Le azioni di predeploy e postdeploy di Cloud Deploy validano la prontezza, la sicurezza delle migrazioni del database e gli smoke test.

Branching, revisione del codice, versionamento, tracciabilità

• Preferire il trunk-based development con feature branch di breve durata e revisioni obbligatorie delle PR. Imporre controlli obbligatori e una cronologia lineare per garantire l’auditabilità.
• Versionamento: Tag di versione semantica per i rilasci; digest delle immagini e SHA dei commit per l’immutabilità. Evitare tag mobili come latest nei deployment di produzione.
• Tracciabilità: Annotare build e rilasci con ID di commit, PR e ticket. Emettere eventi di deployment su Logging; associare etichette alle risorse per costi e proprietà.

Drift dell’infrastruttura, policy, audit, controllo delle modifiche

• Rilevamento del drift: terraform plan -detailed-exitcode schedulato; generare alert su codici di uscita diversi da zero. Per i cluster, Config Sync assicura la convergenza finale allo stato definito in Git.
• Applicazione delle policy: Usare Organization Policy per i guardrail (ad esempio, limitare gli IP esterni), Policy Controller per i vincoli KRM e Binary Authorization per le policy sulle immagini.
• Log di audit: Abilitare i log di Admin Activity e Data Access; instradarli verso progetti centralizzati con sink e retention in linea con la compliance. Cloud Asset Inventory fornisce la cronologia delle modifiche e l’analisi degli accessi.
• Controllo delle modifiche: Approvazioni manuali per le promozioni in produzione, con giustificazioni catturate come annotazioni. Le finestre di blocco (freeze window) possono essere codificate come controlli di policy nella CI/CD. Assicurarsi che i percorsi di rollback di emergenza siano documentati e testati.

Scenario Pratico

Acme Retail deve deployare un nuovo order-service su GKE negli ambienti di dev e prod con rollout canary sicuri, applicazione rigorosa delle policy e completa tracciabilità dei rilasci. Il team deve standardizzare l’infrastruttura gestita con Terraform, la configurazione dichiarativa di Kubernetes con Kustomize e una CI/CD auditabile usando Cloud Build e Cloud Deploy.

Approccio:

1. Creare repository per gli artefatti e identità

• Creare i repository regionali order-docker-dev e order-docker-prod in Artifact Registry. Concedere al service account di Cloud Build nel progetto dell’applicazione il ruolo roles/artifactregistry.writer e ai nodi di runtime di GKE il ruolo roles/artifactregistry.reader per il repository appropriato.
• Logica: I repository separati riducono il blast radius e semplificano le policy del ciclo di vita. L’uso di IAM esplicito evita i privilegi eccessivi predefiniti.

2. Definire l’infrastruttura con Terraform con separazione degli ambienti

• Creare le directory terraform/envs/dev e terraform/envs/prod. Ogni configurazione include un backend GCS con bucket di stato separati, un modulo per il cluster GKE e i binding IAM per il service account di Cloud Deploy. Eseguire terraform init, plan -out=plan.bin e apply plan.bin in un job di CI controllato (gated) per ogni ambiente.
• Logica: Stato e progetti separati per ambiente prevengono impatti accidentali tra ambienti; i file di plan supportano la revisione e un controllo delle modifiche auditabile.

3. Creare la base dichiarativa di Kubernetes e gli overlay con Kustomize

• Posizionare i manifest di Kubernetes in k8s/base per Deployment, Service e HPA con le immagini fissate (pinned) tramite digest. Creare k8s/overlays/dev e k8s/overlays/prod con patch per repliche, richieste di risorse e configurazioni. Usare una classe CSI di Secret Manager per le credenziali del database.
• Logica: Una singola fonte di verità (single source of truth) con gli overlay elimina il drift e mantiene le configurazioni DRY (Don’t Repeat Yourself), abilitando al contempo differenze sicure e specifiche per ogni ambiente.

4. Implementare Cloud Build con fasi distinte di test e pacchettizzazione

• Il file cloudbuild.yaml include i seguenti passaggi: linting e unit test, test di integrazione su un namespace di dev monouso, build e push del container nel repository dell’ambiente, scansione SBOM e delle vulnerabilità, e generazione della provenienza. Il trigger si attiva sulle PR verso main per i test e sui merge per la pacchettizzazione. Le build vengono eseguite con un service account cb-deployer che segue il principio del privilegio minimo.
• Logica: I fallimenti precoci costano poco; la separazione delle responsabilità migliora l’osservabilità e consente tentativi di riesecuzione mirati. Il principio del privilegio minimo riduce i rischi nella supply chain.

5. Configurare la delivery pipeline di Cloud Deploy con approvazione manuale per prod e strategia canary

• Definire una DeliveryPipeline con target di dev e prod. La fase di prod richiede un’approvazione e utilizza una strategia canary (ad esempio, 10% e poi 100%). Usare hook di predeploy per controlli di compatibilità dello schema e smoke test; il postdeploy verifica gli SLO.
• Logica: Il delivery progressivo limita il blast radius e introduce quality gate automatizzati, mentre l’approvazione manuale impone un controllo umano per l’ambiente di produzione.

6. Collegare GitOps e l’applicazione delle policy

• Proteggere il branch main con revisioni obbligatorie e il superamento dei controlli. Usare i vincoli di Policy Controller per bloccare i pod privilegiati e non consentire tag mutabili. Abilitare Binary Authorization per richiedere la provenienza da Cloud Build e attestazioni di “assenza di CVE critiche” prima dell’ammissione (admission).
• Logica: La policy-as-code impedisce che configurazioni rischiose raggiungano il cluster e fornisce un’applicazione coerente.

7. Gestire la configurazione e i feature flag per un rilascio sicuro

• Memorizzare la configurazione a runtime non sensibile nei ConfigMap; i secret sono forniti tramite il CSI di Secret Manager. Introdurre un feature flag order_new_flow letto da Firestore con un rollout iniziale dell'1% in prod; i flag sono messi in cache con un TTL breve e le loro valutazioni vengono registrate.
• Logica: I flag disaccoppiano il rilascio dal deploy, consentendo una disattivazione istantanea in caso di problemi, senza dover effettuare il rollback del binario.

8. Garantire osservabilità, rilevamento del drift e tracciabilità

• Annotare build e rilasci con SHA del commit, numero della PR e ticket di modifica. Instradare gli eventi di Cloud Deploy e i log di audit di GKE a un progetto Logging centrale. Job notturni di terraform plan avvisano in caso di drift; Config Sync monitora la divergenza KRM, riconciliandola con Git.
• Logica: Provenienza completa e audit trail accelerano la risposta agli incidenti; il rilevamento continuo del drift mantiene l’integrità dell’infrastruttura.

9. Gestire rollback e controllo delle modifiche

• In caso di incidenti, disabilitare prima order_new_flow tramite il flag. Se necessario, promuovere la release precedente andata a buon fine in Cloud Deploy verso dev e prod. Tutte le promozioni in prod richiedono un riferimento a un ticket nelle annotazioni del rilascio e l’approvazione dell’SRE di turno.
• Logica: I flag forniscono una mitigazione istantanea; i rilasci immutabili consentono un rollback prevedibile. Le approvazioni e le annotazioni soddisfano la governance operativa e i requisiti di compliance.

← Identità · Tutti i domini · Osservabilità →

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

Sfoglia Google →