Google PCD: Cost, Governance and Sustainable Application Operations — Study Guide

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

Part of the Google Professional Cloud Developer — Study Guide. Practice with verified answers in the Google exam hub, or take timed practice tests on ExamRoll.io.

Overview

Cost, governance, and sustainable operations are inseparable in modern Google Cloud application development. The goal is to expose and control spend, design services that scale economically, and enforce guardrails that keep environments secure, compliant, and clean—while balancing performance and reliability. This section details practical mechanisms (billing and labels, autoscaling knobs, quotas and policies), workload-specific economics (Cloud Run, GKE, data platforms), and the sustainability-aware choices that reduce idle waste and carbon impact without undermining user experience.

Cost Controls and Visibility

• Billing accounts, labels, cost allocation, budgets, alerts, and visibility
  • Use a dedicated billing account per business unit or funding source to isolate ownership and enable granular permissions. Export billing data to BigQuery for detailed analysis, forecasting, and chargeback.
  • Labels are key-value pairs on resources for cost attribution. Standardize label keys (team, app, env, cost-center) and enforce via organization policy and CI checks. Note: labels are not retroactive; unlabeled resources skew reports.
  • Use budgets and alerts at billing account and project levels. Combine thresholds (e.g., 50, 90, 100 percent) and forecast-based triggers. Route budget notifications to Pub/Sub and forward to Chat/Ops tools. Budgets alert; they do not enforce.
  • For shared platforms (e.g., GKE, BigQuery), use per-namespace or per-job labels and attach them to logs and usage to enable showback/chargeback.

Example: add labels gcloud compute instances update web-01 –labels=team=payments,app=checkout,env=prod

• Quotas, limits, consumption forecasting, and capacity governance
  • Quotas protect services and limit runaway costs. Review service quotas regularly, right-size them per project, and request increases ahead of launches. Implement pre-deploy checks that compare expected peak usage against quotas.
  • Forecast spend using Billing export plus product usage telemetry (Cloud Monitoring metrics, logs-based metrics). Model scenarios (expected QPS, data scanned) and validate in pre-production.
  • Failure modes: hitting quota mid-incident or product launch leads to throttling (429/403), partial outages, or silent degradation. Over-provisioned quotas increase blast radius of faulty jobs.

Example: list Compute Engine quotas gcloud services quota list
–service=compute.googleapis.com
–consumer=projects/$PROJECT_ID

Elasticity and Compute Economics

• Right-sizing, autoscaling, request-based billing, committed use, and spot capacity

  • Right-size vCPU and memory using Cloud Monitoring and Recommender insights; validate with load tests. Under-allocations cause latency spikes and OOM/CPU throttling; over-allocations waste spend.
  • Autoscaling converts capex-like overprovisioning into elastic opex. Use HPA/VPA for GKE, and per-request autoscaling for serverless (Cloud Run) to match capacity to demand.
  • Request-based billing (Cloud Run, Cloud Functions, GKE Autopilot) aligns cost with usage and reduces idle. Beware of per-request overheads and cold starts; tune min instances where appropriate.
  • Committed use is for steady-state baseline. Use resource-based CUDs for Compute Engine and flexible CUDs for eligible managed/serverless products. Do not overcommit volatile workloads.
  • Spot capacity reduces compute cost for interruptible, fault-tolerant jobs. Always implement graceful termination handlers; maintain redundancy and rapid checkpointing. Expect termination at any time with short notice.

• Cloud Run concurrency and minimum-instance trade-offs

  • Concurrency controls how many requests a single instance can serve simultaneously.
    • Higher concurrency improves utilization and cost efficiency but can raise tail latency due to head-of-line blocking inside the container.
    • Concurrency of 1 isolates requests (useful for CPU-bound or non-thread-safe code) but often increases instance count and cost.
  • Minimum instances reduce cold starts and smooth latency at the cost of a baseline spend. Use only where SLOs require it and validate the floor with demand patterns.

Example: Cloud Run configuration (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 resource requests and limits, cluster autoscaler behavior, and idle cleanup
  • Requests determine scheduling; limits cap peak usage. Set requests close to observed steady need and limits slightly above to allow short bursts. Too-low limits cause CPU throttling; too-low memory limits cause OOMKilled. Requests far above reality strand capacity and block scheduling.
  • Cluster Autoscaler scales node pools based on unschedulable pods (insufficient aggregate requests). It respects PodDisruptionBudgets and cannot evict certain pods (e.g., with local storage or restrictive PDBs), which may prevent scale-down. DaemonSets and node taints/affinities can also block scale efficiency.
  • Horizontal Pod Autoscaler ties scaling to CPU/memory or custom metrics; Vertical Pod Autoscaler right-sizes requests over time. Coordinate HPA and VPA to avoid oscillation; use VPA in recommend or auto modes as appropriate.
  • Idle-resource cleanup: delete unused load balancers, persistent disks, snapshots, and static IPs. Use Active Assist recommendations and automated janitors to detect and remove idle assets.

Example: GKE deployment with 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”

Data, Analytics, and Network Cost Governance

• Storage classes, lifecycle controls, database scaling, and network-egress design
  • Choose Cloud Storage classes by access pattern: Standard for hot data; Nearline, Coldline, or Archive for colder data. Be mindful of retrieval and early-delete minimums for colder tiers.
  • Lifecycle rules automate transitions and deletions. Use dual-region for resilience where multi-region latency is acceptable; co-locate compute and data to reduce egress and latency.
  • Database scaling:
    • Cloud SQL: scale vertically cautiously; read replicas for reads; storage autoscaling; use query plans and connection pooling. High write throughput may require sharding or moving to Spanner/Bigtable.
    • Spanner: horizontal scaling by adding nodes; multi-region configs for availability and global reads; design schemas and keys for balanced load.
    • Bigtable: design row keys to avoid hotspots; scale cluster nodes and storage separately.
  • Network egress: avoid cross-region traffic; place clients and data in the same region where possible. Use Cloud CDN for internet-scale content, Cloud Interconnect/Peering for hybrid, and Private Google Access or Private Service Connect to access Google APIs privately. Unnecessary cross-zone/regional traffic increases cost and latency.

Example: Cloud Storage lifecycle 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 query controls, data retention, and analytics usage cost
  • Control bytes scanned: always filter by partition/cluster keys; avoid SELECT *; use materialized views and result caching for repeated queries; use approximate aggregations when possible.
  • Cap scan cost with maximum bytes billed and set job priority to batch for non-urgent work to reduce interference and cost.
  • Choose pricing model: on-demand for sporadic workloads; reservations (slots) with commitments for steady high-volume workloads. Use separate reservations and assignments to isolate teams.
  • Data retention: set dataset/table and partition expiration for governance; implement tiered storage or export for archival.
  • Failure modes: unpartitioned large tables explode costs; queries without partition filters scan full tables; overly aggressive expirations delete needed data; excessive slot contention degrades SLA.

Example: cap query cost 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’

Organizational Governance and Environment Hygiene

• Organization policies, resource naming, tagging, and project separation

  • Use organization policies to enforce guardrails: restrict resource locations, disallow external IPs, require CMEK, restrict allowed services, control VPC peering, and mandate OS Login where needed. Apply at org or folder level with exceptions modeled via hierarchy.
  • Standardize resource naming to encode environment, project, app, and region (e.g., app-env-region-suffix). Enforce via CI checks or policy-as-code.
  • Distinguish:
    • Labels: billing/operations attribution.
    • Tags (first-class): attach to resources and use in IAM Conditions and org policy targeting.
    • Network tags: for firewall rules on Compute Engine.
  • Project separation: isolate environments (prod, staging, dev) and sensitive workloads. Use Shared VPC for centralized networking and least-privilege service projects. This reduces blast radius and simplifies IAM.

• Environment lifecycle, ephemeral testing environments, and cleanup automation

  • Provision environments via IaC (Terraform) and enable ephemeral per-PR environments. Set TTL labels and automatic teardown after merge or inactivity.
  • Use Cloud Scheduler plus Cloud Run jobs or Functions to sweep for stale resources by label/age and delete them. Export inventory via Cloud Asset Inventory to drive audits.
  • Failure modes: abandoned sandboxes incur cost; missing TTL or labels prevent cleanup; over-aggressive cleanup can delete active resources—add allowlists and grace periods.

• Sustainability-aware architecture and balancing cost, performance, and reliability

  • Prefer managed and serverless services to reduce idle and improve resource utilization.
  • Choose regions with lower carbon intensity when compliant; schedule batch workloads during periods of higher carbon-free energy when feasible.
  • Optimize data gravity and caching to reduce network energy. Tune autoscaling and concurrency to lower underutilization. Use profiling to remove wasteful code paths that trigger excess compute or IO.
  • Balance: add minimum instances or replicas only where SLOs require; evaluate tail latency vs concurrency and redundancy vs spot usage. Validate with SLO-based load testing and cost/perf modeling.

Practical Problem Scenario

NimbusMarket, an e-commerce company, experiences spiky traffic during flash sales and growing analytics spend. They run customer APIs on Cloud Run, background workers on GKE, and product analytics in BigQuery. Leadership asks for 25 percent cost reduction without compromising the 99.9 percent API SLO.

Approach:

1. Establish cost visibility and guardrails

   • Create budgets with forecast alerts at 60, 90, and 100 percent for the billing account, with Pub/Sub notifications routed to on-call.
   • Standardize labels (team, app, env, cost-center) and enforce via CI on Terraform plans; add an org policy that restricts resource locations to approved regions. Rationale: Budgets give early warning; labels unlock per-team reports; policies prevent accidental high-egress regions and improve compliance.

2. Tune Cloud Run for economic scaling

   • Set containerConcurrency to 40 for the stateless API after profiling confirms 30 ms average CPU time and non-blocking IO. Configure minScale=2 to avoid cold starts during normal hours; set a scheduled policy to drop minScale to 0 overnight. Rationale: Higher concurrency improves utilization and reduces instance count; minimal steady instances preserve SLOs with limited baseline cost that is removed off-hours.

3. Right-size GKE workloads and enable efficient autoscaling

   • Apply requests of 500m CPU/512Mi and limits of 1 CPU/768Mi to the worker pods based on profiling. Enable HPA on queue depth and processing latency, and VPA in recommend mode to iteratively refine requests. Verify PodDisruptionBudgets allow scale-down. Enable Cluster Autoscaler on the pool with multiple smaller nodes. Rationale: Accurate requests drive effective scheduling and autoscaling; HPA aligns capacity to backlog; VPA avoids drift; multiple small nodes reduce stranded capacity and speed scale events.

4. Adopt Spot capacity for fault-tolerant batch

   • Move image thumbnail generation to Spot-backed node pool with checkpointing. Implement preStop hooks to flush in-flight work and a controller to reschedule interrupted jobs. Rationale: Thumbnailing is idempotent and time-flexible, making it ideal for Spot savings with minimal impact on user experience.

5. Reduce analytics scan costs and isolate workloads

   • Partition and cluster the events table by event_date and customer_id. Add table expiration for raw events after 180 days. Assign marketing analysts to a separate BigQuery reservation with a slot cap; enforce maximum_bytes_billed in their scheduled queries. Convert nightly reports to batch priority. Rationale: Partitioning and clustering curb per-query bytes; expiration enforces governance; reservations isolate noisy neighbors; batch reduces contention and cost for non-urgent jobs.

6. Optimize storage lifecycle and egress

   • Store product images in dual-region near customers; move images untouched for 30 days to Coldline via lifecycle rules; serve via Cloud CDN. Co-locate Cloud Run services with Cloud SQL in the same region and enable Private Service Connect to Google APIs. Rationale: CDN reduces egress and latency; lifecycle shifts cold content to cheaper storage; co-location minimizes egress and improves performance.

7. Implement cleanup automation and sustainability checks

   • Tag ephemeral environments with ttl-hours and run a nightly Cloud Run job that deletes expired resources. Use Carbon Footprint reports to consider moving batch jobs to a lower-carbon region and schedule them during off-peak carbon hours. Rationale: Automated cleanup prevents cost leaks; carbon-aware scheduling reduces environmental impact without affecting SLOs.

8. Validate with SLO-aware load tests and cost models

   • Run load tests that replay flash-sale patterns; verify p95 latency and error budgets. Compare cost before/after using billing export dashboards. Rationale: Confirms that tuning meets reliability targets while delivering measurable savings aligned to goals.

By executing these steps, NimbusMarket aligns spend with demand, prevents idle waste, and enforces governance, achieving targeted savings while maintaining the 99.9 percent API SLO and improving sustainability posture.

← Testing · All domains

Practice these questions → · Timed practice on ExamRoll.io →

Browse Google →