Google PCNE: Netzwerkautomatisierung, Governance und Kostenbetrieb — Lernleitfaden

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

Teil des Google Professional Cloud Network Engineer — Lernleitfaden. Üben Sie mit verifizierten Antworten im Google-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Überblick

Netzwerkautomatisierung, Governance und Kostenmanagement in Google Cloud sind untrennbare Disziplinen, die bestimmen, wie zuverlässig, sicher und wirtschaftlich Ihre Netzwerke im großen Maßstab betrieben werden. Eine effektive Praxis verbindet eine gut strukturierte Ressourcenhierarchie und IAM nach dem Prinzip der geringsten Rechte (Least Privilege) mit Infrastructure as Code und ereignisgesteuerten Workflows. All dies wird durch klare Budgets, Kontingente und Auditierbarkeit untermauert. Das Endergebnis sind eine vorhersagbare Bereitstellung, minimale manuelle Änderungen, belastbare Compliance-Nachweise und transparente Stückkosten für das Networking.

Governance und Zugriffskontrolle

Ressourcenhierarchie
- Organisation → Ordner → Projekte ist die Kontrollebene für die Rechtevererbung und für Richtlinien-Guardrails. Platzieren Sie Produktions- und Nicht-Produktionsumgebungen in separaten Ordnern, um Richtlinien und Kontingente zu isolieren. Verwenden Sie Labels für VPCs, Subnetze, Router, Weiterleitungsregeln und Instanzen zur Kostenzuordnung und für das Ressourcen-Targeting.
- Shared VPC konsolidiert Routing und Konnektivität in einem Host-Projekt und delegiert gleichzeitig die Compute-Ressourcen an Service-Projekte. Geben Sie nur die Subnetze frei, die jedes Service-Projekt benötigt, um dem Prinzip der expliziten Netzwerkfreigabe zu folgen und eine unbeabsichtigte Offenlegung von Routen zu reduzieren.
IAM und das Prinzip der geringsten Rechte (Least Privilege)
- Trennen Sie die Netzwerkadministration von der Sicherheitsadministration. Die Rolle Compute Network Admin gewährt volle Kontrolle über Netzwerk-Konstrukte und schreibgeschützten Zugriff auf Firewall-Regeln, während der Security Admin Firewall-Regeln und SSL-Zertifikate verwaltet. Diese Trennung vermeidet Operatoren mit zu weitreichenden Rechten und steht im Einklang mit dem Change Control.
- Vergeben Sie gezielte Rollen:
  - Um Firewall-Regeln zu ändern, verwenden Sie die Rolle Security Admin für die Shared VPC.
  - Um VLAN-Attachments und andere zentrale Netzwerkressourcen zu verwalten, ist die Rolle Compute Network Admin geeignet.
  - Für die Automatisierung, die auf bestimmte Ressourcen abzielt, vergeben Sie nach Möglichkeit Berechtigungen auf Ressourcenebene anstelle von projektweiten Rollen oder erstellen Sie eine benutzerdefinierte Rolle, die auf die erforderlichen Berechtigungen beschränkt ist.
- Bevorzugen Sie Service Account Impersonation und kurzlebige Token gegenüber dauerhaften Schlüsseln. Unterbinden Sie die Erstellung von Dienstkontoschlüsseln nach Möglichkeit über eine Organisationsrichtlinie. Nutzen Sie Workload Identity Federation, um bei der Automatisierung von On-Premises- oder Multi-Cloud-Umgebungen vollständig auf Schlüssel zu verzichten.
- Befolgen Sie das Prinzip des geringsten Rechtezugriffs (Least Privilege) für Aufgaben auf der Datenebene. Beispielsweise benötigt ein Job, der Daten aus Cloud Storage liest, nur die Rolle storage object viewer für den Ziel-Bucket und nicht die weitreichende Rolle editor für das gesamte Projekt.
Organisationsrichtlinien
- Erzwingen Sie standardmäßig „keine externe IP“ für VMs; verwenden Sie Private Google Access und Cloud NAT, um Google-APIs ohne öffentliche Adressen zu erreichen.
- Beschränken Sie Peering und externe Freigaben auf genehmigte Muster (z. B. schränken Sie VPC-Peering-Konfigurationen ein, um Wildwuchs zu vermeiden).
- Schränken Sie die Erstellung und Verwendung von Dienstkontoschlüsseln ein, um Credential Sprawl zu begrenzen.
- Fehlermodi und Kompromisse:
  - Zu weit gefasste, auf Ordnerebene geerbte Rollen können unbemerkt Schreibzugriff auf viele Projekte gewähren. Überprüfen Sie Rollenbindungen mit einer Analyse der effektiven Berechtigungen.
  - Das Blockieren externer IPs für VMs ohne eine Planung für Private Google Access und NAT führt zu Ausfällen bei Aufrufen von Google-Diensten.
  - Die Umstellung einer VPC vom Auto-Modus in den Custom-Modus ohne Anpassung von Vorlagen, die von automatisch erstellten Subnetzen ausgingen, führt zu fehlerhaften Deployments; referenzieren Sie danach explizit die benutzerdefinierten Subnetze.

Automatisierung, IaC und ereignisgesteuerter Betrieb

Infrastructure as Code mit Terraform
- Verwenden Sie einen modularen Aufbau: ein Modul pro Grundbaustein (VPC, Subnetz, Firewall, Cloud Router, Cloud NAT, Interconnect Attachment) und stellen Sie daraus Umgebungs-Stacks zusammen. Versionieren Sie die Module und pinnen Sie die Versionen in den konsumierenden Stacks fest, um Rollouts zu steuern.
- Speichern Sie den Zustand (State) remote mit einem Sperrmechanismus (z. B. in Cloud Storage mit einer Sperre im Dynamo-Stil über ein Backend-Pattern), um gleichzeitige Änderungen zu verhindern. Verschlüsseln und sichern Sie den Zustand; behandeln Sie den Zustand als sensibel.
- Drift-Management:
  - Setzen Sie Änderungen über Pull-Requests und terraform plan in der CI durch, um den Soll- vom Ist-Zustand abzugleichen. Führen Sie eine geplante Drift-Erkennung (plan -detailed-exitcode) durch und geben Sie Warnungen aus, wenn ein Drift auftritt.
  - Vermeiden Sie Ad-hoc-Änderungen mit gcloud in der Produktion; wenn Notfall-Korrekturen erforderlich sind, protokollieren Sie diese und gleichen Sie sie sofort im Code ab.
- Idempotenz und Guardrails: Immer planen, überprüfen und anwenden. Verwenden Sie gezielte Applies, um den Blast Radius zu minimieren. Nutzen Sie Variablenvalidierung und Policy-as-Code (z. B. Sentinel oder OPA), um Anti-Pattern wie überlappende CIDRs oder offene Firewalls zu blockieren.
gcloud, APIs und Workflows
- Verwenden Sie gcloud und REST für operative Aufgaben mit geringer Latenz, aber kapseln Sie diese in wiederholbare Skripte. Behandeln Sie Eventual Consistency und API-Ratenbegrenzungen mit Wiederholungsversuchen und exponentiellem Backoff.
- Ereignisgesteuerter Betrieb:
  - Nutzen Sie Cloud Scheduler + Pub/Sub + Cloud Run/Cloud Functions, um Routineaufgaben wie Kontingentprüfungen, Audits der NAT-Auslastung oder Stichproben des Firewall-Loggings zu automatisieren.
  - Streamen Sie Admin Activity- und Data Access-Logs nach Pub/Sub, um Guardrail-Workflows auszulösen (z. B. das automatische Zurücksetzen einer nicht autorisierten Änderung an einer Firewall-Regel).
- Beispiel-Snippets
  - Eine Rolle zuweisen:
    - gcloud projects add-iam-policy-binding PROJECT –member=user:alice@example.com –role=roles/compute.networkAdmin
  - Eine Route für Google-APIs erstellen, um eine Standardroute zu einer NGFW zu umgehen:
    - gcloud compute routes create google-apis-egress –network=NET –destination-range=199.36.153.8/30 –next-hop-gateway=default-internet-gateway –priority=800
Operative Fallstricke
- Race Conditions, wenn mehrere Pipelines gemeinsam genutzte Ressourcen (z. B. Firewalls in einer gemeinsamen VPC) verwalten, verursachen Flapping. Verwenden Sie Zuständigkeitskonventionen und ordnerbezogene Pipelines.
- Instabilität der API bei hoher Parallelität löst Kontingentfehler aus; drosseln und bündeln Sie Operationen nach Region und Ressourcentyp.

Kosten-, Kontingent- und Kapazitätsmanagement

Kontingente und API-Limits
- Verfolgen Sie die Kontingente pro Projekt und pro Region (Adressen, Weiterleitungsregeln, Firewall-Regeln, Interconnect-Anhänge, Router). Automatisieren Sie die Überwachung der Kontingente und beantragen Sie Erhöhungen, bevor neue Umgebungen bereitgestellt werden. Integrieren Sie Preflight-Kontingentprüfungen in die CI, um frühzeitig Fehler zu erkennen.
- Bereitstellung im großen Maßstab mit:
  - Regionalem Sharding (Ressourcen pro Region erstellen, um regionale Kontingentkonflikte zu vermeiden).
  - Vorab-Zuweisung (Adressen reservieren und Router vor Spitzenlast-Ereignissen einrichten).
  - Phasenweisen Rollouts (Backends erstellen, validieren und dann anhängen).
Egress- und Topologie-Wirtschaftlichkeit
- Regionenübergreifender Traffic innerhalb einer VPC verursacht Kosten für interregionalen Egress. Platzieren Sie kommunizierende Workloads in derselben Region oder replizieren Sie Daten regional, wenn Latenz und Kosten eine Rolle spielen.
- Für Benutzer in der Nähe von us-east1 und europe-west1 ermöglicht eine einzelne VPC mit regionalen Subnetzen private RFC1918-Kommunikation, was den Overhead für NAT und Peering minimiert und gleichzeitig einfache Richtlinien und Routing erlaubt.
- Verwenden Sie VPC Network Peering für Verbindungen mit geringem Overhead zwischen Projekten oder Abteilungen ohne NAT und ohne transitives Routing; halten Sie die CIDRs nicht überlappend. Nutzen Sie separate VPCs, um Abteilungen zu isolieren, die nicht miteinander kommunizieren dürfen.
- Cloud CDN reduziert den Egress und verbessert die Latenz für HTTP(S)-Traffic; ein globaler HTTP(S)-Load-Balancer ist die Steuerungsebene für das CDN. Ein Network Load Balancer verbessert die globale Latenz für Webanwendungen nicht, da ihm die Edge-Verteilung und das Caching fehlen.
- Wählen Sie Interconnect mit Bedacht: Dedicated Interconnect mit VLAN-Anhängen in einem Host-Projekt zentralisiert die Verwaltung und reduziert die Kosten pro Projekt für große, gemeinsam genutzte On-Prem-Konnektivität. Cloud VPN mit Cloud Router eignet sich für eine schnelle, verschlüsselte Verbindung zwischen Organisationen, die später zu einem Interconnect ausgebaut werden kann.
Kostenzuordnung, Budgets und Prognosen
- Versehen Sie alle Netzwerkressourcen mit Labels für Abteilung, Umgebung und Kostenstelle. Exportieren Sie Abrechnungsdaten nach BigQuery und leiten Sie Einheitskosten ab (z. B. $/GB Egress pro Dienst).
- Erstellen Sie Budgets auf Projekt-, Ordner- oder Label-Ebene. Senden Sie Benachrichtigungen an Pub/Sub und verknüpfen Sie diese mit ChatOps- oder Cloud Run-Respondern. Automatisieren Sie Aktionen bei Überschreitungen (z. B. Reduzierung des Logging-Samplings oder Herunterskalieren nicht kritischer Testumgebungen).
- Egress optimieren:
  - Bevorzugen Sie Private Google Access und Cloud NAT anstelle von externen IPs, um Egress-Pfade zu kontrollieren und die Abrechnung zu zentralisieren.
  - Fügen Sie bei Forced-Tunnel-Topologien benutzerdefinierte Routen für Google-APIs zum Standard-Internet-Gateway hinzu oder konfigurieren Sie Private Google Access für On-Prem, um Hairpinning durch Firewalls von Drittanbietern zu vermeiden.
  - Prognostizieren Sie die Kapazität durch Analyse von VPC Flow Logs und Load-Balancer-Logs; korrelieren Sie die Daten mit der Saisonalität. Dimensionieren Sie NAT-Gateways und Interconnect-Kapazitäten im Vorfeld von Spitzenlastzeiten richtig.

Auditierbarkeit und Operationale Exzellenz

Protokollierung und Nachweise
- Cloud Audit Logs:
  - Admin Activity Logs erfassen Änderungen an der Steuerungsebene von VPCs, Routen, Firewalls, Routern und Load Balancern; sie sind immer aktiviert. Speichern Sie sie zentral und leiten Sie sie bei Bedarf an ein Sicherheitsprojekt mit CMEK weiter.
  - Data Access Logs für Netzwerk-APIs können ein hohes Volumen aufweisen; aktivieren Sie sie selektiv und wenden Sie Sampling oder Sinks an.
- VPC Flow Logs und Firewall Rules Logging liefern Nachweise auf der Datenebene für Incident Response und Compliance. Speichern Sie diese für die erforderliche Aufbewahrungsfrist und indizieren Sie sie mit BigQuery für Untersuchungen.
- Änderungsaufzeichnungen: Fordern Sie, dass jede Netzwerkänderung aus IaC mit einem unveränderlichen Plan-Artefakt und einer Ticket-Referenz stammt. Erfassen Sie bei ausnahmsweisen manuellen Änderungen den gcloud-Befehl, den Operator, den Zeitstempel und die Begründung in einem zentralen Register.
Sichere Anmeldedaten und Risikokontrolle bei der Automatisierung
- Eliminieren Sie langlebige Service-Account-Schlüssel. Verwenden Sie IAM Conditions, um die Automatisierung nach Ressource, Zeit oder IP-Adresse einzuschränken. Sichern Sie hochriskante Berechtigungen (z. B. compute.firewalls.update, compute.routers.updateBgpPeer) mit Genehmigungsworkflows ab.
- Wenden Sie das Prinzip der geringsten Rechte (Least Privilege) auf CI/CD an, verwenden Sie Service-Accounts pro Umgebung und rotieren Sie Tokens regelmäßig. Nutzen Sie VPC Service Controls zum Schutz des Service-Perimeters, wo Risiken der Datenexfiltration bestehen.
Runbooks, Lebenszyklus und kontinuierliche Verbesserung
- Pflegen Sie Runbooks für Routinevorgänge: Onboarding eines Projekts in eine Shared VPC, Erstellen eines VPC-Peerings, Einrichten eines Cloud VPN mit IKEv2, Heraufstufen von Cloud Armor-Regeln von der Vorschau zur Erzwingung.
- Definieren Sie Lebenszyklus-Richtlinien:
  - Heraufstufung von Sandbox → Staging → Produktion mit identischen Terraform-Modulen und regionalspezifischen Variablen.
  - Playbooks zur Stilllegung, um Peering, NAT und Routen sicher zu entfernen.
- Kontinuierliche Verbesserung:
  - Post-Incident-Reviews sollten in die Module zurückfließen (z. B. Hinzufügen eines standardmäßigen „Deny Egress“ mit expliziten Allow-Listen oder standardmäßige NAT-Protokollierung).
  - Überprüfen Sie regelmäßig Organisationsrichtlinien, Labels und Budgets auf Abweichungen von der Soll-Haltung.

Praktisches Problemszenario

Contoso Retail ist in Nordamerika und Europa tätig. Benutzer und Dienste laufen hauptsächlich in us-east1 und europe-west1. Die Sicherheitsabteilung fordert eine Standardroute zu einer Drittanbieter-NGFW, keine externen IPs auf VMs und eine zentralisierte On-Prem-Konnektivität. Das Unternehmen benötigt außerdem eine klare Kostenzuordnung nach Abteilung und automatisierte Guardrails.

Governance und Topologie festlegen

Erstellen Sie ein Shared VPC-Host-Projekt mit einer einzigen VPC und zwei regionalen Subnetzen in us-east1 und europe-west1. Begründung: Eine VPC mit regionalen Subnetzen ermöglicht direkte RFC1918-Kommunikation zwischen den Regionen mit einfachem Routing und Richtlinien, was den Overhead pro Projekt minimiert.
Geben Sie nur die notwendigen Subnetze für drei Dienstprojekte (Marketing, Supply, Finance) frei. Begründung: Die Freigabe auf Subnetz-Ebene begrenzt die Exposition von Routen und Firewalls und bewahrt gleichzeitig die zentrale Kontrolle.
Erstellen Sie eine separate VPC für ein veraltetes Finanzsystem, das isoliert werden muss; verbinden Sie nur Marketing und Supply bei Bedarf per Peering. Begründung: VPC-Peering bietet private Konnektivität mit geringer Latenz für die beiden Abteilungen und bewahrt gleichzeitig die Isolation von der Finanzabteilung.

Sicheren Zugriff auf Google-Dienste ohne öffentliche IPs konfigurieren

Aktivieren Sie den privaten Google-Zugriff (Private Google Access) auf allen freigegebenen Subnetzen. Begründung: Instanzen ohne externe IPs können Google-APIs privat erreichen.
Da die Standardroute zu einer NGFW führt, fügen Sie eine benutzerdefinierte statische Route für 199.36.153.8/30 zum Standard-Internet-Gateway hinzu. Begründung: Stellt sicher, dass Aufrufe an Google-APIs kein Hairpinning durch die Firewall machen, was die Latenz reduziert und einen einzelnen Engpass vermeidet.

On-Prem-Konnektivität zentralisieren

Stellen Sie Dedicated Interconnect und VLAN-Anhänge im Shared VPC-Host-Projekt bereit und verbinden Sie diese mit einem Cloud Router pro Region. Begründung: Zentralisierte Interconnect-Verbindungen reduzieren Kosten und operative Doppelarbeit; Cloud Router bietet dynamisches Routing für zukünftiges Wachstum.
Weisen Sie den Netzwerkoperatoren die Rolle „Compute Network Admin“ und dem Sicherheitsteam die Rolle „Security Admin“ zu. Begründung: Erzwingt das Prinzip der geringsten Rechte und die Funktionstrennung; Netzwerkadministratoren können Firewalls nicht ohne Genehmigung der Sicherheitsabteilung ändern.

Bereitstellung und Guardrails automatisieren

Implementieren Sie Terraform-Module für VPC, Subnetze, Router, NAT, Peering und Firewall-Richtlinien. Speichern Sie den State remote mit Sperrung; erzwingen Sie Pull-Request-Reviews mit terraform plan in der CI. Begründung: Wiederholbare, versionierte Änderungen mit Drift-Kontrolle minimieren Ausfälle.
Fügen Sie eine OPA-Richtlinie hinzu, um überlappende CIDRs und offenen 0.0.0.0/0-Ingress-Traffic zu internen Subnetzen zu blockieren. Begründung: Verhindert häufige Fehlkonfigurationen zum Zeitpunkt des Reviews.
Verwenden Sie Cloud Scheduler, um tägliche Kontingentprüfungen in Pub/Sub zu veröffentlichen; ein Cloud Run-Dienst ruft die Service Usage API auf, um den Spielraum für Adressen, Weiterleitungsregeln und Interconnect-Anhänge zu überprüfen. Begründung: Vermeidet Bereitstellungsfehler aufgrund der Erschöpfung von Kontingenten.

Kosten optimieren und genau zuordnen

Wenden Sie die Labels env, dept und service über Terraform auf alle Netzwerkressourcen an. Exportieren Sie die Abrechnungsdaten nach BigQuery und definieren Sie Budgets pro Abteilung mit Benachrichtigungen an Pub/Sub. Begründung: Transparente Kostenzuordnung und frühzeitige Warnungen bei Spitzen ermöglichen proaktives Handeln.
Schalten Sie den öffentlichen Web-Properties einen globalen HTTP(S)-Load-Balancer vor und aktivieren Sie Cloud CDN. Begründung: Verbessert die Latenz für globale Benutzer und reduziert den Egress-Traffic, indem zwischengespeicherte Inhalte am Edge bereitgestellt werden.

Auditierbarkeit und Incident Response stärken

Leiten Sie Admin Activity und Firewall Rules Logging an ein zentrales Logging-Projekt mit CMEK weiter. Begründung: Manipulationssichere Änderungsaufzeichnungen und Nachweise auf Datenebene erfüllen die Compliance-Anforderungen.
Setzen Sie bei Verdacht auf missbräuchliche Clients eine Cloud Armor-Regel im Vorschaumodus auf dem HTTP(S)-Load-Balancer ein und überprüfen Sie die Protokolle, bevor Sie die Regel erzwingen. Begründung: Minimiert die Beeinträchtigung für Benutzer während der Validierung der Gegenmaßnahme.

Dokumentieren und iterieren

Veröffentlichen Sie Runbooks für das Onboarding eines Projekts in eine Shared VPC, das Erstellen eines VPC-Peerings zwischen Marketing und Supply und den Aufbau eines richtlinienbasierten Cloud VPN für Partner ohne BGP. Begründung: Standardisierte Ausführung reduziert MTTR und Abweichungen.
Erfassen Sie nach jedem Änderungsfenster Metriken (Bereitstellungszeit, Fehler, Egress $/GB, Cache-Hit-Ratio) und lassen Sie Verbesserungen in Module und Richtlinien zurückfließen. Begründung: Kontinuierliche Verbesserung verankert Zuverlässigkeit und Kostenkontrolle im täglichen Betrieb.

← Netzwerk-Observability · Alle Domänen

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →