Google PCA: Migratie, Modernisering en Hybride Cloud-strategie — Studiegids

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

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

Overzicht

Een succesvolle migratie-, moderniserings- en hybride-cloudstrategie stemt platformkeuzes af op bedrijfsresultaten, terwijl risico’s voor beschikbaarheid, data-integriteit, latency, beveiliging en kosten worden beheerd. Het traject balanceert een snelle ‘rehost’ om risico’s in het datacenter te verminderen met gerichte ‘refactoring’ om de voordelen van de cloud te benutten. Het operationele model moet meegroeien met de technologie om verbeteringen te bestendigen. Dit gedeelte biedt een pragmatische blauwdruk voor assessment en wave-planning, beslissingskaders, migratiemechanismen, hybride integratie, moderniseringspatronen, beleids- en multi-cloudoverwegingen, en optimalisatie na de migratie, met de nadruk op faalmodi en afwegingen.

Assessment, Readiness en Wave-planning

• Discovery en afhankelijkheidsanalyse

  • Inventariseer workloads, versies, OS-kernels, storage, IAM en dataklassificaties. Breng afhankelijkheden in kaart voor web→API→DB-stromen, gedeelde services (LDAP/AD, DNS, NTP), batch-pipelines en externe API’s.
  • Gebruik applicatieprofilering en ‘distributed tracing’ in pre-migratieomgevingen om verborgen afhankelijkheden en ’long-tail latency’ aan het licht te brengen. Schakel VPC Flow Logs en instrumentatie op applicatieniveau (Cloud Logging, Cloud Monitoring, Cloud Trace) in.
  • Identificeer ‘state boundaries’ en ‘data gravity’: omvang, toegangspatronen (R/W-mix), consistentieverwachtingen en replicatietopologie.

• Gereedheid en vaardigheden

  • Beoordeel de kennis van cloud fundamentals, IaC, CI/CD, SRE, security, networking en databases. Definieer een rolgebaseerd trainings- en certificeringstraject en budgetteer tijd voor bijscholing en schaduw-on-calls.
  • Zet een ’landing zone’ op (projecten, folders, Shared VPC, organisatiebeleid, audit-sinks, CMEK-strategie) vóór de eerste wave.

• Migratiewave-planning

  • Groepeer applicaties in waves op basis van affiniteit en ‘blast radius’: gedeelde data, synchrone afhankelijkheden en change windows. Trek afhankelijkheden met een hoog risico in dezelfde wave of vang ze op met goed gedefinieerde API-contracten (‘stubbing’).
  • Definieer per wave SLO’s, RTO/RPO, rollback-criteria en validatiepoorten (‘gates’) (schemacontroles, synthetische gebruikerstrajecten, prestatiedrempels).
  • Bereid runbooks en change management voor: cutover-stappen, checkpoints, rollback en het verzamelen van bewijs voor goedkeuring (‘sign-off’).

• Compatibiliteit, licenties en performance-baselining

  • Valideer de ondersteuning voor OS en middleware in Compute Engine en beheerde services. Controleer commerciële licentievoorwaarden, BYOL-beperkingen, vereisten voor kernelmodules en hardware-affiniteiten.
  • Leg basislijnen vast voor CPU, geheugen, IOPS, doorvoer en latency met piek- en 95e-percentielwaarden om de doelresources te dimensioneren en de voordelen te valideren.

• Data governance

  • Classificeer PII/PCI-data. Plan de-identificatie of tokenisatie bij ‘ingest’ met behulp van Cloud DLP. Definieer audit-, bewaar- en exportbeleid voordat het eerste productielog wordt opgeslagen.

Veelvoorkomende faalmodi: onbekende synchrone afhankelijkheden die na de cutover trapsgewijze time-outs veroorzaken; overlappende IP-ranges die de connectiviteit blokkeren; hiaten in licentieconformiteit; gebrek aan rollback-pariteit waarbij datamutaties niet ongedaan gemaakt kunnen worden.

Migratiepatronen, Gegevensverplaatsing en Cutover

• Beslissingskader (de 6 R’s)

  • Rehost: as-is verplaatsen naar Compute Engine. Snelste time-to-cloud, minimale verandering. Risico: neemt technische schuld en inefficiënte dimensionering mee.
  • Replatform: kleine aanpassingen om managed services te adopteren (bijv. Cloud SQL, Cloud Load Balancing). Snellere operationele voordelen met weinig codewijzigingen.
  • Refactor: decomponeren of containeriseren voor GKE/Cloud Run; event-driven patronen adopteren. Hoogste voordeel op lange termijn met een risico voor de oplevering.
  • Retire: ongebruikte systemen verwijderen nadat is bewezen dat er geen gebruik en afhankelijkheden meer zijn.
  • Retain: on-premise behouden omwille van regelgeving of latency; integreren via een hybride opzet.
  • Relocate: vSphere-workloads verplaatsen naar Google Cloud VMware Engine; behoudt tooling en minimaliseert veranderingen.

• Tools voor compute- en databasemigratie

  • Migrate to Virtual Machines versnelt rehosting naar Compute Engine met behoud van schijven en netwerkconfiguratie. Valideer de ondersteuning voor het gastbesturingssysteem en de kernel-drivers.
  • Database Migration Service biedt homogene online replicatie (bijv. MySQL, PostgreSQL) naar Cloud SQL met weinig downtime. Zorg ervoor dat de binlog/replicatie-instellingen correct zijn en dat de latency een near-real-time inhaalslag ondersteunt.
  • Kies databases die passen bij de workload:
    • Cloud SQL voor beheerde relationele behoeften; schakel automatische opslagvergroting in en monitor CPU rond 75% per core; volg replicatievertraging (replication lag) en shard of schaal op als drempelwaarden worden benaderd.
    • Bigtable voor time-series-ingestie met lage latency en hoge doorvoersnelheid (bijv. sensordata).
    • Spanner voor wereldwijde schaal en sterke consistentie; begrijp de afweging tussen lock-in en portabiliteit.
  • Gegevensverplaatsing
    • Storage Transfer Service voor doorlopende of geplande overdrachten; parallel en ‘retry-aware’.
    • Transfer Appliance voor eenmalige bulk-uploads (tientallen tot honderden TB) om netwerktijd en risico’s te verminderen.
    • gsutil en parallelle samengestelde uploads voor kleine tot middelgrote datasets.

• Online vs. offline migratie

  • Online: continue replicatie met een korte cutover. Voordelen: minimale downtime; Nadelen: vereist stabiele latency en bandbreedte; zorgvuldig ‘dual-write’ vermijden.
  • Offline: snapshot en bulk-import. Voordelen: eenvoudig en voorspelbaar; Nadelen: downtime is gelijk aan de kopieerduur.

• Cutover-planning, rollback en downtimebeheer

  • Verlaag DNS TTL’s dagen voor de cutover, bevries niet-essentiële wijzigingen en plan een onderhoudsvenster.
  • Voer validatiepoorten uit: schemapariteit, checksums of ‘row counts’, ‘smoke tests’ voor de applicatie, ‘canary traffic’ en performance-probes.
  • Rollback: zorg voor achterwaarts compatibele schemawijzigingen, ‘feature flags’ en het behoud van de ‘source-of-truth’-data. Vermijd onomkeerbare schrijfacties totdat de stabiliteit is bewezen.
  • Voorbeeld van VM-schijfuitbreiding met minimale downtime:
    • Schijf vergroten in de Console of CLI:

undefined

- Op Linux ext4:

undefined

• Rolling app-updates met minimale impact op GKE:

undefined

Veelvoorkomende faalscenario’s: pakketverlies over Cloud VPN dat databasereplicatie verstoort (gebruik Dedicated Interconnect of Partner Interconnect), ‘dual-write’-divergentie tijdens de cutover, ontbrekende health checks die rolling updates stoppen.

Hybride Identiteit, Connectiviteit en On-Premise Integratie

• Identiteit

  • Behoud Active Directory als de ‘source of truth’. Gebruik Google Cloud Directory Sync voor account- en groepsynchronisatie en configureer SAML SSO voor gebruikerstoegang tot Google Cloud.
  • Ken ’least-privilege’ IAM toe via rollen, gebruik serviceaccounts voor workloads en geef de voorkeur aan Workload Identity Federation boven langlevende sleutels.

• Hybride connectiviteit en routing

  • Gebruik Cloud VPN voor initiële behoeften met lage doorvoer en voor testen; stap over op Dedicated Interconnect voor aanhoudende bandbreedte, lagere latency en voorspelbare replicatieprestaties. Implementeer redundante VLAN-attachments en HA VPN of dubbele interconnects voor veerkracht.
  • Zorg ervoor dat Google Cloud IP-ranges niet overlappen met on-premise CIDR’s om end-to-end bereikbaarheid te behouden.

  • Dwing gelaagde toegang af met firewallregels en tags. Voorbeeld om alleen web→API toe te staan:

undefined

• Gebruik Private Service Connect en private Google access voor service-naar-service communicatie zonder publieke egress; segmenteer waar nodig met VPC Service Controls.

• Hybride DNS: gebruik Cloud DNS met forwarding en inkomende/uitgaande beleidsregels (policies) om zowel on-premise als cloud-namen te resolven.

• On-premise integratie en latency

  • Houd state dicht bij compute of vice versa; als de on-premise DB de autoritatieve bron moet blijven, overweeg dan App Engine flexible of Compute Engine met Cloud VPN/Interconnect voor private toegang.
  • Introduceer caches en wachtrijen om synchrone paden te ontkoppelen en latency-jitter op te vangen; meet p95/p99-latency, niet alleen de gemiddelden.

Veelvoorkomende faalscenario’s: overlappende CIDR’s die routes blokkeren, onvoldoende BGP-sessieredundantie, lekken via publieke DNS of egress die private services blootstellen, en onverwachte ‘chatty’ protocollen die lijden onder verbindingen met hoge latency.

← Betrouwbaarheid · Alle domeinen · Operations →

Oefen deze vragen → · Getimede oefening op ExamRoll.io →

Blader door Google →