Google PDE: Governance, Sicurezza, Affidabilità e Operazioni sui Costi dei Dati — Guida allo studio

By Laurynas Brazys · 21 August 2026 · #google #PDE #certification #exam-prep #study-guide

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

Panoramica

Questa sezione riassume i design pattern e le pratiche operative per la data governance, la sicurezza, l’affidabilità e le operazioni di costo su Google Cloud. Si concentra su BigQuery, Cloud Storage, Dataflow, Dataplex e i servizi di supporto. L’enfasi è posta sul principio del privilegio minimo (least privilege), sulla gestione delle chiavi di crittografia, sui metadati e la classificazione, sull’accesso basato su policy, sulle prove di conformità, sull’osservabilità con SLO attuabili e sul controllo dei costi. Vengono inclusi i compromessi (trade-off), le modalità di guasto (failure modes) e le configurazioni pratiche per abilitare piattaforme dati sicure, verificabili ed efficienti.

Identità, Accesso e Governance

IAM, service account, impersonation, workload identity, privilegio minimo (least privilege)
- Confini di identità (Identity boundaries)
  - Utenti e gruppi tramite Cloud Identity o Google Workspace
  - Service account per i carichi di lavoro (workload); assegnare ruoli con ambito ristretto alla risorsa più bassa possibile (es. a livello di dataset invece che di progetto)
- Privilegio minimo (Least privilege)
  - Preferire i ruoli predefiniti ai ruoli primitivi; per BigQuery, usare ruoli come bigquery.dataViewer sui dataset invece del ruolo di viewer a livello di progetto
  - Concedere le autorizzazioni ai gruppi; gestire l’appartenenza in un IdP, non tramite IAM per singolo utente
  - Separazione dei compiti (Split duties): ruoli separati per la gestione delle chiavi, l’accesso ai dati e l’amministrazione
- Impersonation e Workload Identity Federation
  - Utilizzare la Service Account Impersonation (ruolo roles/iam.serviceAccountTokenCreator) in modo che la CI/CD o l’automazione non memorizzino mai chiavi a lunga durata
  - Utilizzare la Workload Identity Federation con OIDC/SAML per consentire a identità esterne di ottenere token a breve durata senza file di chiavi del service account
- Modalità di guasto e mitigazioni
  - Un numero eccessivo di ruoli a livello di progetto porta a movimenti laterali (lateral movement); effettuare audit con Cloud Asset Inventory
  - Perdita di chiavi private del service account: non consentire la creazione di chiavi; usare i vincoli delle policy dell’organizzazione per bloccare il download delle chiavi; ruotarle se vengono trovate
Governance con Dataplex, Data Catalog, metadati di business, lineage
- Dataplex fornisce lake, zone e asset per unificare la governance su BigQuery e Cloud Storage con policy centralizzate
- Data Catalog contiene un glossario di business, modelli di tag (tag template) e metadati tecnici; allegare metadati di business (proprietario, classe PII, RTO/RPO) tramite tag
- Il lineage cattura le relazioni upstream/downstream; utilizzare le integrazioni di lineage di Dataplex con Dataflow, Dataproc e BigQuery per tracciare l’impatto e l’ambito di conformità
- Compromessi (Trade-off)
  - La governance centralizzata aggiunge un overhead iniziale ma riduce il rischio a lungo termine e accelera gli audit
Policy tag, classificazione, accesso a livello di riga (row-level access), mascheramento di colonna (column masking)
- Classificazione
  - Definire una tassonomia (es. public, internal, confidential, restricted) nei policy tag di Data Catalog
  - Associare i policy tag alle colonne di BigQuery; collegare IAM ai tag in modo che l’accesso segua la classificazione attraverso le tabelle
- Mascheramento di colonna (Column masking)
  - Utilizzare le policy di data masking di BigQuery per eseguire l’hashing o annullare (nullify) le colonne sensibili per i lettori non privilegiati
  - Esempio:

undefined

Accesso a livello di riga (Row-level access)
- Utilizzare le policy di accesso a livello di riga (row access policies) per filtrare i record in base ad attributi come tenant_id o region
- Esempio:

undefined

Modalità di guasto
- La mancata concessione delle autorizzazioni IAM per i policy tag ai service account utilizzati dalle pipeline causa errori nelle query; includere i ruoli di viewer/accessor dei policy tag per i service agent secondo necessità
- Le policy a livello di riga possono degradare le prestazioni se i predicati per utente sono numerosi e molto selettivi; preferire un approccio a grana grossa (coarse-grained) con un dataset per tenant dove l’isolamento è rigoroso
Individuazione e de-identificazione di dati sensibili
- Utilizzare Sensitive Data Protection per scansionare continuamente Cloud Storage e BigQuery; creare configurazioni di individuazione (discovery config) per ogni lake/zone con dei modelli (template)
- Utilizzare trasformazioni di de-identificazione: tokenizzazione, crittografia deterministica per la joinability o mascheramento
- Memorizzare le chiavi di trasformazione in Cloud KMS; mantenere le chiavi di re-identificazione separate con doppio controllo (dual control)
- Compromessi (Trade-off)
  - La crittografia deterministica abilita le join ma può rivelare informazioni sulla frequenza; aggiungere crittografia che preserva il formato (format-preserving encryption) o bucketing secondo necessità
  - Il campionamento (sampling) riduce il costo delle scansioni di individuazione ma può mancare PII a bassa prevalenza

Operazioni di Sicurezza e Conformità

Crittografia, Cloud KMS, CMEK e gestione dei segreti
- La crittografia at-rest e in-transit è predefinita; abilitare CMEK dove è richiesto il controllo normativo delle chiavi (BigQuery, GCS, Pub/Sub, Dataflow)
- Gestione delle chiavi
  - Posizionare le chiavi nella stessa region dei dati; concedere al service agent (es. BigQuery Service Agent) il ruolo roles/cloudkms.cryptoKeyEncrypterDecrypter
  - Ruotare le chiavi regolarmente; monitorare le chiavi disabilitate o pianificate per la distruzione
- Modalità di fallimento
  - La disabilitazione di una chiave CMEK o la revoca del service agent interrompe caricamenti, query ed esportazioni; creare alert sulle modifiche di stato della chiave
  - L’uso di chiavi cross-region non è consentito; allineare le location per evitare errori nella creazione dei job
- Segreti
  - Usare Secret Manager per credenziali di database, token API; concedere l’accesso tramite IAM e fare audit con i log di Secret Manager
  - Non incorporare mai segreti nel codice, nei container o nei notebook; montare i segreti tramite accesso a runtime; preferire l’autenticazione IAM per database dove supportata
Log di audit, revisione degli accessi, prove di conformità, conservazione
- Abilitare i log di Data Access a livello di organizzazione per BigQuery, GCS, Pub/Sub; esportarli in un progetto di logging dedicato, di sola scrittura, con CMEK
- Creare sink di log aggregati verso BigQuery (per analisi) e Cloud Storage (per archivio immutabile a lungo termine con blocco di conservazione del bucket)
- Usare Cloud Asset Inventory e Policy Analyzer per la revisione periodica degli accessi e il rilevamento di deviazioni (drift detection)
- Conservazione
  - Impostare la conservazione dei log in base ai requisiti di conformità; usare il versioning degli oggetti e le policy di conservazione su GCS
  - In BigQuery, impostare la scadenza predefinita delle tabelle e affidarsi a snapshot di tabella/time travel per rollback a breve termine; archiviare i dataset critici in progetti separati
- Prove (Evidence)
  - Mantenere una mappatura dei controlli con i tag di Dataplex (es. “SOX-C2: Evidence nel progetto X, sink Y”), automatizzare le esportazioni ed eseguire query pianificate per produrre attestazioni

Affidabilità, Osservabilità, Qualità e Gestione dei Costi

Dimensioni della qualità dei dati, framework di validazione e risposta agli incidenti
- Dimensioni: accuratezza, completezza, coerenza, tempestività, validità, unicità, integrità
- Implementare validazioni durante l’ingestion e la trasformazione
  - Set di regole di Dataplex Data Quality su tabelle BigQuery e asset GCS
  - Great Expectations o Deequ in Dataflow/Dataproc per controlli di schema e contenuto
- Instradare i fallimenti verso tabelle o bucket dead-letter con un contesto di errore dettagliato; evitare la perdita di dati mettendo in quarantena i record non validi
- Risposta agli incidenti
  - Dichiarare livelli di gravità, proprietari, canali di comunicazione, piani di rollback e matrici RACI
  - Automatizzare i runbook per eseguire il backfill delle finestre temporali e rielaborare i messaggi dead-letter; creare snapshot delle tabelle interessate prima della remediation
Cloud Monitoring, logging, alerting, error budget e SLO
- Esporre metriche: backlog di Dataflow, utilizzo degli slot di BigQuery, latenza delle query, latenza/errori di GCS, messaggi non confermati (unacked) di Pub/Sub
- SLO
  - Esempio: “99,9% degli eventi di streaming disponibili in BigQuery entro 5 minuti su un periodo di 30 giorni”
  - Tracciare i tassi di consumo (burn rate) dell’error budget e inviare un “page” per consumi rapidi; aprire un ticket per consumi lenti
- Metriche e alert basati sui log
  - Creare metriche basate sui log per fallimenti dei job di BigQuery, risultati di DLP, errori delle chiavi KMS
  - Utilizzare filtri di log avanzati per generare alert su aggiunte a tabelle specifiche o anomalie di accesso
Allocazione dei costi, budget, controlli sulle query, ciclo di vita dello storage, pianificazione della capacità
- Allocazione e budget
  - Utilizzare etichette (label) e tag su tutti i job, dataset, bucket e prenotazioni; esportare i dati di fatturazione su BigQuery e creare budget con notifiche Pub/Sub
- Controlli dei costi di BigQuery
  - Utilizzare partizionamento e clustering per ridurre i byte scansionati
  - Impostare maximumBytesBilled sui job di query; esempio di configurazione client/job:

undefined

- Prenotare slot con BigQuery Reservations per carichi di lavoro prevedibili; separare i carichi interattivi da quelli batch tramite assegnazioni (assignment)

Ciclo di vita dello storage
- GCS: regole di lifecycle per passare a classi di storage più fredde o eliminare dopo N giorni; abilitare il versioning degli oggetti dove è necessario il rollback
- Esempio (condensato): Eliminare le versioni non correnti dopo 30 giorni; impostare una policy di conservazione (retention) del bucket a 365 giorni per le zone di conformità
- BigQuery: scadenza predefinita delle tabelle per i dataset transitori; creare snapshot prima di modifiche distruttive
Pianificazione della capacità
- Dataflow: impostare il numero massimo di worker e l’autoscaling; dimensionare correttamente i tipi di macchina; partizionare (shard) gli input per evitare hot key
- Pub/Sub: convalidare le quote di pubblicazione/consumo e la conservazione dei messaggi
- Rete: tenere conto del traffico in uscita (egress), dello spostamento tra regioni e dell’accesso privato ai servizi per i database
Disaster recovery, backup, resilienza multi-regionale e runbook
- Classificare i servizi per RTO/RPO; scegliere di conseguenza i pattern cold/warm/hot
- Backup
  - BigQuery: snapshot regolari delle tabelle; esportare su GCS per la conservazione off-platform se necessario
  - GCS: bucket dual-region o multi-region per la durabilità; abilitare il bucket lock per la conformità WORM
  - Database: backup gestiti in Cloud SQL e Bigtable; testare i ripristini
- Multi-regione
  - Mantenere le risorse di calcolo (compute) e storage nella stessa multi-regione per minimizzare l’egress e la latenza; evitare dipendenze intercontinentali se non richieste
- Runbook
  - Documentare le procedure di failover, recupero delle chiavi, gestione degli incidenti KMS, reidratazione da export e riassegnazione delle prenotazioni di BigQuery
  - Testare il DR tramite “game day”; tracciare il tempo di ripristino (time-to-recover) e aggiornare gli SLO

Scenario Pratico

NovaRetail Analytics collabora con diversi brand per l’ingestion giornaliera di file CSV contenenti dati transazionali in una piattaforma di analisi condivisa. I file arrivano in un bucket di landing su Cloud Storage e occasionalmente includono righe malformate. La piattaforma deve applicare il principio del privilegio minimo (least privilege) in modo che ogni cliente possa accedere solo ai propri dati, rilevare campi sensibili e fornire alert immediati quando vengono aggiunte righe a una specifica tabella di audit. L’azienda necessita anche di controlli sui costi e di un piano di ripristino.

Approccio:

Isolare i tenant e applicare il principio del privilegio minimo
- Creare un dataset BigQuery dedicato per ogni cliente (es. client_a_analytics). Concedere solo al gruppo del cliente i ruoli appropriati sul dataset (bigquery.dataViewer, bigquery.jobUser) e limitare l’uso dell’API di BigQuery agli utenti approvati tramite IAM e, se applicabile, VPC-SC.
- Motivazione: Un dataset per tenant limita il “blast radius” (raggio d’impatto) e semplifica la complessità delle policy a livello di riga. L’applicazione del privilegio minimo a livello di dataset impedisce di default l’accesso incrociato tra tenant.
Governare schema, classificazione e mascheramento
- Definire una tassonomia di policy tag in Data Catalog (public, internal, confidential, restricted) e modelli di tag (template) per proprietario, data steward e RTO/RPO. Associare i policy tag alle colonne sensibili (email, card_suffix) in ogni dataset del cliente. Applicare le policy di mascheramento di BigQuery per limitare la visualizzazione per i ruoli non privilegiati.
- Esempio:

undefined

Motivazione: I tag centralizzati forniscono un controllo uniforme su tutte le tabelle; il mascheramento garantisce letture sicure di default senza duplicare i dati.

Individuare PII e applicare la de-identificazione dove necessario
- Configurare la discovery di Sensitive Data Protection per scansionare il bucket di landing e le tabelle BigQuery curate. Utilizzare un modello di ispezione (inspection template) per le PII comuni e un modello de-identificazione (de-identification template) per tokenizzare le email in modo deterministico per i casi d’uso che richiedono join.
- Motivazione: La discovery automatizzata riduce gli errori manuali; la tokenizzazione deterministica bilancia la privacy con i requisiti di join per l’analisi.
Mettere in sicurezza la pipeline con service account, impersonation e CMEK
- Utilizzare un service account di Dataflow con solo i ruoli necessari: storage.objectViewer sul bucket di landing, bigquery.dataEditor sui dataset di destinazione e accesso ai policy tag se richiesto. Utilizzare CMEK per i dataset dei clienti e concedere agli agenti di servizio (service agent) di BigQuery e Dataflow il ruolo CryptoKey Encrypter/Decrypter.
- Motivazione: Ruoli con permessi ristretti più CMEK soddisfano i requisiti di privilegio minimo e di controllo delle chiavi. L’accesso alle chiavi da parte dei service agent previene i fallimenti dei job.
Costruire un’ingestion resiliente con quarantena degli errori
- Eseguire un job batch di Dataflow che legge i CSV, valida lo schema e scrive le righe valide in tabelle partizionate di BigQuery. Instradare le righe non valide a una tabella dead-letter di BigQuery con i dettagli dell’errore (nome file, riga, motivo).
- Motivazione: Gli output secondari (side output) conservano i dati errati per l’analisi senza bloccare i dati validi; le tabelle partizionate riducono i costi di scansione e velocizzano le query.
Creare lineage e metadati di business
- Registrare il bucket di landing e i dataset come asset Dataplex in un lake. Abilitare la raccolta del lineage per il job di Dataflow e aggiungere tag alle tabelle curate con metadati di business (proprietario dei dati, sensibilità, conservazione).
- Motivazione: Una governance centralizzata abilita l’analisi di impatto, la preparazione agli audit e una stewardship standardizzata.
Monitorare, generare alert e fare audit
- Abilitare gli audit log di tipo Admin e Data Access, esportati con CMEK verso un progetto di logging centralizzato e su BigQuery per l’analisi. Aggiungere un alert basato sui log per le nuove righe aggiunte alla tabella di audit utilizzando un filtro avanzato sui job di inserimento di BigQuery; esportare tale sink su Pub/Sub affinché lo strumento di monitoraggio possa consumarlo.
- Motivazione: I log sono prove a prova di manomissione; gli alert mirati notificano solo sulla tabella richiesta, riducendo il rumore.
Applicare controlli sui costi e “guardrail” per le query
- Richiedere che i job di query impostino maximumBytesBilled e sfruttare il clustering su colonne ad alta cardinalità (es. order_id). Applicare budget e impostare etichette (label) (cliente, ambiente) su job e dataset. Utilizzare BigQuery Reservations per separare l’analisi interattiva dai caricamenti pianificati.
- Motivazione: I “guardrail” prev