Google ACE: Compute Engine en virtuele-machineoperaties — 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

Compute Engine biedt flexibele, high-performance virtuele machines en orkestratieprimitieven voor het uitvoeren van algemene en gespecialiseerde workloads. Operationele uitmuntendheid op Compute Engine betekent het selecteren van de juiste machinefamilie en schijf, het vormgeven van de instance-levenscyclus met templates en instance groups, het opzetten van robuuste autohealing en autoscaling, het beveiligen van toegangspaden en het voorbereiden op storingsscenario’s met herhaalbare herstelprocedures. Dit gedeelte legt ontwerpkeuzes, afwegingen en operationele patronen uit die de werklast minimaliseren en de betrouwbaarheid en kostenefficiëntie maximaliseren.

Machinetypes, Sizing en Instance-levenscyclus

Machinefamilies

General-purpose: E2 (kosten-geoptimaliseerd), N2 (gebalanceerd), N2D (op AMD-gebaseerd), Tau T2D/T2A (hoge prijs-prestatieverhouding voor scale-out), geschikt voor de meeste workloads.
Compute-optimized: C3 voor CPU-gebonden taken; kies deze wanneer u hoge prestaties per core nodig heeft.
Memory-optimized: M-series voor in-memory databases en analytics.
GPU’s en accelerators: Koppel aan ondersteunde families wanneer u CUDA- of ML-acceleratie nodig heeft; zorg ervoor dat de initialisatie van stuurprogramma’s wordt vastgelegd in opstartprocessen.

Aangepaste machinetypes

Gebruik aangepaste vCPU en geheugen om workloads de juiste omvang te geven en verspilling te verminderen, vooral bij asymmetrische behoeften (bijv. veel geheugen maar een gematigde CPU).
Geef voor CPU-gebonden services de voorkeur aan een hoger aantal vCPU’s; verhoog voor geheugengebonden services het RAM en zorg ervoor dat garbage collectors en caches zijn afgestemd.
Let op licentiemodellen die gekoppeld zijn aan het aantal cores; aangepaste types helpen onnodig gelicentieerde cores te vermijden.

Workload-sizing

Begin met resourceprofielen die zijn gemeten in ontwikkelings- of eerdere omgevingen: CPU-gebruik op P95, ‘high-water mark’ van het geheugen, schijfdoorvoer/IOPS, netwerkbandbreedte.
Plan voor piekverkeer extra capaciteit (headroom) of gebruik autoscaling; streef voor een stabiele toestand naar 60-70% bezetting tijdens piekmomenten om kosten en veerkracht in evenwicht te brengen.
Evalueer Spot VM’s (preemptible) voor batch- en fouttolerante taken; ze kunnen op elk moment worden beëindigd, dus ontwerp met checkpointing en ‘retry’-mechanismen.

Resources voor de instance-levenscyclus

VM-instances: De atomische compute-resource. Gebruik labels en een consistente naamgeving om automatisering aan te sturen.
Instance templates: Onveranderlijke blauwdrukken die machinetype, schijven, service accounts, metadata en opstartscripts vastleggen; ze vormen de basis voor managed instance groups en zorgen voor herhaalbare implementaties.
Managed instance groups (MIG’s): Bieden declaratieve grootte, autoscaling, autohealing, rolling updates, regionale (multi-zone) plaatsing en per-instance configuratie. Geef de voorkeur aan MIG’s voor stateless en stateful patronen (stateful MIG’s behouden geselecteerde schijven/IP’s).
Unmanaged instance groups: Eenvoudige verzamelingen voor load balancing van legacy-sets; missen autoscaling/autohealing. Gebruik deze alleen wanneer u onafhankelijk beheerde VM’s moet registreren.

Beschikbaarheid, Autoscaling en Onderhoud

Autoscaling

Signalen: CPU-gebruik, HTTP load balancer-verzoeken per seconde per instance, Cloud Monitoring-metrics en wachtrijdiepte. Kies een signaal dat sterk correleert met verzadiging; CPU is een goede basislijn voor homogene, CPU-gebonden workloads.
Cooldowns en stabilisatie: Configureer om ’thrashing’ (snel op- en afschalen) te voorkomen. Als uw app minuten nodig heeft om op te warmen, verhoog dan de ‘initial delay’ van de MIG en stel een geschikte autoscaling-cooldown in.
Exact-één-patronen: Om precies één VM af te dwingen, stelt u autoscaling min=1 en max=1 in op een MIG. Dit waarborgt de gezondheid en maakt tegelijkertijd autohealing mogelijk.

Autohealing en health checks

Health checks: Gebruik HTTP(S)-checks voor de ’liveness’ van de applicatie; TCP valideert alleen de acceptatie van een socket. Implementeer een health-endpoint dat kritieke afhankelijkheden test.
Drempels en intervallen: Stem het ‘check-interval’ en de drempels af om storingen snel te detecteren zonder valse positieven.
Initial delay: Stel de ‘initial delay’ voor autohealing van de MIG lang genoeg in voor het opstarten en opwarmen, om voortijdige vervanging van gezonde instances die online komen te voorkomen.
Storingsscenario’s: Verkeerd geconfigureerde health-endpoints en te korte ‘initial delays’ veroorzaken ‘flapping’ (instabiliteit) en overprovisioning.

Regionale MIG’s en plaatsing

Regionale MIG’s verdelen instances over meerdere zones in een regio, wat tolerantie biedt voor zone-uitval. Kies het aantal doelreplica’s per zone op basis van capaciteitsplanning.
Gebruik ‘per-instance configs’ en ‘stateful policies’ wanneer het behouden van schijven of IP’s vereist is; begrijp dat het vervangen van VM’s langzamer kan zijn vanwege de statusreconciliatie.

Onderhoud, live migration en reserveringen

Live migration: Standaard voor de meeste VM’s; instances worden tijdens hostonderhoud verplaatst zonder herstart. Voor workloads die geen migratie kunnen verdragen (bijv. latency-gevoelige HFT), stelt u het onderhoudsbeleid in op ’terminate’ en vertrouwt u op autohealing.
Hostonderhoudsvensters zijn transparant met live migration, maar genereren nog steeds events; monitor en test dit.
Reserveringen: Maak zonale reserveringen om capaciteit te garanderen voor kritieke lanceringen of strikte SLO’s. Pas ‘specific’ of ‘any’ reserveringsverbruik toe op basis van uw governance.
Reserveringen zijn capaciteitsgaranties; koppel ze aan ‘committed use discounts’ voor kostenplanning.

Opslag, Images en Prestaties

Permanente schijven

Typen: Standard (HDD) voor sequentiële doorvoer tegen lage kosten; Balanced (pd-balanced) voor algemeen gebruik; SSD (pd-ssd) voor hoge IOPS/lage latentie; Extreme (pd-extreme) voor ‘provisioned’ IOPS en doorvoer op high-performance niveaus. Regionale PD’s bieden synchrone replicatie over zones voor verhoogde beschikbaarheid.
Prestaties schalen mee met de schijfgrootte voor standard, balanced en SSD; bepaal de grootte vooraf om te voldoen aan piek-IOPS/doorvoer of gebruik Extreme om expliciet te provisioneren.
Multi-attach read-only maakt het delen van datasets over meerdere VM’s mogelijk; coördineer de toegangs- en caching-lagen hierop.

Lokale SSD

Efemeer, direct aan de host gekoppeld, zeer hoge IOPS/lage latentie. Data gaat verloren bij stop/terminate/migrate. Gebruik voor scratch, caches en gerepliceerde datalagen. Zorg voor replicatie of checkpoints op applicatieniveau.

Snapshots en images

Snapshots zijn incrementele, point-in-time back-ups van permanente schijven; plan ze in met Resource Manager of gcloud om aan de RPO te voldoen. Cross-region opslag ondersteunt DR.
Images bevatten opstartschijven plus configuratie. Onderhoud een ‘hardened’, patch-beheerde image-pipeline. Valideer guest agents (voor logging/monitoring) binnen je ‘golden images’.
Herstelpatronen: Houd voor snel herstel de basis-images klein en configureer de rest via opstartscripts of cloud-init; dit vermindert ‘drift’ en versnelt updates.

Schijfkeuzes: afwegingen en faalmodi

Ondergeprovisioneerde schijven beperken de doorvoer van applicaties; overprovisioning is een verspilling van kosten. Meet de werkelijke I/O-kenmerken en kies de kleinst mogelijke schijf die met een marge aan de piekbehoeften voldoet.
Overweeg voor databases regionale PD’s en pd-ssd/pd-extreme; valideer het fsync-gedrag en de ‘queue depths’. Vermijd lokale SSD voor duurzame staat, tenzij deze gerepliceerd is.

Toegang, Beveiliging, Netwerken en Gespecialiseerde Workloads

Linux- en Windows-beheer

Linux SSH: Geef de voorkeur aan OS Login om SSH-autorisatie te centraliseren en toegang toe te wijzen aan identiteiten. Wijs compute.osLogin of compute.osAdminLogin toe aan groepen, niet aan individuen.
Windows RDP: Stel Windows-inloggegevens in via de console of gcloud; zorg ervoor dat firewallregels TCP 3389 alleen toestaan vanaf vertrouwde IP’s. Gebruik IAP TCP forwarding om publieke blootstelling te vermijden.
Seriële console: Schakel in als ‘break-glass’-toegang; gebruik gcloud compute connect-to-serial-port voor het debuggen van het opstartproces. Beperk de toegang met IAM en voer audits uit.

SSH, OS Login en sleutelbeheer

Schakel OS Login in op project- of instance-niveau met de metadata enable-oslogin=TRUE. Gebruikers voegen hun publieke SSH-sleutel toe aan hun Google-account; IAM regelt de op rollen gebaseerde toegang.
Gebruik compute.osAdminLogin voor sudo/root-toegang. Schakel projectbrede SSH-sleutels uit als je OS Login gebruikt om ‘drift’ te voorkomen.

Metadata, opstartscripts en cloud-init

De metadataserver levert instance-/projectdata en service account tokens. Gebruik alleen tokens met een beperkte scope; hardcodeer nooit secrets.
Opstartscripts en cloud-init: Bootstrap agents, haal configuraties op en registreer services. Maak scripts idempotent en schrijf logs naar de seriële console voor diagnostiek.
Metadata per instance kan template-instellingen overschrijven; gebruik dit voorzichtig om configuratie-afwijkingen (‘skew’) te voorkomen.

Service accounts en scopes

Wijs een toegewijd service account toe per workload met IAM-rollen volgens het ’least-privilege’-principe op de benodigde resources (bijv. storage.objectCreator op een specifieke bucket).
Geef alleen de voorkeur aan brede Cloud API-scopes als IAM de toegang strikt controleert; beperk anders de scopes tot de minimaal benodigde API’s.

Netwerken en adressen

NIC’s kunnen alleen interne of ook externe IP’s hebben. Geef de voorkeur aan private VM’s met Cloud NAT of IAP voor uitgaand verkeer en beheerderstoegang.
Reserveer statische interne IP’s voor stabiele eindpunten zoals licentieservers; vermijd afhankelijkheid van efemere adressen.
Externe HTTP(S) Load Balancing beëindigt TLS aan de ’edge’; gebruik beheerde certificaten en health checks naar backend MIG’s. Houd de gereedheid van de backend afgestemd op de health check en de ‘initial delay’ van de MIG.

Gespecialiseerde workloads en isolatie

Shielded VMs: Secure boot, vTPM en integriteitsmonitoring beperken het risico op rootkits; schakel dit standaard in, tenzij incompatibele drivers anders vereisen.
Confidential VMs: Geheugenversleuteling met AMD SEV beschermt data-in-use; over het algemeen minimale prestatie-overhead, maar valideer dit voor latentiegevoelige applicaties.
Sole-tenant nodes: Toegewijde fysieke hosts voor compliance, isolatie van ’noisy-neighbors’ en licentie-affiniteit. Houd rekening met capaciteitsfragmentatie en hogere kosten.

Probleemoplossing en Hersteloperaties

Veelvoorkomende diagnostiek

Connectiviteit: Verifieer firewallregels, permissies van serviceaccounts en routes. Gebruik de connectiviteitstests van het Network Intelligence Center.
Opstartproblemen: Inspecteer de logs van de seriële console, maak een screenshot en controleer de output van het opstartscript. Schakel secure boot tijdelijk uit als niet-ondertekende drivers het opstarten blokkeren, en los het probleem daarna op.
Toegangsproblemen: Bevestig bij SSH-problemen met OS Login de IAM-rollen en dat er sleutels bestaan op de gebruikersaccounts; gebruik de seriële console om een gebruiker toe te voegen als noodoplossing (‘break-glass’).
Schijfcorruptie: Koppel de opstartschijf los, koppel deze aan een ‘rescue VM’, repareer de bestandssystemen, roteer de credentials en maak een image na het herstel.

Gedrag van MIG’s en load balancers

Overprovisioning: Als instances een lange opwarmtijd nodig hebben, verhoog dan de ‘initial delay’ van de MIG en de ‘cooldown’ van de autoscaler; anders kan er worden opgeschaald vanwege 4xx/5xx-fouten terwijl de applicatie nog aan het initialiseren is.
Autohealing-loops: Bevestig de semantiek van het health-eindpunt en de gereedheid van afhankelijkheden; spreid het opstarten van afhankelijkheden of voeg retries toe.

Herstelpatronen

Maak de instance opnieuw aan vanuit een template of image; onveranderlijke (‘immutable’) patronen verlagen de MTTR.
Herstel data vanaf de laatste succesvolle snapshot; valideer de RPO/RTO ten opzichte van de bedrijfsvereisten.
Bij regionale storingen, voer een failover uit naar een andere zone of regio met behulp van regionale MIG’s en cross-region snapshot-replicatie.

Operationele waarborgen

Reserveringen voor kritieke capaciteit; gebruik op monitoring gebaseerde alarmering voor het verbruik van reserveringen en quota.
Audit en logging: Schakel admin activity- en data access-logs in voor kritieke services. Wijs toegang toe via OS Login en serviceaccounts.

Korte voorbeelden

Een statisch intern IP-adres reserveren:

undefined

OS Login inschakelen op projectniveau:

undefined

Een HTTP-healthcheck aanmaken en koppelen aan een MIG met autohealing:

undefined

Praktijkscenario

Northwind Analytics draait een latency-gevoelige API op Compute Engine. Incidenten tonen frequente overprovisioning tijdens implementaties, af en toe verwarring over SSH-toegang onder beheerders, en een gelicentieerde telemetrieserver die bereikbaar moet blijven op 10.0.3.21. Het doel is om de schaalbaarheid te stabiliseren, de toegang te versterken (‘harden’) en ervoor te zorgen dat het licentie-eindpunt stabiel is.

Aanpak

Maak een instance template met een op maat gemaakt (‘right-sized’) custom machine type en startup bootstrapping

Rationale: Het template dwingt onveranderlijkheid (‘immutability’) af. Een custom vorm van 6 vCPU/20 GB RAM komt overeen met de gemeten P95 CPU en geheugen, terwijl overtollige cores die de licentiekosten verhogen, worden vermeden. Een opstartscript registreert de API bij de load balancer pas nadat de health checks slagen, wat de impact van het opwarmen vermindert.

Implementeer een regionale managed instance group achter een externe HTTP(S) Load Balancer

Rationale: Een regionale MIG spreidt instances over zones voor tolerantie tegen zone-uitval. De HTTP(S) load balancer beëindigt TLS aan de ’edge’ en voert per instance health checks uit, waardoor verkeer alleen naar gereedstaande backends wordt gestuurd.

Configureer autoscaling op basis van CPU met een ‘cooldown’ en autohealing met een realistische ‘initial delay’

Rationale: CPU is sterk gecorreleerd met de verzadiging van deze API. Een ‘cooldown’ van 90 seconden voorkomt ’thrashing’ bij tijdelijke pieken. Een ‘initial delay’ van 200 seconden sluit aan bij het opwarmen van de container en JIT, en voorkomt dat de autoscaler koude starts interpreteert als een capaciteitstekort.

Optimaliseer de health check en voeg een /healthz-eindpunt op applicatieniveau toe

Rationale: Een HTTP-healthcheck die afhankelijkheden valideert (cache, DB-connectiviteit) detecteert ‘gray failures’. Het gebruik van intervallen van 10 seconden en 3 ‘unhealthy thresholds’ balanceert de detectiesnelheid met het risico op valse positieven.

Schakel OS Login in en verleen beheerderstoegang aan een IAM-groep

Rationale: OS Login centraliseert SSH-autorisatie en -attributie. Beheerders voegen hun openbare SSH-sleutels toe aan hun Google-accounts; het toekennen van de rol compute.osAdminLogin aan de on-call groep geeft sudo-rechten terwijl de audittrails behouden blijven. Dit elimineert ‘key drift’ per VM.

Reserveer het statische interne IP-adres van de licentieserver en koppel het aan een kleine, dedicated VM

Rationale: Het reserveren van 10.0.3.21 garandeert dat het adres beschikbaar is en voorkomt onbedoeld hergebruik. Wijs het toe aan de NIC van de licentie-VM, zodat afhankelijke apps geen configuratiewijzigingen nodig hebben. Beperk de firewallregels tot alleen toegestane bronsubnetten.

Wijs een dedicated serviceaccount toe aan het API-template met ’least-privilege’ IAM-rechten

Rationale: Het ‘principle of least privilege’ verkleint de ‘blast radius’. Het serviceaccount krijgt alleen de benodigde rollen toegekend (bijv. leestoegang tot specifieke secrets en Pub/Sub-topics). Het gebruik van een template zorgt ervoor dat alle instances de juiste identiteit overnemen.

Versterk (‘harden’) instances met Shielded VM en handhaaf ‘break-glass’-toegang via de seriële console

Rationale: Secure Boot en integriteitsmonitoring beperken manipulatie van de kernel/bootloader. Beperk de toegang tot de seriële console met IAM en log de toegang voor audits; bewaar deze optie voor herstel als SSH faalt.

Implementeer snapshot-schema’s voor stateful schijven en test het herstelproces

Rationale: Hoewel de API stateless is, maak een snapshot-schema voor de licentieserver en eventuele configuratieschijven om aan de RPO te voldoen. Periodieke hersteltests valideren de tooling en de runbooks.

Valideer en implementeer

Rationale: Blue/green- of canary-updates met de ‘rolling update’-instellingen van de MIG verminderen het risico. Monitoring-dashboards bevestigen de stabilisatie van het aantal instances tijdens implementaties, verbeterde attributie van beheerderstoegang en de ononderbroken bereikbaarheid van 10.0.3.21.

← Hiërarchie van resources · Alle domeinen · Containers →

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