Google PCNE: Netwerkautomatisering, Governance en Kostenbeheer — Studiegids

By Laurynas Brazys · 22 August 2026 · #google #PCNE #certification #exam-prep #study-guide

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

Overzicht

Netwerkautomatisering, governance en kostenbeheer op Google Cloud zijn onlosmakelijk met elkaar verbonden disciplines die bepalen hoe betrouwbaar, veilig en economisch uw netwerken op schaal draaien. Effectieve praktijken combineren een goed gestructureerde resourcehiërarchie en IAM met minimale rechten (least-privilege) met ‘infrastructure as code’ en gebeurtenisgestuurde workflows, allemaal ondersteund door duidelijke budgetten, quota’s en auditeerbaarheid. De eindtoestand is voorspelbare provisioning, minimale handmatige wijzigingen, verdedigbaar bewijs voor compliance en transparante ‘unit economics’ voor netwerken.

Governance en Toegangsbeheer

Resourcehiërarchie
- Organization → Folders → Projects is het ‘control plane’ voor het overerven van permissies en beleidsmatige ‘guardrails’. Plaats productie en niet-productie in afzonderlijke folders om beleid en quota’s te isoleren. Gebruik labels op VPC’s, subnets, routers, forwarding rules en instances voor kostentoewijzing en het targeten van resources.
- Shared VPC consolideert routing en connectiviteit in een hostproject, terwijl compute wordt gedelegeerd aan serviceprojecten. Deel alleen de subnets die elk serviceproject nodig heeft om het principe van expliciete netwerkblootstelling te volgen en onbedoelde route-exposure te verminderen.
IAM en het principe van minimale rechten
- Scheid netwerkadministratie van security-administratie. Compute Network Admin geeft volledige controle over netwerkconstructies en alleen-lezen toegang tot firewallregels, terwijl Security Admin firewallregels en SSL-certificaten beheert. Deze scheiding voorkomt operators met te veel rechten en sluit aan bij ‘change control’.
- Wijs gerichte rollen toe:
  - Gebruik Security Admin op de Shared VPC om firewallregels aan te passen.
  - Voor het beheren van VLAN attachments en andere kernnetwerkresources is Compute Network Admin geschikt.
  - Verleen voor automatisering op specifieke resources permissies op resourceniveau in plaats van projectbrede rollen waar mogelijk, of maak een aangepaste rol die beperkt is tot de vereiste permissies.
- Geef de voorkeur aan ‘service account impersonation’ en kortlevende tokens boven persistente sleutels. Verbied het aanmaken van service-accountsleutels via organisatiebeleid waar mogelijk. Gebruik Workload Identity Federation om sleutels volledig te elimineren voor on-prem of multi-cloud automatisering.
- Volg het principe van minimale rechten voor ‘data plane’-taken. Een taak die bijvoorbeeld Cloud Storage leest, heeft alleen ‘storage object viewer’ nodig op de doelbucket, niet een brede ’editor’-rol op het project.
Organisatiebeleid
- Dwing standaard “geen extern IP” af voor VM’s; gebruik Private Google Access en Cloud NAT om Google API’s te bereiken zonder publieke adressen.
- Beperk peering en externe deling tot goedgekeurde patronen (beperk bijvoorbeeld VPC peering-configuraties om wildgroei te voorkomen).
- Beperk het aanmaken en gebruiken van service-accountsleutels om de wildgroei van credentials te beperken.
- Faalmodi en afwegingen:
  - Te breed overgeërfde rollen op folderniveau kunnen stilzwijgend schrijftoegang verlenen tot veel projecten. Controleer roltoewijzingen met een analyse van effectieve permissies.
  - Het blokkeren van externe IP’s voor VM’s zonder te plannen voor Private Google Access en NAT leidt tot storingen bij het aanroepen van Google-services.
  - Het converteren van een VPC van auto-modus naar custom-modus zonder templates te refactoren die uitgingen van auto-subnets, breekt implementaties; verwijs daarna expliciet naar custom subnets.

Automatisering, IaC en Gebeurtenisgestuurde Operaties

Infrastructure as Code met Terraform
- Gebruik een modulair ontwerp: één module per primitief (VPC, subnet, firewall, Cloud Router, Cloud NAT, interconnect attachment), en stel daaruit omgevingsstacks samen. Versioneer modules en pin versies in de consumerende stacks om rollouts te beheersen.
- Sla de state op afstand op met locking (bijvoorbeeld Cloud Storage met Dynamo-stijl locking via een back-end patroon) om gelijktijdige wijzigingen te voorkomen. Versleutel en back-up de state; behandel de state als gevoelige informatie.
- Drift management:
  - Dwing wijzigingen af via pull requests en terraform plan in CI om het verschil tussen beoogd en actueel te onthullen. Voer geplande driftdetectie uit (plan -detailed-exitcode) en verstuur alerts wanneer drift optreedt.
  - Vermijd ad-hoc gcloud-wijzigingen in productie; als noodreparaties nodig zijn, leg ze vast en breng ze onmiddellijk in overeenstemming met de code.
- Idempotentie en guardrails: Plan, review en pas altijd toe. Gebruik gerichte ‘applies’ om de ‘blast radius’ te minimaliseren. Gebruik variabelevalidatie en ‘policy-as-code’ (bijvoorbeeld Sentinel of OPA) om anti-patronen zoals overlappende CIDR’s of open firewalls te blokkeren.
gcloud, API’s en workflows
- Gebruik gcloud en REST voor operationele taken met lage latentie, maar verpak ze in herhaalbare scripts. Ga om met ’eventual consistency’ en API rate limits door middel van retries en ’exponential backoff’.
- Gebeurtenisgestuurde operaties:
  - Gebruik Cloud Scheduler + Pub/Sub + Cloud Run/Cloud Functions om routinetaken te automatiseren, zoals quotacontroles, audits van NAT-gebruik of het samplen van firewall-logging.
  - Stream Admin Activity- en Data Access-logs naar Pub/Sub om ‘guardrail’-workflows te triggeren (bijvoorbeeld het automatisch terugdraaien van een ongeautoriseerde wijziging van een firewallregel).
- Voorbeeld-snippets
  - Een rol toewijzen:

undefined

- Een route aanmaken voor Google API's om een standaardroute naar een NGFW te omzeilen:
  -

undefined

Operationele valkuilen
- ‘Race conditions’ wanneer meerdere pipelines gedeelde resources beheren (bijvoorbeeld firewalls in een gemeenschappelijke VPC) veroorzaken ‘flapping’. Gebruik conventies voor eigenaarschap en pipelines die op folderniveau zijn gescoped.
- Instabiliteit van de API onder hoge parallelliteit veroorzaakt quotafouten; ’throttle’ en batch operaties per regio en resourcetype.

Kosten, Quota en Capaciteitsbeheer

Quota en API-limieten
- Houd quota per project en per regio bij (adressen, doorstuurregels, firewallregels, interconnect-attachments, routers). Automatiseer quotamonitoring en vraag verhogingen aan voordat nieuwe omgevingen worden geïmplementeerd. Integreer preflight quotacontroles in CI om snel te falen.
- Provisioneer op schaal met:
  - Regionale sharding (maak resources per regio aan om conflicten met regionale quota te vermijden).
  - Pre-allocatie (reserveer adressen en configureer routers voorafgaand aan piekevenementen).
  - Gefaseerde rollouts (maak aan, valideer en koppel vervolgens backends).
Egress en topologie-economie
- Intra-VPC cross-region verkeer brengt inter-region egress-kosten met zich mee. Plaats communicerende workloads in dezelfde regio of repliceer data regionaal wanneer latency en kosten belangrijk zijn.
- Voor gebruikers in de buurt van us-east1 en europe-west1 maakt een enkele VPC met regionale subnets private RFC1918-communicatie mogelijk, waardoor NAT- en peering-overhead wordt geminimaliseerd en eenvoudig beleid en routering mogelijk zijn.
- Gebruik VPC Network Peering voor connectiviteit met lage overhead tussen projecten of afdelingen zonder NAT en zonder transitieve routering; houd CIDR’s niet-overlappend. Gebruik afzonderlijke VPC’s om afdelingen te isoleren die niet met elkaar mogen communiceren.
- Cloud CDN vermindert egress en verbetert de latency voor HTTP(S)-verkeer; een globale HTTP(S) load balancer is het control plane voor CDN. Een network load balancer zal de globale latency voor webapps niet verbeteren omdat deze geen edge-distributie en caching heeft.
- Kies interconnect verstandig: Dedicated Interconnect met VLAN-attachments in een hostproject centraliseert het beheer en verlaagt de kosten per project voor grote, gedeelde on-prem connectiviteit. Cloud VPN met Cloud Router is geschikt voor snelle, versleutelde connectiviteit tussen organisaties, met de mogelijkheid om later naar interconnect te evolueren.
Kostentoewijzing, budgetten en prognoses
- Tag alle netwerkresources met labels voor afdeling, omgeving en kostenplaats. Exporteer factureringsgegevens naar BigQuery en leid eenheidskosten af (bijvoorbeeld, $/GB egress per service).
- Maak budgetten aan op project-, folder- of labelniveau. Stuur alerts naar Pub/Sub en koppel deze aan ChatOps of Cloud Run responders. Automatiseer acties bij overschrijding (bijvoorbeeld, verminder de logging-sampling of schaal niet-kritieke testomgevingen af).
- Optimaliseer egress:
  - Geef de voorkeur aan Private Google Access en Cloud NAT in plaats van externe IP’s om egress-paden te beheren en de facturering te centraliseren.
  - Voeg voor forced-tunnel topologieën aangepaste routes voor Google API’s toe aan de default internet gateway of configureer Private Google Access voor on-prem om ‘hairpinning’ via firewalls van derden te voorkomen.
  - Voorspel capaciteit door VPC Flow Logs en load balancer-logs te analyseren; correleer dit met seizoensinvloeden. Zorg voor de juiste omvang van NAT-gateways en interconnect-capaciteit voorafgaand aan piekbelasting.

Auditability en Operational Excellence

Logging en bewijsvoering
- Cloud Audit Logs:
  - Admin Activity logs leggen wijzigingen in het control plane vast voor VPC’s, routes, firewalls, routers en load balancers; ze staan altijd aan. Bewaar ze centraal en stuur ze door naar een security-project met CMEK indien nodig.
  - Data Access logs voor netwerk-API’s kunnen een hoog volume hebben; schakel ze selectief in en pas sampling of sinks toe.
- VPC Flow Logs en Firewall Rules Logging leveren bewijs op data-plane-niveau voor incidentrespons en compliance. Sla op voor de vereiste bewaartermijn en indexeer met BigQuery voor onderzoek.
- Wijzigingsrecords: Vereis dat elke netwerkwijziging afkomstig is van IaC met een onveranderlijk plan-artefact en een ticketreferentie. Voor uitzonderlijke handmatige wijzigingen, leg het gcloud-commando, de operator, de timestamp en de rechtvaardiging vast in een centraal register.
Veilige credentials en risicobeheersing van automatisering
- Elimineer langlevende service account keys. Gebruik IAM Conditions om de scope van automatisering te beperken op basis van resource, tijd of IP. Beveilig risicovolle permissies (bijvoorbeeld compute.firewalls.update, compute.routers.updateBgpPeer) met goedkeuringsworkflows.
- Pas ’least privilege’ toe op CI/CD, gebruik service accounts per omgeving en roteer tokens frequent. Gebruik VPC Service Controls voor perimeterbeveiliging waar risico’s op data-exfiltratie bestaan.
Runbooks, levenscyclus en continue verbetering
- Onderhoud runbooks voor routineoperaties: een project onboarden naar Shared VPC, VPC-peering aanmaken, een Cloud VPN met IKEv2 opzetten, Cloud Armor-regels promoveren van preview naar ’enforce’.
- Definieer levenscyclusbeleid:
  - Sandbox → Staging → Productie-promotie met identieke Terraform-modules en regiospecifieke variabelen.
  - Decommissioning-playbooks om peering, NAT en routes veilig te verwijderen.
- Continue verbetering:
  - Post-incident reviews moeten teruggekoppeld worden naar modules (bijvoorbeeld het toevoegen van een ‘default deny egress’ met expliciete allowlists, of NAT-logging standaard inschakelen).
  - Review regelmatig organisatiebeleid, labels en budgetten op afwijkingen (‘drift’) van de beoogde staat.

Praktijkscenario

Contoso Retail is actief in Noord-Amerika en Europa. Gebruikers en services draaien voornamelijk in us-east1 en europe-west1. Security vereist een default route naar een NGFW van een derde partij, geen externe IP’s op VM’s en gecentraliseerde on-premise connectiviteit. Het bedrijf heeft ook duidelijke kostentoewijzing per afdeling en geautomatiseerde ‘guardrails’ nodig.

Governance en topologie opzetten

Maak een Shared VPC host-project aan met één enkele VPC en twee regionale subnets in us-east1 en europe-west1. Rationale: Eén VPC met regionale subnets maakt directe RFC1918-communicatie tussen regio’s mogelijk met eenvoudige routing en policies, wat de overhead per project minimaliseert.
Deel alleen de noodzakelijke subnets met drie service-projecten (Marketing, Supply, Finance). Rationale: Het delen op subnetniveau beperkt de blootstelling van routes en firewalls, terwijl de centrale controle behouden blijft.
Maak een aparte VPC voor een legacy Finance-systeem dat geïsoleerd moet worden; peer alleen Marketing en Supply waar nodig. Rationale: VPC-peering biedt private connectiviteit met lage latentie voor de twee afdelingen, terwijl de isolatie van Finance behouden blijft.

Veilige toegang tot Google-services configureren zonder publieke IP’s

Schakel Private Google Access in op alle gedeelde subnets. Rationale: Instanties zonder externe IP’s kunnen Google API’s privé bereiken.
Omdat de default route naar een NGFW gaat, voeg een custom static route voor 199.36.153.8/30 toe naar de default internet gateway. Rationale: Zorgt ervoor dat aanroepen naar Google API’s geen ‘hairpinning’ door de firewall veroorzaken, wat de latentie vermindert en een ‘single choke point’ vermijdt.

On-premise connectiviteit centraliseren

Implementeer Dedicated Interconnect en VLAN attachments in het Shared VPC host-project, gekoppeld aan een Cloud Router per regio. Rationale: Gecentraliseerde interconnect verlaagt de kosten en operationele duplicatie; Cloud Router biedt dynamische routing voor groei.
Ken Compute Network Admin toe aan netwerkoperators en Security Admin aan het securityteam. Rationale: Dwingt ’least privilege’ en scheiding van taken af; netwerkbeheerders kunnen geen firewalls wijzigen zonder goedkeuring van security.

Provisioning en ‘guardrails’ automatiseren

Implementeer Terraform-modules voor VPC, subnets, routers, NAT, peering en firewall-policies. Sla de state extern op met locking; dwing pull-request reviews af met ’terraform plan’ in CI. Rationale: Herhaalbare, geversioneerde wijzigingen met ‘drift control’ minimaliseren storingen.
Voeg een OPA-policy toe om overlappende CIDR’s en open 0.0.0.0/0 ingress naar interne subnets te blokkeren. Rationale: Voorkomt veelvoorkomende misconfiguraties tijdens de review.
Gebruik Cloud Scheduler om dagelijkse quotacontroles naar Pub/Sub te publiceren; een Cloud Run-service roept de Service Usage API aan om de beschikbare ruimte (‘headroom’) voor adressen, forwarding rules en interconnect attachments te verifiëren. Rationale: Voorkomt deploymentfouten als gevolg van het bereiken van quota.

Kosten optimaliseren en nauwkeurig toewijzen

Pas de labels env, dept en service toe op alle netwerkresources via Terraform. Exporteer facturering naar BigQuery en definieer budgetten per afdeling met alerts naar Pub/Sub. Rationale: Transparante kostentoewijzing en vroege waarschuwingen bij pieken maken proactief handelen mogelijk.
Plaats een globale HTTP(S) load balancer voor de publieke web-properties en schakel Cloud CDN in. Rationale: Verbetert de latentie voor wereldwijde gebruikers en vermindert egress door gecachte content vanaf de ’edge’ te serveren.

Auditability en incidentrespons versterken

Stuur Admin Activity en Firewall Rules Logging door naar een centraal logging-project met CMEK. Rationale: Manipulatiebestendige wijzigingsrecords en bewijs op data-plane-niveau voldoen aan de compliance-eisen.
Voor verdachte, misbruik makende clients, implementeer een Cloud Armor-regel in preview-modus op de HTTP(S) load balancer en review de logs alvorens deze af te dwingen. Rationale: Minimaliseert de verstoring voor gebruikers tijdens het valideren van de mitigatie.

Documenteren en itereren

Publiceer runbooks voor het onboarden van een project naar Shared VPC, het aanmaken van VPC-peering tussen Marketing en Supply, en het opzetten van een policy-based Cloud VPN voor partners die geen BGP hebben. Rationale: Gestandaardiseerde uitvoering verlaagt de MTTR en variantie.
Leg na elk ‘change window’ metrics vast (deploymenttijd, fouten, egress $/GB, cache hit ratio) en voer verbeteringen terug in de modules en policies. Rationale: Continue verbetering verankert betrouwbaarheid en kostenbeheersing in de dagelijkse operaties.

← Netwerkobservability · Alle domeinen

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