Google PCD: Kosten, Governance und nachhaltiger Anwendungsbetrieb — Lernleitfaden

By Laurynas Brazys · 3 September 2026 · #google #PCD #certification #exam-prep #study-guide

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

Überblick

Kosten, Governance und nachhaltiger Betrieb sind bei der modernen Anwendungsentwicklung in Google Cloud untrennbar miteinander verbunden. Das Ziel ist es, Ausgaben transparent zu machen und zu kontrollieren, Dienste zu entwerfen, die wirtschaftlich skalieren, und Leitplanken (Guardrails) durchzusetzen, die Umgebungen sicher, konform und sauber halten – während gleichzeitig Leistung und Zuverlässigkeit im Gleichgewicht bleiben. Dieser Abschnitt beschreibt praktische Mechanismen (Abrechnung und Labels, Autoscaling-Parameter, Kontingente und Richtlinien), die Wirtschaftlichkeit spezifischer Workloads (Cloud Run, GKE, Datenplattformen) und nachhaltigkeitsbewusste Entscheidungen, die ungenutzte Ressourcen und den CO2-Fußabdruck reduzieren, ohne die Benutzererfahrung zu beeinträchtigen.

Kostenkontrolle und Transparenz

• Abrechnungskonten, Labels, Kostenzuordnung, Budgets, Benachrichtigungen und Transparenz
  • Verwenden Sie ein dediziertes Abrechnungskonto pro Geschäftseinheit oder Finanzierungsquelle, um die Zuständigkeit zu isolieren und granulare Berechtigungen zu ermöglichen. Exportieren Sie Abrechnungsdaten nach BigQuery für detaillierte Analysen, Prognosen und die interne Weiterverrechnung (Chargeback).
  • Labels sind Schlüssel-Wert-Paare für Ressourcen zur Kostenzuordnung. Standardisieren Sie Label-Schlüssel (team, app, env, cost-center) und setzen Sie deren Verwendung durch Organisationsrichtlinien und CI-Prüfungen durch. Hinweis: Labels wirken nicht rückwirkend; nicht gekennzeichnete Ressourcen verzerren die Berichte.
  • Verwenden Sie Budgets und Benachrichtigungen auf Ebene des Abrechnungskontos und des Projekts. Kombinieren Sie Schwellenwerte (z. B. 50, 90, 100 Prozent) mit prognosebasierten Auslösern. Leiten Sie Budget-Benachrichtigungen an Pub/Sub weiter und von dort an Chat/Ops-Tools. Budgets benachrichtigen; sie setzen keine Limits durch.
  • Für gemeinsam genutzte Plattformen (z. B. GKE, BigQuery) verwenden Sie Labels pro Namespace oder pro Job und fügen Sie diese den Logs und Nutzungsdaten hinzu, um eine Kostendarstellung (Showback) oder Weiterverrechnung (Chargeback) zu ermöglichen.

Beispiel: Labels hinzufügen gcloud compute instances update web-01 –labels=team=payments,app=checkout,env=prod

• Kontingente, Limits, Verbrauchsprognosen und Kapazitäts-Governance
  • Kontingente schützen Dienste und begrenzen unkontrollierte Kosten. Überprüfen Sie Dienstkontingente regelmäßig, passen Sie sie pro Projekt an (Right-Sizing) und beantragen Sie Erhöhungen rechtzeitig vor Produkteinführungen. Implementieren Sie Pre-Deploy-Prüfungen, die die erwartete Spitzenauslastung mit den Kontingenten vergleichen.
  • Prognostizieren Sie Ausgaben mithilfe des Abrechnungsexports und der Produktnutzungs-Telemetrie (Cloud Monitoring-Metriken, logbasierte Metriken). Modellieren Sie Szenarien (erwartete QPS, gescannte Datenmenge) und validieren Sie diese in der Vorproduktionsumgebung.
  • Fehlerszenarien: Das Erreichen eines Kontingents während eines Störfalls oder einer Produkteinführung führt zu Drosselung (Throttling, 429/403), teilweisen Ausfällen oder einer stillen Verschlechterung der Leistung. Überdimensionierte Kontingente erhöhen den potenziellen Schaden (Blast Radius) durch fehlerhafte Jobs.

Beispiel: Compute Engine-Kontingente auflisten gcloud services quota list
–service=compute.googleapis.com
–consumer=projects/$PROJECT_ID

Elastizität und Wirtschaftlichkeit von Compute-Ressourcen

• Passende Dimensionierung (Right-Sizing), Autoscaling, anfragebasierte Abrechnung, zugesicherte Nutzung und Spot-Kapazität

  • Passende Dimensionierung von vCPU und Arbeitsspeicher mithilfe von Cloud Monitoring und Recommender-Erkenntnissen; Validierung durch Lasttests. Unterdimensionierung verursacht Latenzspitzen und OOM/CPU-Drosselung; Überdimensionierung führt zu unnötigen Kosten.
  • Autoscaling wandelt Capex-ähnliche Überprovisionierung in elastische Opex um. Verwenden Sie HPA/VPA für GKE und anfragebasiertes Autoscaling für Serverless (Cloud Run), um die Kapazität an den Bedarf anzupassen.
  • Die anfragebasierte Abrechnung (Cloud Run, Cloud Functions, GKE Autopilot) richtet die Kosten an der Nutzung aus und reduziert den Leerlauf. Achten Sie auf den Overhead pro Anfrage und auf Kaltstarts; passen Sie gegebenenfalls die Mindestanzahl an Instanzen an.
  • Zugesicherte Nutzung (Committed Use) ist für die Grundlast im stationären Zustand gedacht. Verwenden Sie ressourcenbasierte CUDs für Compute Engine und flexible CUDs für berechtigte verwaltete/serverless Produkte. Binden Sie sich nicht übermäßig für volatile Workloads.
  • Spot-Kapazität reduziert die Compute-Kosten für unterbrechbare, fehlertolerante Jobs. Implementieren Sie immer Handler für eine ordnungsgemäße Beendigung (graceful termination); sorgen Sie für Redundanz und schnelles Checkpointing. Rechnen Sie jederzeit mit einer kurzfristig angekündigten Beendigung.

• Cloud Run: Kompromisse bei Concurrency und Mindestanzahl an Instanzen

  • Concurrency (Gleichzeitigkeit) steuert, wie viele Anfragen eine einzelne Instanz gleichzeitig bedienen kann.
    • Eine höhere Concurrency verbessert die Auslastung und Kosteneffizienz, kann aber die Tail-Latenz aufgrund von Head-of-Line-Blocking innerhalb des Containers erhöhen.
    • Eine Concurrency von 1 isoliert Anfragen (nützlich für CPU-gebundenen oder nicht threadsicheren Code), erhöht aber oft die Anzahl der Instanzen und die Kosten.
  • Eine Mindestanzahl an Instanzen reduziert Kaltstarts und glättet die Latenz auf Kosten von fixen Grundkosten. Nur verwenden, wenn SLOs dies erfordern, und den Mindestwert anhand von Bedarfsmustern validieren.

Beispiel: Cloud Run-Konfiguration (service.yaml) apiVersion: serving.knative.dev/v1 kind: Service metadata: name: img-api annotations: autoscaling.knative.dev/minScale: “2” spec: template: spec: containerConcurrency: 40 containers: - image: gcr.io/PROJECT/img-api resources: limits: memory: “512Mi”

• GKE: Ressourcen-Requests und -Limits, Verhalten des Cluster Autoscalers und Bereinigung von Leerlaufressourcen
  • Requests bestimmen die Zuweisung (Scheduling); Limits begrenzen die Spitzennutzung. Setzen Sie Requests nahe am beobachteten, konstanten Bedarf und Limits leicht darüber, um kurzzeitige Lastspitzen zu ermöglichen. Zu niedrige Limits verursachen CPU-Drosselung; zu niedrige Arbeitsspeicher-Limits führen zu OOMKilled. Requests, die weit über dem realen Bedarf liegen, binden ungenutzte Kapazität und blockieren das Scheduling.
  • Der Cluster Autoscaler skaliert Knotenpools basierend auf nicht zuweisbaren (unschedulable) Pods (unzureichende aggregierte Requests). Er berücksichtigt PodDisruptionBudgets und kann bestimmte Pods nicht verdrängen (evict), z. B. solche mit lokalem Speicher oder restriktiven PDBs, was das Herunterskalieren verhindern kann. DaemonSets und Node-Taints/Affinities können die Skalierungseffizienz ebenfalls beeinträchtigen.
  • Der Horizontal Pod Autoscaler koppelt die Skalierung an CPU/Arbeitsspeicher oder benutzerdefinierte Metriken; der Vertical Pod Autoscaler passt die Größe der Requests im Laufe der Zeit an (Right-Sizing). Koordinieren Sie HPA und VPA, um Oszillationen zu vermeiden; verwenden Sie VPA je nach Anforderung im Empfehlungs- (recommend) oder Automatikmodus (auto).
  • Bereinigung von Leerlaufressourcen: Löschen Sie ungenutzte Load Balancer, Persistent Disks, Snapshots und statische IPs. Nutzen Sie Active Assist-Empfehlungen und automatisierte „Janitor“-Skripte, um ungenutzte Ressourcen zu erkennen und zu entfernen.

Beispiel: GKE-Deployment mit Requests/Limits apiVersion: apps/v1 kind: Deployment metadata: name: api spec: replicas: 3 template: spec: containers: - name: api image: gcr.io/PROJECT/api:stable resources: requests: cpu: “500m” memory: “512Mi” limits: cpu: “1” memory: “768Mi”

Kosten-Governance für Daten, Analysen und Netzwerk

• Speicherklassen, Lebenszykluskontrollen, Datenbank-Skalierung und Design des Netzwerk-Egress
  • Wählen Sie Cloud Storage-Klassen nach Zugriffsmuster: Standard für „heiße“ Daten; Nearline, Coldline oder Archive für „kältere“ Daten. Beachten Sie die Mindestgebühren für Abruf und vorzeitiges Löschen bei den kälteren Stufen.
  • Lebenszyklusregeln automatisieren Übergänge und Löschungen. Verwenden Sie Dual-Region für Ausfallsicherheit, wo Multi-Region-Latenz akzeptabel ist; platzieren Sie Compute und Daten am selben Ort (Co-Location), um Egress und Latenz zu reduzieren.
  • Datenbank-Skalierung:
    • Cloud SQL: vorsichtig vertikal skalieren; Lesereplikas für Lesezugriffe; automatische Speicherskalierung; Abfragepläne und Connection Pooling verwenden. Hoher Schreibdurchsatz kann Sharding oder einen Wechsel zu Spanner/Bigtable erfordern.
    • Spanner: horizontale Skalierung durch Hinzufügen von Knoten; Multi-Region-Konfigurationen für Verfügbarkeit und globale Lesezugriffe; Schemata und Schlüssel für eine ausgewogene Lastverteilung entwerfen.
    • Bigtable: Zeilenschlüssel so entwerfen, dass Hotspots vermieden werden; Cluster-Knoten und Speicher getrennt voneinander skalieren.
  • Netzwerk-Egress: Regionsübergreifenden Datenverkehr vermeiden; Clients und Daten nach Möglichkeit in derselben Region platzieren. Verwenden Sie Cloud CDN für Inhalte im Internetmaßstab, Cloud Interconnect/Peering für hybride Umgebungen und Private Google Access oder Private Service Connect für den privaten Zugriff auf Google-APIs. Unnötiger zonen- oder regionsübergreifender Datenverkehr erhöht Kosten und Latenz.

Beispiel: Cloud Storage-Lebenszyklus cat > policy.json « ‘EOF’ { “rule”: [ { “action”: {“type”: “SetStorageClass”, “storageClass”: “COLDLINE”}, “condition”: {“age”: 30} }, { “action”: {“type”: “Delete”}, “condition”: {“age”: 365} } ] } EOF gsutil lifecycle set policy.json gs://my-bucket

• BigQuery-Abfragekontrollen, Datenaufbewahrung und Kosten für die Analyse-Nutzung
  • Gescannte Bytes kontrollieren: immer nach Partitions-/Cluster-Schlüsseln filtern; SELECT * vermeiden; materialisierte Ansichten und Ergebnis-Caching für wiederholte Abfragen nutzen; wenn möglich, approximative Aggregationen verwenden.
  • Scan-Kosten durch maximum bytes billed begrenzen und die Job-Priorität für nicht dringende Aufgaben auf batch setzen, um Interferenzen und Kosten zu reduzieren.
  • Preismodell wählen: On-Demand für sporadische Workloads; Reservierungen (Slots) mit Commitments für gleichmäßige, hochvolumige Workloads. Verwenden Sie separate Reservierungen und Zuweisungen, um Teams zu isolieren.
  • Datenaufbewahrung: Ablaufdatum für Datasets/Tabellen und Partitionen zur Governance festlegen; Tiered Storage implementieren oder für die Archivierung exportieren.
  • Fehlermodi: Nicht partitionierte große Tabellen lassen die Kosten explodieren; Abfragen ohne Partitionsfilter scannen ganze Tabellen; zu aggressive Ablaufzeiten löschen benötigte Daten; übermäßige Slot-Konkurrenz verschlechtert das SLA.

Beispiel: Abfragekosten begrenzen bq query –use_legacy_sql=false –maximum_bytes_billed=1000000000
‘SELECT user_id, COUNT(*) FROM proj.ds.events WHERE _PARTITIONDATE >= DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY) GROUP BY user_id’

Governance auf Organisationsebene und Umgebungs-Hygiene

• Organisationsrichtlinien, Ressourcenbenennung, Tagging und Projekttrennung

  • Verwenden Sie Organisationsrichtlinien, um Leitplanken durchzusetzen: Schränken Sie Ressourcenstandorte ein, verbieten Sie externe IPs, fordern Sie CMEK, beschränken Sie erlaubte Dienste, kontrollieren Sie VPC-Peering und schreiben Sie bei Bedarf OS Login vor. Wenden Sie diese auf Organisations- oder Ordnerebene an, wobei Ausnahmen über die Hierarchie modelliert werden.
  • Standardisieren Sie die Ressourcenbenennung, um Umgebung, Projekt, App und Region zu kodieren (z. B. app-env-region-suffix). Setzen Sie dies durch CI-Prüfungen oder Policy-as-Code um.
  • Unterscheiden Sie:
    • Labels: Zuordnung für Abrechnung/Betrieb.
    • Tags (First-Class): An Ressourcen anhängen und in IAM Conditions und für das Targeting von Organisationsrichtlinien verwenden.
    • Network tags: Für Firewall-Regeln auf Compute Engine.
  • Projekttrennung: Isolieren Sie Umgebungen (Prod, Staging, Dev) und sensible Workloads. Verwenden Sie Shared VPC für zentralisiertes Networking und Service-Projekte mit geringsten Rechten (Least Privilege). Dies reduziert den Auswirkungsradius und vereinfacht IAM.

• Lebenszyklus von Umgebungen, kurzlebige Testumgebungen und Bereinigungsautomatisierung

  • Stellen Sie Umgebungen über IaC (Terraform) bereit und aktivieren Sie kurzlebige Umgebungen pro Pull-Request. Setzen Sie TTL-Labels und einen automatischen Abbau nach dem Merge oder bei Inaktivität.
  • Nutzen Sie Cloud Scheduler zusammen mit Cloud Run-Jobs oder Functions, um nach veralteten Ressourcen anhand von Label/Alter zu suchen und diese zu löschen. Exportieren Sie das Inventar über Cloud Asset Inventory, um Audits zu steuern.
  • Fehlermodi: Verwaiste Sandboxes verursachen Kosten; fehlende TTLs oder Labels verhindern die Bereinigung; eine übermäßig aggressive Bereinigung kann aktive Ressourcen löschen – fügen Sie Allow-Listen und Schonfristen hinzu.

• Nachhaltigkeitsbewusste Architektur und Abwägung von Kosten, Leistung und Zuverlässigkeit

  • Bevorzugen Sie verwaltete und serverlose Dienste, um Leerlauf zu reduzieren und die Ressourcenauslastung zu verbessern.
  • Wählen Sie, wenn konform, Regionen mit geringerer Kohlenstoffintensität; planen Sie Batch-Workloads nach Möglichkeit in Zeiträumen mit höherem Anteil an kohlenstofffreier Energie.
  • Optimieren Sie Data Gravity und Caching, um den Energieverbrauch des Netzwerks zu senken. Passen Sie Autoscaling und Concurrency an, um die Unterauslastung zu verringern. Nutzen Sie Profiling, um verschwenderische Codepfade zu entfernen, die übermäßige Rechenleistung oder I/O verursachen.
  • Abwägung: Fügen Sie Mindestinstanzen oder Replikate nur dort hinzu, wo SLOs dies erfordern; bewerten Sie Tail-Latenz vs. Concurrency und Redundanz vs. Spot-Nutzung. Validieren Sie dies mit SLO-basierten Lasttests und Kosten-Performance-Modellierung.

Praktisches Problemszenario

NimbusMarket, ein E-Commerce-Unternehmen, verzeichnet Traffic-Spitzen während Flash-Sales und steigende Ausgaben für Analysen. Die Kunden-APIs laufen auf Cloud Run, Hintergrund-Worker auf GKE und die Produktanalysen in BigQuery. Die Geschäftsführung fordert eine Kostenreduzierung von 25 Prozent, ohne das 99,9-prozentige API-SLO zu gefährden.

Vorgehensweise:

1. Kostentransparenz und Leitplanken schaffen

   • Erstellen Sie Budgets mit Prognose-Benachrichtigungen bei 60, 90 und 100 Prozent für das Rechnungskonto, mit Pub/Sub-Benachrichtigungen, die an das Bereitschaftsteam weitergeleitet werden.
   • Standardisieren Sie Labels (team, app, env, cost-center) und setzen Sie diese über CI bei Terraform-Plänen durch; fügen Sie eine Organisationsrichtlinie hinzu, die Ressourcenstandorte auf genehmigte Regionen beschränkt. Begründung: Budgets bieten eine Frühwarnung; Labels ermöglichen team-spezifische Berichte; Richtlinien verhindern versehentlich gewählte Regionen mit hohem Egress-Traffic und verbessern die Compliance.

2. Cloud Run für wirtschaftliche Skalierung optimieren

   • Setzen Sie containerConcurrency auf 40 für die zustandslose API, nachdem Profiling eine durchschnittliche CPU-Zeit von 30 ms und nicht-blockierendes I/O bestätigt hat. Konfigurieren Sie minScale=2, um Kaltstarts während der normalen Geschäftszeiten zu vermeiden; richten Sie eine zeitgesteuerte Richtlinie ein, um minScale über Nacht auf 0 zu senken. Begründung: Eine höhere Concurrency verbessert die Auslastung und reduziert die Anzahl der Instanzen; eine minimale Anzahl konstanter Instanzen sichert die SLOs bei begrenzten Grundkosten, die außerhalb der Geschäftszeiten entfallen.

3. GKE-Workloads richtig dimensionieren und effizientes Autoscaling aktivieren

   • Wenden Sie basierend auf Profiling Requests von 500m CPU/512Mi und Limits von 1 CPU/768Mi auf die Worker-Pods an. Aktivieren Sie HPA basierend auf Warteschlangentiefe und Verarbeitungslatenz sowie VPA im Empfehlungsmodus, um die Requests iterativ zu verfeinern. Überprüfen Sie, ob PodDisruptionBudgets das Herunterskalieren erlauben. Aktivieren Sie den Cluster Autoscaler für den Pool mit mehreren kleineren Knoten. Begründung: Genaue Requests steuern effektives Scheduling und Autoscaling; HPA passt die Kapazität an den Rückstand an; VPA vermeidet Abweichungen (Drift); mehrere kleine Knoten reduzieren gestrandete Kapazität und beschleunigen Skalierungsereignisse.

4. Spot-Kapazität für fehlertolerante Batch-Verarbeitung nutzen

   • Verlagern Sie die Erstellung von Bild-Thumbnails auf einen durch Spot-VMs gestützten Knotenpool mit Checkpointing. Implementieren Sie preStop-Hooks, um laufende Arbeiten abzuschließen, und einen Controller, um unterbrochene Jobs neu einzuplanen. Begründung: Die Thumbnail-Erstellung ist idempotent und zeitlich flexibel, was sie ideal für Kosteneinsparungen durch Spot-VMs mit minimalen Auswirkungen auf die Benutzererfahrung macht.

5. Kosten für Analyse-Scans reduzieren und Workloads isolieren

   • Partitionieren und clustern Sie die Events-Tabelle nach event_date und customer_id. Fügen Sie einen Tabellenablauf für Roh-Events nach 180 Tagen hinzu. Weisen Sie Marketing-Analysten einer separaten BigQuery-Reservierung mit einer Slot-Obergrenze zu; erzwingen Sie maximum_bytes_billed in ihren geplanten Abfragen. Wandeln Sie nächtliche Berichte in Jobs mit Batch-Priorität um. Begründung: Partitionierung und Clustering reduzieren die pro Abfrage gelesenen Bytes; der Tabellenablauf setzt Governance durch; Reservierungen isolieren „Noisy Neighbors“;

← Testen · Alle Domänen

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

Google durchsuchen →