Google PDE: Data Governance, Beveiliging, Betrouwbaarheid en Kostenbeheer — Studiegids
Onderdeel van de Google Professional Data Engineer — Studiegids. Oefen met geverifieerde antwoorden in het Google-examencentrum, of doe getimede oefentests op ExamRoll.io.
Overzicht
Dit gedeelte vat ontwerppatronen en operationele praktijken samen voor data governance, beveiliging, betrouwbaarheid en kostenbeheer op Google Cloud. Het richt zich op BigQuery, Cloud Storage, Dataflow, Dataplex en ondersteunende services. De nadruk ligt op ’least privilege’, beheer van encryptiesleutels, metadata en classificatie, beleidsgestuurde toegang, bewijs van compliance, observeerbaarheid met bruikbare SLO’s en kostenbeheersing. Afwegingen, faalscenario’s en praktische configuraties worden behandeld om veilige, auditeerbare en efficiënte dataplatforms mogelijk te maken.
Identiteit, Toegang en Governance
IAM, service accounts, impersonation, workload identity, least privilege
- Identiteitsgrenzen
- Gebruikers en groepen via Cloud Identity of Google Workspace
- Service accounts voor workloads; wijs rollen met een beperkte scope toe op het laagst mogelijke resourceniveau (bv. dataset in plaats van project)
- Least privilege
- Geef de voorkeur aan vooraf gedefinieerde rollen boven primitieve rollen; gebruik voor BigQuery rollen zoals bigquery.dataViewer op datasets in plaats van de viewer-rol op projectniveau
- Verleen permissies aan groepen; beheer het lidmaatschap in een IdP, niet per gebruiker in IAM
- Scheiding van taken: aparte rollen voor sleutelbeheer, datatoegang en administratie
- Impersonation en Workload Identity Federation
- Gebruik Service Account Impersonation (roles/iam.serviceAccountTokenCreator) zodat CI/CD of automatisering nooit langlevende sleutels opslaat
- Gebruik Workload Identity Federation met OIDC/SAML om externe identiteiten kortlevende tokens te laten verkrijgen zonder service account-sleutelbestanden
- Faalscenario’s en mitigaties
- Buitensporige rollen op projectniveau leiden tot ’lateral movement’; auditeer met Cloud Asset Inventory
- Verloren private sleutels van service accounts: sta het aanmaken van sleutels niet toe; gebruik organisatiebeleidsbeperkingen om het downloaden van sleutels te blokkeren; roteer indien gevonden
- Identiteitsgrenzen
Dataplex governance, Data Catalog, business metadata, lineage
- Dataplex biedt ’lakes’, ‘zones’ en ‘assets’ om governance over BigQuery en Cloud Storage te verenigen met gecentraliseerd beleid
- Data Catalog bevat een business glossary, tag-templates en technische metadata; koppel business metadata (eigenaar, PII-klasse, RTO/RPO) via tags
- Lineage legt upstream/downstream-relaties vast; gebruik Dataplex lineage-integraties met Dataflow, Dataproc en BigQuery om de impact en compliance-scope te traceren
- Afwegingen
- Gecentraliseerde governance voegt initiële overhead toe, maar vermindert het risico op lange termijn en versnelt audits
Policy tags, classificatie, toegang op rijniveau, kolommaskering
- Classificatie
- Definieer een taxonomie (bv. openbaar, intern, vertrouwelijk, beperkt) in Data Catalog policy tags
- Koppel policy tags aan BigQuery-kolommen; bind IAM aan tags zodat toegang de classificatie volgt over tabellen heen
- Kolommaskering
- Gebruik BigQuery data masking-beleid om gevoelige kolommen te hashen of te nullificeren voor niet-geprivilegieerde lezers
- Voorbeeld:
- ALTER TABLE fin.payments ALTER COLUMN card_number SET POLICY TAGS (‘pii.restricted’);
- Toegang op rijniveau
- Gebruik ‘row access policies’ om records te filteren op attributen zoals tenant_id of regio
- Voorbeeld:
- CREATE ROW ACCESS POLICY tenant_filter ON sales.orders GRANT TO (“group:analysts@acme.com”) FILTER USING (tenant_id = “acme”);
- Faalscenario’s
- IAM voor policy tags niet toegekend aan service accounts die door pipelines worden gebruikt, veroorzaakt queryfouten; neem waar nodig de ‘policy tag viewer/accessor’-rol op voor service agents
- Rijbeleid kan de prestaties verminderen als er veel zeer selectieve predicaten per gebruiker zijn; geef de voorkeur aan een grofmazige dataset-per-tenant-structuur waar strikte isolatie vereist is
- Classificatie
Ontdekking en de-identificatie van gevoelige data
- Gebruik Sensitive Data Protection om Cloud Storage en BigQuery continu te scannen; maak discovery-configuraties per lake/zone met templates
- Gebruik de-identificatietransformaties: tokenisatie, deterministische encryptie voor ‘joinability’, of maskering
- Sla transformatiesleutels op in Cloud KMS; houd her-identificatiesleutels gescheiden met ‘dual control’
- Afwegingen
- Deterministische encryptie maakt joins mogelijk, maar kan frequentie-informatie lekken; voeg waar nodig ‘format-preserving encryption’ of ‘bucketing’ toe
- Sampling verlaagt de kosten van discovery-scans, maar kan PII met een lage prevalentie missen
Security- en Compliance-operaties
Encryptie, Cloud KMS, CMEK en het omgaan met secrets
- Encryptie ‘at rest’ en ‘in transit’ is standaard; schakel CMEK in waar regelgeving controle over sleutels vereist (BigQuery, GCS, Pub/Sub, Dataflow)
- Sleutelbeheer
- Plaats sleutels in dezelfde regio als de data; geef de service agent (bijv. BigQuery Service Agent) de rol
roles/cloudkms.cryptoKeyEncrypterDecrypter - Roteer sleutels regelmatig; monitor op uitgeschakelde sleutels of sleutels die gepland zijn voor vernietiging
- Plaats sleutels in dezelfde regio als de data; geef de service agent (bijv. BigQuery Service Agent) de rol
- Faalscenario’s
- Het uitschakelen van een CMEK-sleutel of het intrekken van de service agent verbreekt laadprocessen, query’s en exports; alarmeer bij wijzigingen in de sleutelstatus
- Gebruik van sleutels over regio’s heen is niet toegestaan; stem locaties op elkaar af om fouten bij het aanmaken van jobs te voorkomen
- Secrets
- Gebruik Secret Manager voor database-credentials, API-tokens; verleen toegang via IAM en voer audits uit met Secret Manager-logs
- Sla nooit secrets op in code, containers of notebooks; mount secrets via runtime-toegang; geef de voorkeur aan IAM-database-authenticatie waar dit wordt ondersteund
Auditlogs, toegangsbeoordeling, compliance-bewijs en retentie
- Schakel Data Access-logs in voor de hele organisatie voor BigQuery, GCS, Pub/Sub; exporteer naar een toegewijd, ‘write-only’ loggingproject met CMEK
- Maak geaggregeerde log sinks aan naar BigQuery (analytics) en Cloud Storage (onveranderlijk langetermijnarchief met bucket retention lock)
- Gebruik Cloud Asset Inventory en Policy Analyzer voor periodieke toegangsbeoordeling en ‘drift detection’
- Retentie
- Stel logretentie in volgens de compliance-eisen; gebruik ‘object versioning’ en retentiebeleid op GCS
- Stel in BigQuery een standaard tabelverlooptijd in en vertrouw op ’table snapshots’/’time travel’ voor korte-termijn rollbacks; archiveer kritieke datasets naar afzonderlijke projecten
- Bewijs
- Onderhoud een ‘control mapping’ met Dataplex-tags (bijv. “SOX-C2: Bewijs in project X, sink Y”), automatiseer exports en voer geplande query’s uit om attestaties te genereren
Betrouwbaarheid, Observeerbaarheid, Kwaliteit en Kostenbeheer
Dimensies van datakwaliteit, validatieframeworks en incidentrespons
- Dimensies: nauwkeurigheid, volledigheid, consistentie, tijdigheid, validiteit, uniciteit, integriteit
- Implementeer validaties bij opname (ingestion) en transformatie
- Dataplex Data Quality-regelsets op BigQuery-tabellen en GCS-assets
- Great Expectations of Deequ in Dataflow/Dataproc voor schema- en inhoudscontroles
- Leid fouten om naar dead-letter-tabellen of -buckets met uitgebreide foutcontext; voorkom dataverlies door foute records in quarantaine te plaatsen
- Incidentrespons
- Definieer ernstniveaus (severities), eigenaren, communicatiekanalen, rollback-plannen en RACI
- Automatiseer runbooks om periodes te backfillen en dead letters opnieuw te verwerken; maak een snapshot van de getroffen tabellen vóór herstel
Cloud Monitoring, logging, alarmering, error budgets en SLO’s
- Maak metrics beschikbaar: Dataflow-backlog, BigQuery-slotgebruik, query-latency, GCS-latency/fouten, Pub/Sub unacked-berichten
- SLO’s
- Voorbeeld: “99,9% van de streaming-events is binnen 5 minuten beschikbaar in BigQuery over een periode van 30 dagen”
- Volg de burn rates van het error budget en page bij snelle verbranding; maak een ticket aan bij langzame verbranding
- Op logs gebaseerde metrics en alerts
- Maak op logs gebaseerde metrics voor mislukte BigQuery-jobs, DLP-bevindingen, KMS-sleutelfouten
- Gebruik geavanceerde logfilters om te alarmeren bij toevoegingen aan specifieke tabellen of toegangsafwijkingen
Kostentoewijzing, budgetten, query-controles, storage lifecycle, capaciteitsplanning
- Toewijzing en budgetten
- Gebruik labels en tags op alle jobs, datasets, buckets en reservations; exporteer factureringsdata naar BigQuery en maak budgetten met Pub/Sub-notificaties
- BigQuery-kostenbeheersing
- Gebruik partitionering en clustering om het aantal gescande bytes te verminderen
Stel maximumBytesBilled in op query-jobs; voorbeeld client/job-configuratie:
- Toewijzing en budgetten
undefined
- Reserveer slots met BigQuery Reservations voor voorspelbare workloads; scheid interactieve van batch-workloads via toewijzingen (assignments)
Storage lifecycle
- GCS: lifecycle-regels om over te gaan naar koudere opslag of te verwijderen na N dagen; schakel object-versiebeheer in waar rollback nodig is
- Voorbeeld (verkort): Verwijder niet-huidige versies na 30 dagen; stel een bucket retention policy in op 365 dagen voor compliance-zones
- BigQuery: standaard tabelverloopdatum (expiration) voor tijdelijke datasets; maak een snapshot vóór destructieve wijzigingen
Capaciteitsplanning
- Dataflow: stel max workers en autoscaling in; kies de juiste machine types (right-sizing); shard de input om hot keys te vermijden
- Pub/Sub: valideer publish/consume-quota’s en berichtretentie
- Netwerk: houd rekening met egress, verkeer tussen regio’s en private service access voor databases
Disaster recovery, back-ups, multi-regionale veerkracht en runbooks
- Classificeer services op basis van RTO/RPO; kies dienovereenkomstig cold/warm/hot-patronen
- Back-ups
- BigQuery: regelmatige tabel-snapshots; exporteer naar GCS voor off-platform retentie indien nodig
- GCS: dual-region of multi-region buckets voor duurzaamheid; schakel bucket lock in voor WORM-compliance
- Databases: beheerde back-ups in Cloud SQL en Bigtable; test het terugzetten (restores)
- Multi-region
- Houd compute en storage in dezelfde multi-regio om egress en latency te minimaliseren; vermijd intercontinentale afhankelijkheden tenzij vereist
- Runbooks
- Documenteer failover, sleutelherstel, KMS-incidentprocedures, rehydratatie vanuit exports en hertoewijzing van BigQuery-reservations
- Test DR via game days; volg de time-to-recover en update de SLO’s
Praktijkscenario
NovaRetail Analytics werkt samen met meerdere merken om dagelijks CSV’s met transactiedata op te nemen in een gedeeld analyseplatform. Bestanden komen binnen in een Cloud Storage landing bucket en bevatten af en toe onjuist geformatteerde rijen. Het platform moet het ’least privilege’-principe afdwingen, zodat elke klant alleen toegang heeft tot zijn eigen data, gevoelige velden detecteren en onmiddellijk waarschuwen wanneer rijen worden toegevoegd aan een specifieke audittabel. Het bedrijf heeft ook kostenbeheersing en een herstelplan nodig.
Aanpak:
Isoleer tenants en dwing ’least privilege’ af
- Maak een aparte BigQuery-dataset per klant (bijv. client_a_analytics). Geef alleen de groep van de klant de juiste dataset-rollen (bigquery.dataViewer, bigquery.jobUser) en beperk het gebruik van de BigQuery API tot goedgekeurde gebruikers via IAM en eventueel VPC-SC.
- Rationale: Een dataset per tenant beperkt de ‘blast radius’ en vereenvoudigt de complexiteit van rij-beleid. Scoping op datasetniveau met ’least privilege’ voorkomt standaard toegang tussen tenants.
Beheer schema, classificatie en maskering
- Definieer een Data Catalog policy tag-taxonomie (public, internal, confidential, restricted) en tag templates voor eigenaar, data steward en RTO/RPO. Koppel policy tags aan gevoelige kolommen (email, card_suffix) in elke klantendataset. Pas BigQuery-maskeringsbeleid toe om de weergave voor niet-geprivilegieerde rollen te beperken.
- Voorbeeld:
undefined
.
- Rationale: Centrale tags bieden uniforme controle over tabellen; maskering zorgt voor standaard veilige leesbewerkingen zonder data te dupliceren.
Ontdek PII en dwing de-identificatie af waar nodig
- Configureer Sensitive Data Protection discovery om de landing bucket en de gecureerde BigQuery-tabellen te scannen. Gebruik een inspectietemplate voor veelvoorkomende PII en een de-identificatietemplate om e-mails deterministisch te tokenizen voor join-use-cases.
- Rationale: Geautomatiseerde ontdekking vermindert handmatige fouten; deterministische tokenisatie brengt privacy in evenwicht met de join-vereisten voor analyses.
Beveilig de pipeline met service accounts, impersonation en CMEK
- Gebruik een Dataflow service account met alleen de benodigde rollen: storage.objectViewer op de landing bucket, bigquery.dataEditor op de doel-datasets, en indien nodig toegang tot policy tags. Gebruik CMEK voor de klantendatasets en geef de BigQuery en Dataflow service agents de CryptoKey Encrypter/Decrypter-rol.
- Rationale: Beperkte rollen plus CMEK voldoen aan de vereisten voor ’least privilege’ en sleutelbeheer. Toegang van de service agent tot sleutels voorkomt dat jobs mislukken.
Bouw een veerkrachtige opname (ingest) met foutenquarantaine
- Voer een batch Dataflow-job uit die de CSV’s leest, het schema valideert en geldige rijen naar gepartitioneerde BigQuery-tabellen schrijft. Leid ongeldige rijen om naar een BigQuery dead-letter-tabel met foutdetails (bestandsnaam, regel, reden).
- Rationale: Side outputs bewaren foute data voor analyse zonder de goede data te blokkeren; gepartitioneerde tabellen verlagen de scankosten en versnellen query’s.
Creëer lineage en business metadata
- Registreer de landing bucket en datasets als Dataplex-assets in een lake. Schakel lineage-verzameling in voor de Dataflow-job en tag gecureerde tabellen met business metadata (data-eigenaar, gevoeligheid, retentie).
- Rationale: Gecentraliseerde governance maakt impactanalyse, audit-gereedheid en gestandaardiseerd stewardship mogelijk.
Monitor, alarmeer en audit
- Schakel Admin en Data Access audit logs in, geëxporteerd met CMEK naar een centraal logging-project en naar BigQuery voor analyses. Voeg een op logs gebaseerde alert toe voor nieuwe rijen die aan de audittabel worden toegevoegd met behulp van een geavanceerd filter op BigQuery insert-jobs; exporteer die sink naar Pub/Sub zodat de monitoringtool deze kan consumeren.
- Rationale: Logs zijn fraudebestendig bewijs; gerichte alerts geven alleen een melding voor de vereiste tabel, wat ruis vermindert.
Dwing kostenbeheersing en query-guardrails af
- Vereis dat query-jobs maximumBytesBilled instellen en maak gebruik van clustering op kolommen met hoge cardinaliteit (bijv. order_id). Pas budgetten toe en stel labels in (client, environment) op jobs en datasets. Gebruik BigQuery Reservations om interactieve analyses te scheiden van geplande laadprocessen.
- Rationale: Guardrails voorkomen uit de hand lopende kosten; labels maken doorberekening (chargeback) mogelijk; slot-isolatie zorgt voor voorspelbare prestaties.
Implementeer retentie en DR
- Schakel in de landing bucket object-versiebeheer en een lifecycle-regel in om objecten na 30 dagen te verwijderen; stel een retentiebeleid in voor compliance-zones. Stel in BigQuery een standaard tabelverloopdatum in voor staging-tabellen en maak periodiek tabel-snapshots van gecureerde tabellen. Bewaar KMS-back-upprocedures en stappen voor het herstellen van tabellen in runbooks en test deze per kwartaal.
- Rationale: Lifecycle management verlaagt de opslagkosten; snapshots en gedocumenteerde runbooks garanderen herstelbaarheid. Testen valideert de RTO/RPO-aannames.
Periodieke toegangsreviews en kwaliteits-SLI’s/SLO’s
- Exporteer per kwartaal IAM-beleid met Cloud Asset Inventory en vergelijk dit met een goedgekeurde baseline. Definieer SLO’s zoals “99% van de dagelijkse bestanden verwerkt binnen 30 minuten na aankomst” met alerts op de burn rate. Volg datakwaliteits-SLI’s (volledigheid, validiteit) met Dataplex Data Quality-regels en stuur schendingen door naar incidentrespons met backfill-automatisering.
- Rationale: Regelmatige reviews voorkomen ‘privilege creep’; SLO-gestuurde operaties stemmen de inspanning af op de gebruikerservaring; geautomatiseerde kwaliteitscontroles detecteren regressies vroegtijdig.
Behandelde technische afwegingen en faalscenario’s:
- Een verkeerde CMEK-configuratie of het uitschakelen van een sleutel zal Dataflow-loads en BigQuery-query’s breken; monitoring van de KMS-status en de permissies van de service agent is verplicht.
- Overmatig gebruik van fijnmazig rij-beleid kan de prestaties verminderen; geef de voorkeur aan dataset-isolatie voor tenants.
- Discovery-scans kunnen kostbaar zijn; beperk de scope per zone en neem waar mogelijk steekproeven, en accepteer het risico dat zeldzame PII wordt gemist.
- Alert-moeheid vermindert de reactiesnelheid; bouw precieze filters per tabel/actie en test deze vóór de uitrol.
← Machine Learning · Alle domeinen
Oefen deze vragen → · Getimede oefening op ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Slaag voor je examen →