Google PCA: DevOps, ingegneria di delivery e infrastruttura come codice — Guida allo studio

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

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

Panoramica

DevOps, Delivery Engineering e Infrastructure as Code (IaC) su Google Cloud si concentrano sulla delivery continua di modifiche affidabili con una solida tracciabilità, automazione e sicurezza. Le architetture dovrebbero essere ottimizzate per cicli di feedback brevi, deployment ripetibili, infrastruttura immutabile e guardrail che scalano con l’organizzazione. Su Google Cloud, questo approccio combina tipicamente le best practice per il controllo di versione; la CI con Cloud Build; la gestione degli artefatti con Artifact Registry; la CD con Cloud Deploy; Kubernetes con GKE utilizzando manifest, Helm o Kustomize; GitOps per il controllo del configuration drift; e l’IaC con Terraform o i modelli di deployment di Google Cloud. L’eccellenza operativa richiede una delivery progressiva (blue-green, canary, traffic splitting e feature flag), controlli sulla supply-chain del software (scansione, provenienza, firma), gate di test e deployment, e una governance che bilanci velocità, sicurezza, auditability e ownership.

CI/CD, controllo di versione e orchestrazione dei rilasci

Principi di CI/CD
- Mantenere il branch master/main sempre rilasciabile; praticare lo sviluppo trunk-based con feature branch di breve durata.
- Automatizzare build, test, scansione e packaging a ogni modifica; richiedere la code review con approvazioni obbligatorie e status check.
- Mantenere la tracciabilità completa dal commit → build → digest dell’artefatto → rilascio in ambiente; integrare gli SHA dei commit e i metadati del build nelle immagini e nelle annotazioni del deployment.
- Modalità di fallimento: branch di lunga durata, passaggi manuali, test instabili (flaky), build non riproducibili e la mancanza di immutabilità degli artefatti portano a sorprese tardive e rollback.
Controllo di versione, branching, pull request, code review e tracciabilità
- Utilizzare branch protetti, review obbligatorie e firma dei commit. Taggare i rilasci e mantenere un changelog generato dai merge commit.
- Applicare CODEOWNERS e metadati di service ownership per rafforzare la responsabilità di dominio (domain stewardship).
- Collegare i commit a issue e deployment; esportare i log e i metadati di CI/CD su Cloud Logging e BigQuery per audit e metriche DORA.
Cloud Build
- Trigger: si attivano su eventi Git (branch, tag, PR), invocazioni manuali o Pub/Sub. Parametrizzare con sostituzioni per versione, ambiente e feature flag per mantenere le pipeline DRY.
- Step di build: eseguire builder ufficiali o container definiti dall’utente; usare step paralleli quando indipendenti per ridurre la latenza; usare le cache per le dipendenze dei linguaggi per accelerare i build.
- Artefatti: effettuare il push delle immagini su Artifact Registry con tag e digest immutabili; archiviare SBOM e log di build; pubblicare i report dei test come artefatti di build.
- Identità di build sicure: eseguire Cloud Build con un service account dedicato con il principio del least privilege e Workload Identity Federation per-repository dove possibile. Per reti private o per evitare l’egress, usare i Private Pool. Limitare le chiavi dei service account; preferire token di breve durata.
- Esempio (abbreviato):
  - cloudbuild.yaml:
    - steps:
      - name: gcr.io/cloud-builders/docker args: [build, -t, $REGION-docker.pkg.dev/$PROJECT/app/web:$COMMIT_SHA, .]
      - name: gcr.io/cloud-builders/docker args: [push, $REGION-docker.pkg.dev/$PROJECT/app/web:$COMMIT_SHA]
    - substitutions:
      - _ENV=staging
Cloud Deploy
- Release e target: modellare una delivery pipeline con promozioni tra i target (es. dev → staging → prod). Una release acquisisce un riferimento a un artefatto immutabile e la configurazione del deployment.
- Approvazioni e promozione: richiedere approvazioni manuali o automatiche con controllo basato sui ruoli. La promozione dovrebbe essere un’azione rapida e a basso rischio, poiché l’artefatto e i manifest non cambiano.
- Rollout canary e rollback: definire strategie per l’esposizione progressiva, health check e rollback automatico in caso di errori sugli SLO. Registrare ogni promozione, approvatore e risultato della verifica per l’audit.
- Modalità di fallimento: artefatti mutabili tra ambienti, kubectl manuale in produzione o la mancata verifica pre-deployment causano drift e outage non tracciabili.

Infrastruttura come Codice e gestione della configurazione

Terraform
- Moduli: catturano pattern riutilizzabili (es. VPC, cluster GKE, service account, binding IAM). Versionare e fissare (“pin”) le release dei moduli; pubblicare registri di moduli interni.
- Stato remoto: archiviare in Cloud Storage con versioning, policy di conservazione e CMEK; abilitare il locking; limitare l’accesso tramite IAM e l’accesso uniforme a livello di bucket; eseguire il backup dello stato.
- Piani e controlli delle policy: eseguire

undefined

in CI; richiedere la revisione umana del piano; applicare la policy as code (OPA/Conftest, Sentinel o Policy Controller) per bloccare le violazioni (es. bucket pubblici, binding IAM ampi).

Promozione tra ambienti: utilizzare workspace separati o stati/backend separati per ambiente; promuovere le modifiche tramite le stesse versioni di moduli e variabili; non modificare mai manualmente le risorse cloud. Gli input sensibili dovrebbero provenire da Secret Manager o dall’automazione, mai codificati direttamente (“hardcoded”).
Modalità di fallimento: fuga di segreti nello stato, modifiche concorrenti senza locking, “drift” (deviazione) da modifiche fuori banda e dipendenze implicite che rompono le operazioni di destroy/replace.
Template di deployment di Google Cloud e configurazione dichiarativa
- Utilizzare strumenti dichiarativi (Terraform, Google Cloud Deployment Manager o Kubernetes Configuration as Code) per definire lo stato desiderato anziché script di passaggi imperativi.
- Preferire l’infrastruttura immutabile: sostituire i template di istanza ed eseguire il roll-out dei MIG; distribuire nuovi Deployment GKE anziché applicare patch ai pod esistenti. I pattern immutabili semplificano il rollback e l’audit.
- Deployment Manager supporta template Jinja/Python per le risorse Google Cloud ma è limitato a Google Cloud; Terraform offre un ecosistema più ampio e strumenti di policy. Scegliere in base alla standardizzazione aziendale e alle competenze.
Manifest di Kubernetes, Helm, Kustomize e GitOps
- Manifest: mantenere template di base con “overlay” per ambiente; parametrizzare solo ciò che dovrebbe variare per ambiente (es. repliche, limiti, endpoint).
- Helm: impacchettare, creare template e versionare i servizi con i chart; bloccare le dipendenze; fissare (“pin”) i digest delle immagini. Modalità di fallimento: l’eccesso di templating (“over-templating”) oscura l’intento e complica la revisione.
- Kustomize: gestire gli “overlay” (base + patch per ambiente); più semplice di Helm quando è sufficiente Kubernetes puro.
- GitOps: un controller (es. Config Sync, Argo CD, Flux) riconcilia continuamente i cluster con lo stato desiderato in Git; ogni modifica è una PR con revisione e una traccia di audit. Rilevare e correggere automaticamente il “drift”.

Delivery progressivo, supply chain, test e verifica

Feature flag e gestione del traffico
- I feature flag disaccoppiano il deploy dal rilascio; utilizzarli per l’esposizione graduale, test A/B e “kill switch” di emergenza. Assicurarsi che gli stati dei flag siano versionati e verificabili; ritirare i flag obsoleti.
- Suddivisione del traffico: su Cloud Run utilizzare il routing basato su percentuale tra le revisioni; su GKE utilizzare service mesh o controller di ingress che supportano il routing ponderato. Per le API sotto un unico nome host/TLS, mantenere servizi di backend separati per percorso dietro l’HTTP(S) Load Balancer; il routing basato sul percorso (“path routing”) isola nettamente le versioni vecchie e nuove preservando un singolo URL e certificato.
- Blue-green: eseguire due stack pronti per la produzione; commutare il traffico in modo atomico tramite load balancer, selettori di servizio o traffico tra revisioni di Cloud Run. Consente il rollback istantaneo ma raddoppia i costi a regime.
- Canary e rollout progressivo: aumentare gradualmente il traffico da una piccola porzione misurando i “golden signal” e i KPI di business; automatizzare il rollback in caso di regressione.
Controlli della supply chain del software
- Scansione delle immagini: abilitare la scansione delle vulnerabilità di Artifact Analysis; far fallire le build in caso di vulnerabilità critiche o immagini di base note per essere problematiche; mantenere una cadenza di patching.
- Provenienza e firma: generare la provenienza della build conforme a SLSA in Cloud Build; firmare gli artefatti con Cosign; applicare le policy di Binary Authorization che richiedono attestazioni prima del deployment.
- Gestione delle dipendenze: fissare (“pin”) versioni e digest, mantenere SBOM, includere (“vendor”) le dipendenze critiche e verificare i checksum. Le modalità di fallimento includono il “drift” delle dipendenze transitive e registri compromessi.
Piramide dei test, gate di deployment e verifica post-deployment
- Piramide: dare enfasi a unit test veloci; aggiungere test di integrazione e di contratto; eseguire test end-to-end mirati. Mantenere i dati di test realistici e de-identificati (usare Cloud DLP per rimuovere le PII).
- Gate di deployment: applicare soglie per il tasso di superamento dei test, lo stato delle vulnerabilità, la conformità alle policy e la revisione del codice prima della promozione; richiedere l’approvazione manuale per la produzione quando il rischio è elevato.
- Verifica post-deployment: eseguire smoke test, controlli sintetici e analisi canary utilizzando Cloud Monitoring, Error Reporting e Trace. Se i KPI si degradano, attivare un rollback automatico e aprire un incidente con il contesto acquisito.
- Diagnostica operativa: distribuire l’agente Cloud Logging dove necessario e strumentare i servizi per Trace e Debugger. Mantenere runbook per la remediation sicura (es. ridimensionare un disco persistente online ed eseguire

undefined

con un downtime minimo).

Governance, sicurezza, auditability e proprietà

Velocità con sicurezza
- Lo sviluppo basato su trunk (trunk-based development) con PR di breve durata e revisione obbligatoria mantiene il flusso senza sacrificare la qualità.
- Le pipeline self-service con template per stack comuni (GKE + Helm, Cloud Run, Dataflow) accelerano i team e riducono il rischio di soluzioni personalizzate.
Accesso, identità e approvazioni
- Utilizzare service account dedicati per ogni fase della pipeline con il principio del privilegio minimo (least privilege) e Workload Identity Federation; evitare chiavi statiche.
- Separazione dei compiti: gli sviluppatori creano; i release manager approvano la promozione in produzione; gli operatori di runtime gestiscono la configurazione di runtime e i budget.
Auditability e conformità
- Esportare i log di Cloud Build, Cloud Deploy e Cloud Audit Logs in BigQuery. Utilizzare viste di set di dati e IAM per condividere dati di audit con ambito limitato con gli auditor. Conservare le metriche a lungo termine esportandole su Cloud Storage o BigQuery secondo le policy.
- Registrare i digest degli artefatti nei metadati di deployment. Mantenere un SBOM e una provenance end-to-end per ogni rilascio.
Proprietà e SLO
- Ogni servizio ha un proprietario, una turnazione di reperibilità (on-call), SLO e error budget che controllano i rilasci. Associare le policy di deployment alla conformità degli SLO per evitare di rilasciare modifiche quando il budget è esaurito.
Compromessi e insidie comuni
- Costo del blue-green vs. velocità di rollback; affidabilità del canary vs. tempo per il rilascio completo.
- Coerenza di GitOps vs. flessibilità operativa; consentire procedure di emergenza (break-glass) controllate con logging e PR di follow-up.
- Un eccesso di template riduce la leggibilità; mantenere la configurazione esplicita e minimale.
- Una policy centralizzata previene errori di configurazione ma deve essere implementata in modo iterativo per evitare di bloccare i team inutilmente.

Scenario di un Problema Pratico

Azienda: Borealis Fintech

Sfida: Borealis sta lanciando una nuova API per i pagamenti su GKE, mantenendo la v1 e la v2 sotto lo stesso hostname e TLS. Hanno bisogno di tracciabilità end-to-end, delivery progressiva con canary e feature flag, controlli rigorosi sulla supply-chain e promozioni auditate tra gli ambienti di dev, staging e prod. Vogliono anche utilizzare GitOps per la configurazione del cluster e Terraform per le risorse della piattaforma.

Approccio:

Impostare il controllo di versione e il branching
- Creare un mono-repo con directory per i servizi e un repo separato per l’infrastruttura. Imporre un branch ‘main’ protetto, revisioni obbligatorie delle PR, CODEOWNERS e commit firmati. Motivazione: flusso basato su trunk con proprietà chiara e cronologia pronta per l’audit.
Creare gli artefatti con Cloud Build e Artifact Registry
- Definire un file cloudbuild.yaml per creare e caricare immagini taggate con $COMMIT_SHA e annotate con SBOM e provenance. Utilizzare un service account dedicato per Cloud Build con privilegi minimi e un Private Pool. Motivazione: build riproducibili e isolate con digest tracciabili.
- Esempio:
  - gcloud artifacts repositories create app –repository-format=docker –location=us
Implementare controlli sulla supply-chain del software
- Abilitare la scansione delle vulnerabilità in Artifact Registry. Generare la provenance e firmare le immagini con Cosign nelle fasi post-build di Cloud Build. Configurare Binary Authorization per richiedere firme e il superamento della scansione prima del deploy su GKE. Motivazione: bloccare artefatti non attendibili o vulnerabili al momento dell’applicazione della policy.
Modellare la delivery con Cloud Deploy
- Definire una pipeline di delivery con target dev, staging, prod e una strategia canary per prod. Richiedere l’approvazione manuale per prod con approvatori basati sui ruoli. Motivazione: promozione immutabile e approvazioni auditabili.
- clouddeploy.yaml (estratto):
  - strategy:
    - canary:
      - canaryDeployment:
        percentages: [5, 25, 50, 100]
Instradare le API v1 e v2 sotto lo stesso hostname
- Configurare un External HTTP(S) Load Balancer con backend service separati per i percorsi /v1 e /v2, ciascuno che punta al NEG GKE corrispondente. Motivazione: isolamento pulito basato sul percorso (path), stesso certificato e DNS, capacità di deployment indipendente.
- Esempio (estratto):
  - gcloud compute url-maps add-path-matcher api-map –path-matcher-name api-pm –default-service v1-bes –path-rules="/v1/=v1-bes,/v2/=v2-bes"
Gestire l’infrastruttura con Terraform
- Creare moduli per VPC, GKE, Artifact Registry, service account e IAM. Archiviare lo stato remoto in un bucket Cloud Storage protetto con CMEK, con versionamento e retention. Applicare policy OPA nella CI per prevenire modifiche rischiose. Motivazione: provisioning della piattaforma riutilizzabile, revisionabile e governato.
- backend “gcs” { bucket = “borealis-tf-state” prefix = “prod” }
Configurare Kubernetes con Helm/Kustomize e GitOps
- Mantenere manifest di base per l’API e overlay per ogni ambiente usando Kustomize. Usare Config Sync o Argo CD per riconciliare i cluster con lo stato di Git. Motivazione: operazioni dichiarative, auditabili e resistenti al drift.
Delivery progressiva con canary e feature flag
- Usare il canary di Cloud Deploy per prod e un SDK di feature-flag (OpenFeature) per controllare la nuova logica. Iniziare con il 5% del traffico, promuovere automaticamente in caso di SLO integri; effettuare un rollback automatico in caso di degrado e usare il flag come kill switch. Motivazione: ridurre il raggio d’impatto (blast radius) e disaccoppiare il deploy dal rilascio.
Quality gate e verifica
- Fasi della pipeline: unit test → integration test su un ambiente effimero → scansione dei container → controlli delle policy → test end-to-end in staging → canary in prod con verifica automatizzata basata su SLO (Cloud Monitoring, Error Reporting, Trace). Motivazione: feedback rapido nelle fasi iniziali, sicurezza elevata prima di prod e controlli di salute oggettivi post-deployment.
Operatività, logging e audit
- Installare gli agenti di Cloud Logging/Monitoring per le VM di supporto e abilitare i log/metriche dei workload GKE. Esportare i log di CI/CD e Audit Logs in BigQuery con viste con ambito limitato per gli auditor. Mantenere dei runbook (incluse procedure per un rollback sicuro e per lo switch di emergenza del DNS o del LB). Motivazione: osservabilità per una rapida remediation e prove pronte per la conformità.

Questo design preserva la velocità con un flusso basato su trunk e pipeline automatizzate; la sicurezza con canary, feature flag e Binary Authorization; l’auditability con artefatti immutabili, approvazioni e log centralizzati; e una chiara proprietà tramite CODEOWNERS e ambienti controllati da GitOps.

← Operazioni · Tutti i domini · Costi →

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