Google PCA: Cost, Performance and Sustainable Cloud Design — Study Guide

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

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

Overview

Cost, performance, and sustainable cloud design are co-optimized disciplines. Building efficient architectures on Google Cloud requires financial observability, elastic capacity that follows demand, data lifecycle rigor, informed placement and caching for networks, and continuous measurement. This section explains design and operational patterns that reduce waste without sacrificing reliability, security, or performance, and highlights failure modes and trade-offs to avoid costly surprises.

Cost Architecture and Financial Accountability

Establish financial controls as part of your platform baseline.

• Billing analysis and allocation

  • Export billing data to BigQuery for queryable, near-real-time spend analysis by project, service, SKU, and label. Partition by day for scalable queries and set dataset access controls for finance and engineering stakeholders.
  • Use budgets with alert thresholds to prevent spend drift. Route budget alerts to Pub/Sub and automate responses (for example, pausing noncritical workloads). Be aware that alerts are not transactional and may have reporting delays; do not rely on them as the sole control for runaway jobs.

• Labels, tags, and cost attribution

  • Standardize organization-wide labels (cost_center, env, owner, app) and enforce them at provisioning time with deployment templates or policy-as-code.
  • Prefer hierarchical tags and folder/project structure to reflect chargeback/showback models. Use both labels (resource-level) and tags (policy and billing scope) to achieve precise allocation.

• Budget guardrails and anomaly detection

  • Configure per-project and per-portfolio budgets; set multiple thresholds (for example, 50, 80, 100 percent) and “forecasted” alerts for proactive action.
  • Use Recommender insights (idle VM, unattached disk, IPs, unused commitments) to prune waste continuously.

• Practical examples

  • Apply labels on creation:
    • gcloud compute instances create api-1 –labels=env=prod,cost_center=retail,owner=eng
  • Query billing export for unlabelled spend to enforce compliance via CI/CD checks.

Common failure modes and trade-offs:

• Inconsistent labels break cost allocation; enforce with org policies and validation in pipelines.
• Centralized billing without per-team budgets hinders accountability; create budgets at the team or product level.
• Delayed budget alerting means rapid spikes may overshoot; layer caps and quotas where possible.

Compute Efficiency and Performance

Match resources to workload profiles; automate elasticity; reserve or discount steady baseload.

• Rightsizing and custom machine types

  • Continuously analyze CPU, memory, disk IOPS, and network utilization to rightsize. Use custom machine types to fit vCPU and memory to the app’s real needs and avoid paying for idle memory.
  • Watch out for headroom: target 60–75 percent sustained CPU and ensure memory headroom sufficient for GC or spikes. Too aggressive rightsizing increases risk of throttling or OOMs.

• Autoscaling and lifecycle scheduling

  • Use managed instance group autoscaling on relevant signals (CPU, load balancer capacity, or custom queue depth). Configure warmup periods and scale-in controls to prevent thrash.
  • For non-24/7 environments, schedule start/stop of VMs, GKE node pools, or Cloud Run min instances to avoid idle spend. A simple first step is Cloud Scheduler triggering a Cloud Run job to stop dev instances nightly.

• Discount instruments

  • Committed-use discounts: commit 1–3 years for steady-state usage eligible for commitments. Balance commitment size with historic usage and business forecasts; overcommitting wastes money.
  • Spot VMs: ideal for fault-tolerant, batch, or distributed workloads. They can be reclaimed at any time; implement checkpointing and multi-instance groups with on-demand fallbacks.
    • Example: gcloud compute instances create etl-spot –provisioning-model=SPOT
  • Capacity reservations: reserve zonal or regional capacity for critical fleets to mitigate scale-up failure during regional shortages.
    • Example: gcloud compute reservations create web-capacity –zone=us-central1-a –machine-type=n2-standard-4 –vm-count=10

• Utilization metrics and performance tuning

  • Instrument with Cloud Monitoring, Profiler, and Trace. Measure p50/p95 latency, CPU steal, GC time, and queue backlogs. Optimize hot code paths before scaling out.
  • Pin performance-sensitive workloads to regions and zones with adequate CPU platforms and consider high-throughput persistent disks or Hyperdisk where needed.

Failure modes and trade-offs:

• Unbounded autoscaling can exceed quotas and cost targets; pre-raise quotas, set max replicas, and use predictive autoscaling for known peaks.
• Spot VMs can cause partial-fleet churn; diversify zones and implement graceful termination hooks.
• Overcommitting CUDs or underutilized reservations create sunk costs; review commitments quarterly.

Storage, Databases, and Analytics Cost-Performance

Choose storage classes and database capacity models that reflect access patterns, retention, and performance SLOs.

• Storage classes and lifecycle policies

  • Use Standard for hot, Nearline for monthly access, Coldline for quarterly, and Archive for long-term seldom access. Keep data and compute in the same region to avoid egress.
  • Apply lifecycle management to transition or delete objects automatically. Mind minimum storage durations and retrieval charges; premature class transitions can cost more than they save.
  • Example lifecycle policy (delete older than 90 days):
    • { “rule”: [{ “action”: {“type”: “Delete”}, “condition”: {“age”: 90} }]}
    • gsutil lifecycle set lifecycle.json gs://my-backups

• Data transfer and archival

  • Inter-region access often incurs egress; co-locate producers and consumers. Use Private Google Access and VPC-SC for secure, cost-aware access to Google APIs. For long-term archives, avoid frequent retrieval from Archive to prevent high retrieval charges.

• Database sizing and performance

  • Relational: size for memory-resident working set, IOPS, and read replicas. Enable automatic storage increase and monitor replication lag; scale vertically or shard horizontally when lag threatens RPO/RTO.
  • NoSQL/time series: use Bigtable for high-throughput, low-latency ingestion with proper row key design to avoid hotspots.

• BigQuery cost controls and capacity models

  • On-demand (per TB scanned): fast to start, spiky cost risk. Capacity-based reservations: predictable spend, control over concurrency and throughput. Flex commitments absorb short-term spikes.
  • Optimize queries with partitioning and clustering; require partition filters to prevent full-table scans:
    • bq update –require_partition_filter=true myds.mytable
  • Set per-job maximum bytes billed to cap spend:
    • bq query –use_legacy_sql=false –maximum_bytes_billed=100000000000 ‘SELECT …’
  • Use materialized views, result cache, approximate aggregations, and avoid SELECT * in production. Keep storage and compute in the same region.

Failure modes and trade-offs:

• Moving hot objects to Coldline/Archive triggers retrieval cost and early deletion fees.
• BigQuery on-demand without controls can incur runaway costs from unfiltered scans; enforce max bytes billed and partition filters.
• Oversharding databases increases operational complexity; benchmark before splitting.

Networks, Throughput, Quotas, and Sustainable Design

Data movement and concurrency design strongly influence cost and performance; sustainability choices further refine placement and scheduling.

• Network egress, inter-region traffic, CDN, and caching

  • Minimize inter-region hops; replicate data only where user proximity or compliance demands it. Use Cloud CDN to offload static and cacheable dynamic content; tune cache keys, TTLs, and signed URLs for high hit ratios.
  • Cache near clients (CDN), at the edge of your VPC (proxy cache), and within services (in-memory caches like Memorystore). Beware stale data and invalidation storms; define explicit cache-control headers.

• Performance measurement, load testing, and scaling

  • Establish SLOs and measure them with Cloud Monitoring, Uptime checks, Cloud Trace, and Profiler. Track p95/p99 latency and saturation signals.
  • Load test with realistic data and think time. Stage tests to avoid triggering global rate limits; request temporary quota increases.
  • Scale throughput using horizontal replicas, sharded queues, partitioned topics, and autoscalers driven by backlog metrics. Prefer asynchronous pipelines where possible.

• Quotas, concurrency, rate limits, and backpressure

  • Inventory per-service quotas by region; enforce client-side exponential backoff with jitter for 429/5xx responses. Implement admission control and queue-based backpressure to protect dependencies.
  • Tune Pub/Sub flow control (max outstanding messages/bytes), batching, and parallelism. In Cloud Run and GKE, right-size concurrency to match CPU and memory, preventing tail-latency inflation.

• Sustainability-aware design

  • Prefer serverless and managed services with high utilization. Choose regions with higher carbon-free energy percentages when latency and compliance permit.
  • Schedule batch and flexible jobs during low-carbon windows; use Carbon Footprint reporting to track impact.
  • Use energy-efficient machine types and consider ARM-based compute where compatible to improve performance per watt.

• Governance that balances reliability, security, performance, and cost

  • Define architectural guardrails: mandatory labels, budget alerts, org policies (for example, restrict external IPs), SLO/error budgets, and cost SLOs.
  • Conduct regular cost-performance reviews with engineering, security, and finance. Integrate Recommender and custom dashboards; build remediation runbooks.
  • Balance trade-offs explicitly: multi-region versus regional (durability and latency versus cost and egress), encryption and inspection layers (security versus CPU and latency), and aggressive autoscaling (performance versus quota and spend risk).

Typical failure modes and trade-offs:

• Cross-region analytics against a single-region dataset drives sustained egress; replicate or relocate compute.
• CDN misconfiguration yields low hit ratios; monitor cache hit and origin egress to validate savings.
• Lack of backpressure during partial outages amplifies failure; implement circuit breakers and shed load gracefully.

Practical Problem Scenario

Acme Learn, an online education company, experiences unpredictable evening spikes during live events. Costs rise sharply from cross-region BigQuery queries, autoscaling surges, and egress from static assets. Leadership also wants to reduce carbon impact without degrading user experience.

Approach:

1. Consolidate billing visibility and enforce cost allocation

   • Create a billing export to BigQuery and dashboards segmented by product, environment, and region using labels and tags standardized in deployment templates.
   • Rationale: Near-real-time visibility ties spend to responsible teams, enabling budget accountability. Labels power granular chargeback and anomaly detection.

2. Re-architect analytics to co-locate compute and storage

   • Move event analytics datasets and scheduled queries to the same region as the stream processors. For BigQuery, switch high-volume teams from on-demand to capacity reservations sized for peak concurrency with a small flex buffer.
   • Rationale: Co-location eliminates inter-region egress. Capacity-based BigQuery stabilizes costs under load while preserving performance.

3. Optimize content delivery with edge caching

   • Front static and semi-dynamic lesson assets with Cloud CDN, setting explicit cache-control headers and signed URLs for premium content. Tune TTLs based on content mutability.
   • Rationale: High cache hit ratios shift traffic from origins to the edge, cutting egress and origin compute while improving latency during peaks.

4. Harden autoscaling and reservations for live events

   • Add a regional managed instance group for the API tier with autoscaler targets on both CPU and request backlog. Create a small zonal capacity reservation to guarantee burst headroom during events. Enable predictive autoscaling ahead of scheduled sessions.
   • Rationale: Dual-signal autoscaling reacts to both utilization and demand, while reservations and predictive warm-up avoid cold-start latency and capacity shortfalls.

5. Apply compute mix: base load on commitments, burst on spot

   • Purchase 1-year commitments for baseline API and data processing workloads. Configure batch transcodes and enrichment jobs on Spot VMs with checkpointing and multi-zone instance groups.
   • Rationale: Commitments reduce steady-state cost; Spot VMs provide low-cost elasticity for interruptible work without risking user traffic.

6. Institute storage lifecycle and regional placement

   • Keep hot course metadata and thumbnails in regional Standard close to serving compute. Transition logs and raw clickstreams to Nearline after 30 days and delete after 180 days. For compliance archives, use Archive with documented retrieval SLAs.
   • Rationale: Aligns storage class to access patterns, reducing ongoing cost while respecting retention.

7. Put guardrails on BigQuery usage

   • Require partition filters on large tables and set project-level job defaults for maximum bytes billed. Introduce materialized views for common aggregates and partitioned ingestion patterns.
   • Rationale: Prevents accidental full scans, stabilizes spend, and accelerates frequent queries.

8. Engineer for throughput with backpressure and quotas

   • Integrate Cloud Tasks for rate-limited workflows and configure Pub/Sub subscribers with flow control. Implement exponential backoff with jitter for third-party APIs and set per-service concurrency ceilings in Cloud Run.
   • Rationale: Controls demand to respect quotas, protects dependencies under surge, and avoids cascading failures.

9. Embed sustainability into operations

   • Prefer serverless where feasible, select regions with higher carbon-free energy for analytics, and schedule non-urgent batch jobs during low-carbon windows. Track emissions with Carbon Footprint and include in quarterly reviews.
   • Rationale: Improves performance-per-watt and reduces carbon impact with minimal user-facing trade-offs.

10. Govern continuously

• Create budgets and alerts per product, enforce labels via policy, and establish monthly cost-performance-SLO reviews. Automate Recommender-based cleanup of idle resources and unattached disks.
• Rationale: Ongoing governance sustains gains, prevents regressions, and balances reliability, security, performance, and cost over time.

This design reduces egress, stabilizes analytics cost, ensures predictable performance during live events, and advances sustainability targets without compromising user experience.

← DevOps · All domains

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

Browse Google →