Google Cloud Professional Cloud Architect
Last reviewed: May 2026
A scannable reference of architectural patterns the PCA exam tests. Read top-to-bottom, or jump to a section.
A global application requires low latency and high availability for users worldwide.
Use a Global HTTP(S) Load Balancer with multi-region backends (MIGs/GKE), Cloud CDN for static content, and Cloud Armor for DDoS protection.
Why: The Global Load Balancer provides a single anycast IP that routes users to the nearest healthy backend. CDN caches content at the edge, reducing origin load and latency.
Ingest and process high-throughput, real-time data from IoT devices for immediate analysis.
Use Pub/Sub for scalable message ingestion, a Dataflow streaming pipeline for real-time processing and anomaly detection, and write results to BigQuery for analytics.
Why: This is the canonical serverless pattern for real-time data. Pub/Sub decouples ingestion, Dataflow handles complex processing with auto-scaling, and BigQuery supports streaming inserts for real-time analytics.
A gaming backend needs to store player state and leaderboards with sub-millisecond read latency and high throughput.
Use Cloud Bigtable for game state/leaderboards and Memorystore (Redis) for session caching.
Why: Bigtable provides single-digit millisecond latency for high-throughput reads/writes, ideal for time-series or large analytical datasets. Memorystore offers microsecond latency for session state.
A globally distributed application requires a database with strong transactional consistency and horizontal scalability.
Use Cloud Spanner with a multi-region configuration.
Why: Spanner is the only service that provides global, strongly consistent transactions with SQL semantics and horizontal scalability. Cloud SQL requires manual sharding for this scale.
Migrating a demanding, on-premises Oracle or PostgreSQL database requiring high availability, performance, and minimal refactoring.
Use AlloyDB for PostgreSQL.
Why: AlloyDB is a fully managed, PostgreSQL-compatible database with superior performance, 99.99% availability, and Oracle compatibility features, making it ideal for enterprise migrations.
Connecting an on-premises data center to GCP with consistent, low-latency (<10ms) and high-bandwidth (10+ Gbps) requirements.
Use Dedicated Interconnect with redundant connections.
Why: Dedicated Interconnect provides a private, high-bandwidth, low-latency physical connection. Cloud VPN runs over the public internet and cannot guarantee latency or bandwidth SLAs at this level.
Designing a network for multiple teams/projects requiring centralized network management but decentralized project ownership.
Implement a hub-and-spoke model using a Shared VPC. The central network team manages the host project, and application teams use service projects.
Why: Shared VPC allows centralized control over networking resources (subnets, firewalls) while delegating resource management in service projects. This is more scalable and secure than VPC peering.
Managing Kubernetes clusters consistently across Google Cloud, AWS, Azure, and on-premises environments.
Use Anthos to provide a unified control plane for multi-cloud and hybrid cluster management, policy enforcement, and observability.
Why: Anthos extends GKE to other environments, enabling consistent operations and GitOps-based configuration management (Config Management) across your entire fleet.
A data science team needs to train complex ML models with GPU acceleration without managing infrastructure.
Use Vertex AI Training with custom containers and Vertex AI Experiments for tracking model iterations.
Why: Vertex AI provides a fully managed training service that handles infrastructure provisioning, scaling, and GPU management. It integrates with experiments to track and compare model performance.
Serving a large ML model with low latency and high availability, capable of auto-scaling.
Use Vertex AI Prediction with a custom container, deployed to a managed endpoint with autoscaling enabled.
Why: Vertex AI Prediction is optimized for low-latency model serving. It handles autoscaling, traffic splitting (for A/B testing), and infrastructure management, abstracting complexity from developers.
A Cloud Function or Cloud Run service needs to securely connect to a Cloud SQL instance with a private IP.
Configure a Serverless VPC Access Connector to bridge the serverless environment with your VPC.
Why: The connector creates a tunnel into your VPC, allowing serverless services to access internal resources by their private IP addresses without exposing them to the internet.
Migrating a stateful application that uses local session storage to a stateless, auto-scaling platform like Cloud Run or GKE.
Externalize session state to a managed in-memory store like Memorystore (Redis).
Why: Stateless compute requires session data to be stored externally so any instance can handle any user request. Memorystore provides a shared, low-latency solution for this.
Create a managed continuous delivery pipeline to promote releases across multiple environments (staging, prod) with approvals.
Use Cloud Deploy to define a delivery pipeline that orchestrates deployments to target environments (GKE, Cloud Run) with built-in approval gates.
Why: Cloud Deploy is a fully managed service for CD, providing release management, audibility, and automated rollback capabilities without the operational overhead of self-hosting tools like Spinnaker.
Deploy a containerized application on a production-ready Kubernetes cluster with minimal operational and management overhead.
Use a GKE Autopilot cluster.
Why: Autopilot manages the cluster's control plane and nodes, including provisioning, scaling, and security hardening. You only pay for the pod resources you request, simplifying both operations and cost management.
Incrementally migrate a large, monolithic application to a microservices architecture with minimal risk and downtime.
Apply the Strangler Fig pattern. Place a proxy in front of the monolith, and gradually redirect traffic for specific functionalities to new microservices as they are built and validated.
Why: This pattern avoids a high-risk "big bang" rewrite by allowing for a gradual, controlled transition. The monolith is slowly "strangled" as new services take over its functionality.
Migrate a large number of on-premises VMs to Google Cloud with minimal downtime.
Use Migrate to Virtual Machines (formerly Migrate for Compute Engine) to perform continuous, block-level replication from on-premises to GCP, followed by a quick cutover.
Why: This tool is designed for lift-and-shift migrations, minimizing downtime to minutes by keeping source and target VMs in sync until the final cutover.
A team is adopting SRE principles and needs to establish their initial SLOs.
Define user-centric Service Level Indicators (SLIs) first (e.g., availability, latency). Analyze historical performance data to set realistic initial Service Level Objectives (SLOs).
Why: SLOs must be based on user experience (SLIs) and be achievable. Setting them based on historical data ensures the initial error budget is realistic and not immediately violated.
Automate the creation of new GCP projects with a standardized configuration (APIs, IAM, networking, security).
Use a "Project Factory" pattern with a Terraform module, triggered by Cloud Build. Use Service Catalog to provide a self-service interface.
Why: This ensures all new projects adhere to organizational standards and security baselines, reducing manual effort and configuration drift. It enables governance at scale.
Preventing manual changes (configuration drift) to infrastructure managed by Terraform.
Use a CI/CD pipeline (e.g., Cloud Build) for all applies, Terraform state locking (via GCS backend), Organization Policies to restrict console actions, and regular drift detection.
Why: A multi-layered approach is required. The pipeline enforces a single path for changes, locking prevents concurrent applies, and Org Policies provide a preventative guardrail.
Managing infrastructure code (Terraform) for multiple environments (dev, staging, prod) with shared modules but different configurations.
Use a single set of reusable Terraform modules and provide environment-specific configurations through separate `.tfvars` files or workspaces.
Why: This follows the Don't Repeat Yourself (DRY) principle. Modules ensure consistency, while variables files provide the flexibility to tailor each environment.
Implementing a GitOps workflow to automatically deploy Kubernetes manifests from a Git repository to GKE clusters.
Use Anthos Config Management (or the standalone Config Sync) to continuously reconcile the cluster state with the configuration in a Git repository.
Why: Config Sync provides a fully managed GitOps solution that detects and corrects configuration drift, ensuring the Git repository is the single source of truth for the cluster's state.
Implementing a blue-green deployment for a web application with zero downtime and instant rollback capability.
Use two identical Managed Instance Groups (or GKE Deployments) behind an HTTP(S) Load Balancer. Perform the cutover by redirecting traffic in the load balancer's backend service.
Why: Traffic splitting at the load balancer level is instantaneous and allows for easy rollback by simply switching the traffic back to the original backend. This is superior to slower DNS-based methods.
Securely store, manage, and audit access to secrets like API keys and database passwords for applications.
Use Secret Manager with IAM for access control and Workload Identity for keyless authentication from GKE/Cloud Run.
Why: Secret Manager is a centralized, managed service with versioning, rotation policies, and audit logging. Using Workload Identity avoids managing and distributing service account keys.
Prevent sensitive data in services like BigQuery and Cloud Storage from being accessed or copied to unauthorized projects or locations.
Use VPC Service Controls to create a service perimeter around sensitive projects and restrict data flow.
Why: VPC Service Controls act as a firewall for Google-managed services, preventing data exfiltration at the API level. This is a critical defense-in-depth layer beyond IAM and network firewalls.
Encrypt data at rest in Google Cloud services while maintaining full control over the encryption keys.
Use Customer-Managed Encryption Keys (CMEK), with keys stored and managed in Cloud KMS.
Why: CMEK allows you to use your own keys via Cloud KMS to protect data in other GCP services. You control key rotation and can revoke access by disabling the key, providing cryptographic erasure.
Designing an architecture to handle Protected Health Information (PHI) in compliance with HIPAA.
Use CMEK for encryption control, VPC Service Controls to prevent exfiltration, Assured Workloads for compliance boundaries, Cloud Audit Logs, and Access Transparency for auditing.
Why: HIPAA requires a combination of technical controls. CMEK provides key control, VPC-SC prevents data leaks, and extensive logging (Audit Logs, Access Transparency) provides necessary audibility.
A GKE pod needs to connect to a Cloud SQL database securely without using passwords or managing service account keys.
Use Workload Identity to bind a Kubernetes Service Account to a Google Service Account. Connect using the Cloud SQL Auth Proxy sidecar and IAM database authentication.
Why: This "passwordless" pattern is the most secure. Workload Identity provides keyless authentication, the Auth Proxy encrypts traffic, and IAM DB auth uses IAM for database access instead of static credentials.
Enforce a policy that all cloud resources must be created only in specific geographic regions (e.g., EU).
Configure an Organization Policy constraint (`gcp.resourceLocations`) at the organization or folder level, specifying the allowed regions.
Why: This is a preventative control that blocks non-compliant resource creation at the API level. It is the authoritative way to enforce data residency policies across the entire organization.
Ensure only trusted, scanned, and authorized container images are deployed to production GKE clusters.
Use Artifact Registry for vulnerability scanning and Binary Authorization to enforce deployment policies that require valid attestations (signatures).
Why: This creates a secure software supply chain. Artifact Registry scans for vulnerabilities, and Binary Authorization acts as a policy enforcement point, cryptographically verifying that an image has passed all required checks.
Provide secure, context-aware access to internal web applications for remote employees without using a traditional VPN.
Use BeyondCorp Enterprise with Identity-Aware Proxy (IAP), Access Context Manager for policies, and Endpoint Verification for device posture.
Why: This implements a zero-trust model where access is granted based on user identity and device trust, not network location. IAP acts as an authenticating proxy for every request.
A regulated workload requires that encryption keys be stored and processed within a FIPS 140-2 Level 3 certified Hardware Security Module (HSM).
Use Cloud KMS with the `HSM` protection level for keys.
Why: Cloud HSM is a fully managed service providing FIPS 140-2 Level 3 certified HSMs. Keys generated with this protection level never leave the HSM boundary in plaintext.
Automatically discover and de-identify sensitive data (like PII) in Cloud Storage or BigQuery.
Use Cloud Data Loss Prevention (DLP) to scan for sensitive data and apply de-identification techniques like masking, tokenization, or redaction.
Why: DLP provides pre-built and custom detectors for a wide range of sensitive data types, enabling automated and scalable data protection without custom scripting.
Allow employees from multiple identity providers (e.g., Okta, Azure AD) to access Google Cloud resources without creating Google accounts.
Use Workforce Identity Federation to connect external identity providers to Google Cloud IAM.
Why: This allows you to leverage your existing identity systems as the source of truth, avoiding the need to sync users or manage separate Google identities for your workforce.
Process highly sensitive data where the data must remain encrypted even while in-use (in memory).
Use Confidential VMs.
Why: Confidential Computing encrypts data during processing using dedicated hardware features (AMD SEV). This protects against memory scraping attacks and provides an extra layer of security for sensitive workloads.
Optimize BigQuery cost and performance for a large data warehouse.
Implement partitioning by date and clustering on frequently filtered columns. Use BI Engine for dashboards and materialized views for common, expensive aggregations.
Why: Partitioning and clustering are fundamental for reducing the amount of data scanned per query, which directly lowers costs and improves speed. BI Engine and MVs reduce redundant computations.
Run large-scale, fault-tolerant batch processing jobs with the lowest possible compute cost.
Use Spot VMs in a Managed Instance Group. Ensure the application is fault-tolerant and can handle preemptions.
Why: Spot VMs offer up to 91% savings over on-demand instances. They are ideal for stateless, fault-tolerant workloads that can be stopped and restarted, like many batch processing tasks.
Implement FinOps practices to provide cost visibility and accountability to different teams or departments.
Use a resource hierarchy (folders per team), apply labels for cost allocation, and export detailed billing data to BigQuery for analysis and visualization in Looker Studio.
Why: This combination provides a structured way to organize resources, granularly track costs via labels, and build custom, team-specific dashboards for showback/chargeback.
Optimize GKE cluster cost and performance for applications with variable load.
Use Horizontal Pod Autoscaler (HPA) to scale pods based on metrics, and Cluster Autoscaler to add/remove nodes as needed.
Why: This two-level autoscaling approach ensures that both the application (pods) and the infrastructure (nodes) scale in tandem with demand, preventing over-provisioning and ensuring performance.
An ML training job shows low GPU utilization (<30%), indicating a bottleneck.
Diagnose and optimize the data input pipeline. Use `tf.data` with prefetching and parallel reads, or Cloud Storage FUSE to improve I/O performance.
Why: Low GPU utilization is almost always a data I/O bottleneck. The GPU is idle while waiting for the next batch of data. Optimizing data loading is the first step to improve training efficiency.
Reduce high network egress costs from serving data to the internet or across regions.
Use Cloud CDN to cache static content. For inter-region traffic, use the Standard Network Service Tier for non-latency-sensitive workloads.
Why: CDN serves data from the edge, which is cheaper than egress from the origin. Standard Tier routes traffic over the public internet instead of Google's premium network, offering a lower cost for bulk data transfer.
Reduce costs for development and test VMs that are only needed during business hours.
Use Cloud Scheduler to trigger Cloud Functions that automatically start and stop instances on a predefined schedule.
Why: This "instance scheduling" pattern automates the process of shutting down resources when they are not in use, significantly reducing costs for non-production environments.
A critical application requires a relational database with automatic failover in case of a zonal failure.
Configure the Cloud SQL instance with the High Availability (HA) option.
Why: The HA configuration creates a standby instance in a different zone with synchronous replication. In case of a primary instance or zone failure, failover is automatic and typically takes under 60 seconds.
Automatically detect and recover from unresponsive or failed Compute Engine instances.
Deploy instances within a Managed Instance Group (MIG) and configure autohealing with an application-based health check.
Why: MIG autohealing actively probes the application on each instance. If the application fails its health check, the MIG automatically recreates the instance, ensuring service reliability.
Design a disaster recovery plan with an RTO of < 1 hour and RPO of < 15 minutes.
Implement a warm standby in a secondary region. Use Cloud SQL cross-region replicas, multi-regional Cloud Storage, and pre-configured instance templates for compute.
Why: This approach balances cost and recovery time. Data is replicated near-synchronously to meet the RPO, and minimal infrastructure is running (warm) to allow for a quick scale-up to meet the RTO.
Implement comprehensive observability for a microservices application to enable quick troubleshooting.
Use structured logging with correlation IDs, Cloud Trace for distributed tracing, Cloud Monitoring for metrics, and Cloud Error Reporting for automated error grouping.
Why: A combination of logs, traces, and metrics (the "three pillars of observability") is essential. Correlation IDs and distributed tracing are critical for following a single request across multiple services.
Prevent a failure in one microservice from causing a cascading failure across the entire application.
Implement resilience patterns like circuit breakers, retries with exponential backoff, and aggressive timeouts at each service-to-service communication point.
Why: These patterns isolate failures. A circuit breaker stops calls to a failing service, preventing the calling service from exhausting its resources and failing in turn.
Implement SRE best practices to reduce the risk of production outages caused by new deployments.
Use canary deployments to gradually roll out changes, feature flags to decouple deployment from release, and automated rollback triggers based on SLO monitoring.
Why: These practices limit the "blast radius" of a bad deployment. Canaries expose the new version to a small subset of users first, and automated rollback minimizes the Mean Time to Recovery (MTTR).
Use SRE error budgets to balance feature velocity with reliability.
Define an error budget policy: when the budget is nearly consumed, freeze new feature deployments and prioritize work that improves reliability.
Why: The error budget is a data-driven mechanism for making trade-off decisions. It gives teams permission to take risks when the budget is healthy and enforces a focus on stability when it is not.
A globally distributed application using Cloud Spanner experiences high write latency in certain regions.
Analyze the application's write patterns and configure the Spanner instance's leader region to be geographically close to the majority of write operations.
Why: In Spanner, all writes are routed through the leader region to ensure consistency. Placing the leader region close to the primary source of writes minimizes network latency for those transactions.
