Google ACE: Opslag, databases en datadiensten — Studiegids

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

Onderdeel van de Google Associate Cloud Engineer — Studiegids. Oefen met geverifieerde antwoorden in het Google-examencentrum, of doe getimede oefentests op ExamRoll.io.

Overzicht

Deze sectie biedt een praktische, op operations gerichte referentie voor Google Cloud storage, databases en analytische dataservices. Het legt de nadruk op configuratiepatronen, toegangsbeheer, duurzaamheidsmechanismen, prestatie- en kostenkenmerken, en veilige herstelprocedures. Het doel is om u te helpen beslissen welke service te gebruiken voor een bepaalde workload, de operationele afwegingen te begrijpen en te anticiperen op veelvoorkomende storingen.

Cloud Storage ontwerp, toegang, lifecycle en bescherming

Cloud Storage is duurzame, hoog beschikbare object storage voor ongestructureerde data en back-ups.

Buckets en objecten: Buckets zijn globale naamruimten in een locatie (regio of dual/multi-region) die onveranderlijke objectversies bevatten. Kies de bucket-locatie om egress te minimaliseren en te voldoen aan data-residentie-eisen.
Storage classes: Gebruik Standard (hot), Nearline (~30 dagen min), Coldline (~90 dagen min), en Archive (~365 dagen min) op basis van toegangsfrequentie. Voor DR-back-ups is Coldline een gangbare standaard. Je kunt klassen per object binnen een bucket combineren.
Lifecycle-regels: Automatiseer overgangen en verwijderingen op basis van Age, CreatedBefore, MatchesStorageClass en NoncurrentVersion condities. Voorbeeld om na 90 dagen over te zetten en na 365 dagen te verwijderen:
1. lifecycle.json:

undefined

Toepassen:

undefined

Retentie en legal holds: Retentiebeleid voorkomt verwijdering of wijziging van objecten voordat de periode verstrijkt; het vergrendelen van het beleid is onomkeerbaar. Legal holds zijn per object en moeten worden opgeheven voordat verwijdering mogelijk is.

Toegangsbeheer en delen:

Uniform vs fijnmazig: Geef de voorkeur aan Uniform bucket-level access (UBLA) om permissies uitsluitend met IAM te beheren. Fijnmazige toegang (object ACL’s) is legacy en bemoeilijkt de controleerbaarheid en propagatie. Het inschakelen van UBLA deactiveert ACL’s en kan onmiddellijk bestaande integraties beïnvloeden die afhankelijk waren van ACL’s.
Signed URLs: Gebruik signed URLs voor kortstondige toegang zonder een Google-identiteit. Vermijd service account key-bestanden door te ondertekenen met IAM:

undefined

Zorg ervoor dat het serviceaccount de rol ‘Service Account Token Creator’ op zichzelf heeft of via een ‘signer’-rol.

Encryptie: Standaard server-side encryptie; schakel CMEK in op bucket- of objectniveau wanneer je controle over sleutels en audittrails nodig hebt. Monitor de beschikbaarheid en rotatie van KMS-sleutels; onbeschikbaarheid van CMEK blokkeert uploads en decrypties.
Versioning: Schakel object versioning in om niet-huidige versies te bewaren na overschrijvingen/verwijderingen. Combineer met lifecycle-regels om niet-huidige versies te laten verlopen en de opslaggroei te beheersen. Wees je bewust van de client-side logica voor het opvragen van lijsten wanneer er veel versies bestaan.

Storingsmodi en mitigatie:

Onopzettelijke verwijdering of overschrijving: Gebruik versioning en retentiebeleid. Voor strikte compliance, vergrendel het retentiebeleid.
Verkeerd geconfigureerde publieke toegang: Dwing Public Access Prevention en UBLA af. Controleer periodiek met Cloud Asset Inventory en policy analyzer.
Buitensporige kosten: Lifecycle-regels, object-level klassen en requester pays verminderen verrassingen. Monitor met Cloud Monitoring-metrics en budgetten.

Handige commando’s:

Bucket aanmaken met UBLA en retentie:

undefined

Block en file storage voor compute workloads

Kies opslag op basis van toegangspatroon, prestatiebehoeften en duurzaamheidseisen voor Compute Engine en GKE.

Persistent Disk (PD): Duurzame block storage, zonaal of regionaal. Typen: Standard (HDD) voor sequentiële doorvoer; Balanced (pd-balanced) en SSD (pd-ssd) voor lage latency en hoge IOPS. Regionale PD repliceert synchroon over zones, wat een sneller herstel mogelijk maakt. PD kan worden gesnapshot, online worden vergroot/verkleind, en read-only aan meerdere VM’s worden gekoppeld (single-writer voor read-write).
- Afwegingen: Hogere IOPS-kosten op SSD; HDD is kosteneffectief maar heeft een hoge latency voor willekeurige IO. Regionale PD kost meer maar verlaagt de RTO.
Local SSD: NVMe of SCSI-gekoppelde efemere opslag met zeer hoge IOPS en lage latency. Data gaat verloren bij het stoppen van de VM of bij hostonderhoud; gebruik het alleen voor efemere caches of gerepliceerde data. Maak elders back-ups of repliceer om dataverlies te voorkomen.
Filestore: Beheerde NFS voor POSIX-gedeelde bestandsemantiek. Basic-tiers zijn zonaal; Enterprise en hogere tiers bieden regionale HA met synchrone replicatie en hogere IOPS. Ideaal voor GCVE, HPC scratch, media rendering en apps die gedeelde file locking vereisen.
- Afwegingen: NFS introduceert client-side caching en lock-semantiek; doorvoer en latency verschillen per tier; niet geschikt voor kleine willekeurige IO met latency’s van enkele microseconden zoals local SSD.

Overwegingen bij storingen:

Hostonderhoud: Dataverlies op Local SSD; bescherm met applicatiereplicatie.
Zonale storingen: Onderbrekingen van zonale PD en Basic Filestore; gebruik regionale PD of Filestore Enterprise voor HA.
Snapshotconsistentie: Voor applicatieconsistente PD-snapshots, coördineer met een filesystem freeze of database native quiesce om crash recovery-vensters te vermijden.

Beheerde databases en datadiensten

Cloud SQL (beheerde MySQL, PostgreSQL, SQL Server):

Configuratie: Kies machine shape, opslagtype, verbindingen (private IP heeft de voorkeur), geautoriseerde netwerken bij gebruik van een public IP, onderhoudsvensters en insights voor prestatiediagnostiek. Gebruik connection pooling (bv. Cloud SQL Auth Proxy, PGbouncer) om binnen de limieten voor verbindingen en CPU te blijven.
Hoge beschikbaarheid (HA): Regionale HA-instances implementeren een standby in een andere zone met synchrone opslagreplicatie; failover is automatisch. Verwacht een kort venster van onbeschikbaarheid voor schrijfacties tijdens de failover.
Replica’s: Read replica’s voor het schalen van leesoperaties en het offloaden van BI; externe replicatie voor migraties. Monitor replica lag en ontwerp idempotente readers.
Back-ups en PITR: Schakel geautomatiseerde back-ups en binary/WAL-logging in voor point-in-time recovery (PITR). Test het terugzetten van back-ups (restores) regelmatig. gcloud sql instances patch my-sql –backup-start-time=03:00 –enable-bin-log
Faalscenario’s: Langlopende transacties blokkeren vacuum/checkpointing; pieken in verbindingen veroorzaken ’thrashing’; automatische opslaggroei (autogrow) kan vastlopen als het quotum onvoldoende is. Stel alerts in voor CPU, geheugen, verbindingen, replica lag en schijfgebruik.

Cloud Spanner:

Schaal en regionaliteit: Regionale of multi-regionale instances met synchrone replicatie en sterke globale consistentie. Schaal nodes voor doorvoersnelheid (throughput) en opslag; de plaatsing van de leader-regio beïnvloedt de schrijflatentie.
Schema en sleutels: Ontwerp primary keys om hotspots te vermijden; gebruik samengestelde sleutels (composite keys) met een gehasht of willekeurig voorvoegsel voor tijdreeksen om schrijfacties te verdelen. Gebruik secundaire indexen voor querypatronen en overweeg om vaak gefilterde kolommen samen op te slaan. Houd transacties klein en beperkt om lock-conflicten te minimaliseren.
Transacties: Sterk consistente, gedistribueerde transacties met externe consistentie via TrueTime. Schrijflatentie wordt begrensd door het quorum; conflicten leiden tot afgebroken transacties—probeer opnieuw met ‘backoff’.

Firestore en Bigtable:

Firestore (Native mode): Document store met collections, real-time listeners, transacties over maximaal 500 documenten per transactie, en sterke consistentie voor het lezen van documenten en de meeste query’s. Meest geschikt voor data van mobiele/web-apps, hiërarchische JSON en event-driven apps.
Bigtable: Wide-column database voor petabyte-schaal en een latentie van minder dan 10 ms. Alleen transacties op één rij (single-row); ontwerp row keys om hotspotting te vermijden. Ideaal voor tijdreeksen, IoT, personalisatie en grootschalige ‘counters’. Niet voor ad-hoc joins of complexe aggregaties.

Memorystore:

Redis en Memcached: In-memory caches voor een latentie van microseconden tot milliseconden. De Basic-tier heeft geen HA; de Standard-tier biedt regionale HA met automatische failover voor Redis. Behandel als efemeer (kortstondig); niet gebruiken als het ‘system of record’.

BigQuery:

Datasets en tabellen: Organiseer per dataset; beheer toegang op project-, dataset-, tabel-, kolom- en rijniveau. Gebruik gepartitioneerde en geclusterde tabellen om de gescande bytes en kosten te beheersen.
Load- en query-jobs: Laad data vanuit Cloud Storage, Cloud SQL-exports of via streaming inserts. Gebruik ‘dry runs’ om de kosten in te schatten: bq query –use_legacy_sql=false –dry_run=true ‘SELECT …’
Toegangsbeheer: Verleen de rol BigQuery Data Viewer op dataset-niveau voor read-only gebruikers; gebruik ‘authorized views’ of ‘row-level/column-level security’ voor het ’least privilege’-principe.

Afwegingen bij dataverplaatsing, migratie, validatie en operations

Migratie en overdracht:

Database Migration Service (DMS): Voor homogene migraties naar Cloud SQL met minimale downtime via replicatie. Valideer de cutover met lag-metrics en checksum-vergelijkingen.
Cloud Storage-overdrachten: Storage Transfer Service voor repetitieve of event-driven overdrachten; gsutil -m rsync voor eenmalige gesynchroniseerde kopieën met checksums; Transfer Appliance voor grote offline verplaatsingen.
Import/export: Cloud SQL exporteert naar Cloud Storage; herimporteren ondersteunt PITR-bootstrap en dataverificatie. BigQuery ondersteunt batch-ladingen vanuit Cloud Storage en exporteert naar Avro/Parquet voor downstream gebruik.
Validatie: Gebruik object-checksums (CRC32C), tellingen van rijen (row counts), steekproefqueries en invarianten op applicatieniveau. Vergelijk voor BigQuery de resultaten van GROUP BY-tellingen of hashes tussen de bron en het doel.

Afwegingen tussen prestaties, beschikbaarheid, capaciteit en kosten:

Cloud Storage: Optimaliseer egress door compute in dezelfde locatie te plaatsen (co-locating); kies klassen op basis van toegangsfrequentie; gebruik dual/multi-region voor cross-zone veerkracht en hogere beschikbaarheid tegen hogere opslagkosten.
PD/Filestore: SSD voor IO met lage latentie; HDD voor doorvoersnelheid; regionale replicatie voor HA; kies de juiste IOPS-grootte (right-sizing) om throttling te voorkomen.
Cloud SQL: Verticaal schalen is eenvoudig maar beperkt; read replicas nemen leesverkeer over; HA voegt beschikbaarheid toe, maar geen leescapaciteit; de opslagklasse beïnvloedt de latentie en kosten.
Spanner: Schaalt horizontaal met sterke consistentie; de premiumkosten worden gecompenseerd door wereldwijde RPO/RTO en vereenvoudigde sharding. Schrijfacties zijn gevoelig voor het sleutelontwerp en de latentie van de leader-regio.
Firestore/Bigtable/Memorystore: Kies op basis van latentie, datamodel en consistentie. In-memory caches verminderen de databasebelasting, maar voegen complexiteit toe rond cache-invalidatie.
BigQuery: On-demand kosten zijn evenredig met het aantal gescande bytes; partitionering/clustering en predicate pushdown verlagen de kosten. Flat-rate reserveringen ruilen voorspelbaarheid in voor een commitment.

Probleemoplossing en veilig herstel:

Cloud Storage: Gebruik object versioning en retentie voor herstel; onderzoek Cloud Logging data access logs om lees-/schrijfevents te auditen; zorg ervoor dat CMEK-sleutels zijn ingeschakeld tijdens herstel.
PD/Filestore: Herstel vanaf snapshots of back-ups; voer fsck en database-herstelmodi uit; zorg voor consistentie door de applicatie op app-niveau stil te leggen (quiesce) voordat een snapshot wordt gemaakt.
Cloud SQL: Herstel naar een nieuwe instance voor PITR om dataverlies op de primaire instance te voorkomen; verifieer met read-only tests; onderhoud de firewall en private DNS voor veilige cutover-patronen.
Spanner/Bigtable: Onderzoek hotspotting via scheve toegang tot sleutels (key access skew); gebruik Monitoring om latentie en throttling te volgen; implementeer backoff en retries voor afgebroken transacties of operaties die door rate-limiting worden beperkt.
BigQuery: Diagnoseer trage queries via de uitvoeringsdetails (execution details); voeg partities en clustering toe; beperk SELECT *; materialiseer tussenresultaten waar nodig. Herstel verwijderde tabellen binnen het time travel-venster door een snapshot te herstellen of te kopiëren vanaf een snapshot-tijdstip.

Praktisch Probleemscenario

Contoso Retail consolideert back-ups en analytics-data, terwijl ze de toegangscontroles versterken en point-in-time recovery (PITR) inschakelen voor hun transactionele systemen. Ze moeten: applicatieback-ups opslaan met geautomatiseerde tiering, bestanden voor korte duur delen met derden, PITR inschakelen voor een kleine relationele workload, en de kosten van analytics-queries schatten vóór uitvoering.

Aanpak:

Maak een regionale Cloud Storage-bucket met UBLA, retentie en lifecycle.
- Commando: gcloud storage buckets create gs://contoso-backups –location=us-central1 –uniform-bucket-level-access –default-storage-class=STANDARD gcloud storage buckets update gs://contoso-backups –retention-period=365d gsutil lifecycle set lifecycle.json gs://contoso-backups
- Reden: UBLA centraliseert autorisatie in IAM en verbetert de auditeerbaarheid. Een retentieperiode van één jaar voorkomt onbedoelde verwijdering. Lifecycle verplaatst back-ups na 90 dagen naar Coldline en verwijdert ze bij het verlopen om de kosten te beheersen.
Verleen alleen-schrijftoegang (write-only) voor back-uptaken via een toegewezen serviceaccount.
- Commando: gcloud storage buckets add-iam-policy-binding gs://contoso-backups –member=serviceAccount:backup-writer@contoso.iam.gserviceaccount.com –role=roles/storage.objectCreator
- Reden: storage.objectCreator voorkomt het aanpassen van metadata en het teruglezen van gevoelige back-ups, in lijn met het principe van ’least privilege’.
Deel een gevoelige back-up met een leverancier voor vier uur met behulp van een signed URL, zonder sleutels te verspreiden.
- Commando: gcloud storage sign-url gs://contoso-backups/db-dump-2024-09-30.sql.gz –duration=4h –impersonate-service-account share-signer@contoso.iam.gserviceaccount.com
- Reden: Tijdsgebonden, identiteitsloze toegang voorkomt het aanmaken van externe identiteiten of langlevende secrets. Impersonation maakt gebruik van gecentraliseerde ondertekening ondersteund door KMS en elimineert het risico op gelekte sleutels.
Schakel Cloud SQL-back-ups en PITR in voor de orderdatabase.
- Commando: gcloud sql instances patch orders-sql –backup-start-time=02:00 –enable-bin-log
- Reden: Geautomatiseerde back-ups plus binary/WAL-logging bieden herstelpunten tot op de seconde nauwkeurig binnen het retentievenster, wat beschermt tegen logische corruptie en menselijke fouten.
Test het herstel door te restoren naar een nieuwe instance en de data te valideren vóór de cutover.
- Commando: gcloud sql backups list –instance=orders-sql gcloud sql instances restore-backup orders-restore –backup-id=LATEST –destination-instance=orders-restore
- Reden: Herstellen naar een afzonderlijke instance voorkomt impact op de productie en maakt validatie mogelijk via checksums en steekproefqueries vóór een switch op DNS- of applicatieniveau.
Schat de kosten van een BigQuery-query met een dry run en optimaliseer met partitionering.
- Commando: bq query –use_legacy_sql=false –dry_run=true ‘SELECT COUNT(*) FROM contoso.analytics.sales WHERE sale_date >= “2026-01-01”’
- Reden: Dry runs tonen het aantal te scannen bytes; door ervoor te zorgen dat sale_date een partitiekolom is met een begrensd predicaat, wordt het aantal gescande bytes verminderd en worden de on-demand kosten beheerst.
Monitor en audit de toegang.
- Stappen:
  - Schakel Data Access logs in voor Cloud Storage en BigQuery.
  - Configureer Cloud Monitoring-alerts voor Cloud SQL-verbindingen, schijfgebruik en mislukte back-ups.
- Reden: Data Access logs bieden inzicht in lees-/schrijfacties op objectniveau voor compliance. Proactieve alerts verkorten de MTTR en zorgen ervoor dat back-ups en PITR effectief blijven.
Documenteer faalscenario’s en runbooks.
- Stappen:
  - Leg procedures vast voor het herstellen van objectversies, het intrekken van signed URL’s, Cloud SQL PITR en het herstellen van BigQuery-tabellen met behulp van time travel.
- Reden: Duidelijke, geteste runbooks verminderen het operationele risico tijdens incidenten en standaardiseren veilige herstelpraktijken binnen teams.