Free Google Cloud Architect Designing and planning a cloud solution architecture Practice Test 2026 — GCP PCA Questions

Last updated: June 2026 · Aligned with the current Google Professional Cloud Architect exam · 25% of the exam

This free Google Cloud Architect Designing and planning a cloud solution architecture practice test covers translating business and technical requirements into a Google Cloud architecture — compute, storage, networking, hybrid connectivity, migration planning, and cost optimization. Each question includes a detailed explanation with real Google Cloud context — perfect for GCP PCA exam prep.

Key Topics in Google Cloud Architect Designing and planning a cloud solution architecture

10 Free Google Cloud Architect Designing and planning a cloud solution architecture Practice Questions with Answers

Each question below includes 4 answer options, the correct answer, and a detailed explanation. These are real questions from the FlashGenius GCP PCA question bank for the Designing and planning a cloud solution architecture domain (25% of the exam).

Sample Question 1 — Designing and planning a cloud solution architecture

A global retail company is modernizing its legacy on‑premises order management system. The new system will be deployed on Google Cloud and must: • Serve web and mobile clients globally with p95 latency under 200 ms for read operations. • Support peak traffic spikes of 20x during seasonal sales with minimal manual intervention. • Ensure that order creation and payment processing remain strongly consistent and ACID-compliant. • Minimize operational overhead for infrastructure management. • Keep costs predictable and avoid overprovisioning for rare peak events. Additional constraints: • The company’s risk team requires that payment data be stored in a single geographic region for regulatory reasons. • Business stakeholders want to roll out new features weekly with minimal downtime. You are designing the core data and application architecture. What should you do?

  1. A. Use a global HTTP(S) Load Balancer in front of regional managed instance groups running a monolithic application on Compute Engine. Store all data (including orders and payments) in a single regional Cloud SQL instance in the regulatory-approved region. Use autoscaling on the instance groups to handle traffic spikes.
  2. B. Deploy stateless microservices on Cloud Run (fully managed) in multiple regions behind a global HTTP(S) Load Balancer. Store order and payment data in a single-region Cloud SQL instance in the regulatory-approved region. Use Cloud CDN for static assets and configure Cloud Run autoscaling to handle peak traffic.
  3. C. Deploy stateless microservices on GKE Autopilot in two regions behind a global HTTP(S) Load Balancer. Use Cloud Spanner with a multi-region configuration for all order and payment data to achieve global low-latency reads and strong consistency. Use horizontal pod autoscaling to handle traffic spikes.
  4. D. Deploy stateless microservices on Cloud Run (fully managed) in multiple regions behind a global HTTP(S) Load Balancer. Use a dual-database strategy: Cloud Spanner multi-region for order data to provide global low-latency reads and strong consistency, and a single-region Cloud SQL instance in the regulatory-approved region for payment data. Use Cloud Run autoscaling to handle traffic spikes. (Correct answer)

Correct answer: D

Explanation: Option D best balances latency, consistency, regulatory, and operational requirements. Analysis of requirements: - Global low-latency reads (<200 ms p95): This suggests regional deployments close to users and a globally distributed data store for read-heavy data (orders, catalog, etc.). - Strong consistency and ACID for order creation and payments: Both operations must not exhibit eventual consistency; they need transactional guarantees. - Regulatory constraint: Payment data must reside in a single geographic region. - Operational simplicity and elastic scaling: Prefer fully managed, serverless, and autoscaling services. - Frequent releases with minimal downtime: Stateless services and managed platforms simplify blue/green or rolling deployments. Why D is best: - Cloud Run (fully managed) in multiple regions behind a global HTTP(S) Load Balancer provides: - Low-latency access for users globally. - Automatic scaling to handle 20x traffic spikes with minimal ops overhead. - Simple deployment model for weekly releases. - Dual-database strategy: - Cloud Spanner multi-region for order data: - Strong consistency and ACID transactions across regions. - Global low-latency reads and writes with high availability. - Ideal for order state, inventory, and other globally accessed transactional data. - Single-region Cloud SQL for payment data: - Satisfies regulatory requirement to keep payment data in one region. - Provides ACID transactions for payment records. - The application can orchestrate transactions so that payment operations are localized to that region while orders are globally consistent via Spanner. - This design: - Meets latency targets for most user interactions via Spanner and regional Cloud Run. - Respects regulatory constraints for payment data. - Minimizes operational overhead by using fully managed services. Why not A: - Monolithic app on Compute Engine: - Higher operational overhead (instance management, patching, capacity planning). - Less agile for weekly feature rollouts. - Single-region Cloud SQL for all data: - Global users will experience higher latency due to cross-continent round trips. - May struggle with 20x spikes without careful capacity planning and scaling. - While technically possible, this design does not optimize for global latency or operational simplicity. Why not B: - Cloud Run multi-region is good for stateless services and autoscaling, but using a single-region Cloud SQL for both orders and payments: - Violates the latency requirement for global users (all reads/writes go to one region). - Puts more pressure on a single regional database during 20x spikes. - It meets regulatory needs but not the global latency and scalability goals for the core order workload. Why not C: - Cloud Spanner multi-region for all data (including payments): - Technically strong for global consistency and latency, but conflicts with the explicit requirement that payment data be stored in a single geographic region. - May increase cost and regulatory complexity for payment data. - GKE Autopilot is managed but still more operationally complex than Cloud Run (cluster concepts, upgrades, etc.). - While this design is robust and performant, it fails the regulatory constraint and is not the simplest operationally. Therefore, D is the only option that satisfies global latency, strong consistency, regulatory constraints, and operational simplicity together.

Sample Question 2 — Designing and planning a cloud solution architecture

A financial analytics company is building a new customer-facing reporting platform on Google Cloud. The platform ingests transactional data from multiple banks and generates dashboards and scheduled reports. Key requirements are: • Data from each bank must be logically and cryptographically isolated from other banks. • The platform must support per-bank custom data retention policies and encryption key rotation schedules. • Regulatory auditors require clear separation of duties: the platform operations team must not be able to decrypt customer data, but must be able to operate and monitor the system. • The solution must minimize operational overhead and avoid complex custom key management code. • The architecture should allow onboarding new banks with minimal engineering effort. You are designing the high-level architecture for multi-tenancy, security, and operations. What should you do?

  1. A. Use a single GCP project for the platform. Store all banks’ data in shared BigQuery datasets and Cloud Storage buckets, using row-level security and per-bank IAM roles. Use a single CMEK key in Cloud KMS for all data, and rotate it on a global schedule managed by the security team.
  2. B. Create a separate GCP project for each bank. Within each project, store that bank’s data in its own BigQuery datasets and Cloud Storage buckets. Use per-project CMEK keys in Cloud KMS, managed and rotated according to each bank’s policy. Use a shared service project for the platform services and configure cross-project IAM and VPC peering. (Correct answer)
  3. C. Use a single GCP project and separate BigQuery datasets and Cloud Storage buckets per bank. Use per-bank CMEK keys in Cloud KMS within the same project. Grant the platform operations team Cloud KMS CryptoKey Encrypter/Decrypter role so they can manage and troubleshoot encryption issues. Use a single VPC and shared services for all banks.
  4. D. Use an organization-level folder per bank, with multiple projects per bank (prod, test, dev). Store data in per-bank BigQuery datasets and Cloud Storage buckets using Google-managed encryption keys. Implement logical isolation using IAM and VPC Service Controls. Manage retention and key rotation policies centrally at the organization level.

Correct answer: B

Explanation: Option B best aligns with the requirements for strong isolation, per-tenant policies, separation of duties, and operational simplicity. Requirement mapping: - Logical and cryptographic isolation per bank: - Separate GCP projects per bank provide a strong isolation boundary for resources, IAM, and quotas. - Per-project CMEK keys ensure cryptographic isolation; compromise of one key does not affect others. - Per-bank retention and key rotation policies: - Each project can have its own Cloud KMS key ring and keys with independent rotation schedules. - Data retention policies can be configured per project (e.g., per-bucket lifecycle rules, per-dataset policies). - Separation of duties: - Platform operations team can have roles in the shared service project (where application and monitoring run) without having decrypt permissions on per-bank CMEK keys. - Access to KMS keys in each bank’s project can be tightly controlled, potentially to a separate security team or customer-controlled identities. - Minimize operational overhead and onboarding effort: - A repeatable project-per-tenant pattern is easy to templatize (e.g., via Terraform or Deployment Manager). - Cross-project access from a shared service project is a standard pattern (shared VPC, cross-project IAM, or service accounts). Why B is best: - It uses projects as the primary isolation boundary, which is recommended for strong multi-tenant isolation in regulated environments. - It supports per-tenant CMEK and retention policies without complex custom key management code. - It cleanly separates operational responsibilities between platform operations and security/compliance teams. Why not A: - Single project and single CMEK key for all banks: - Fails cryptographic isolation requirement; compromise or misconfiguration of the single key affects all tenants. - Cannot support per-bank key rotation schedules. - While row-level security and IAM can provide logical isolation, auditors and regulators often prefer stronger boundaries (projects + separate keys) for financial data. Why not C: - Single project with per-bank CMEK keys improves cryptographic isolation but: - Granting the operations team CryptoKey Encrypter/Decrypter role violates the separation of duties requirement; they would be able to decrypt customer data. - Single project still couples quotas, policies, and blast radius across all banks. - This design partially meets requirements but fails the clear separation of duties and strong isolation expectations for financial data. Why not D: - Organization-level folders per bank with Google-managed encryption keys: - Google-managed keys do not provide per-bank CMEK control or custom key rotation schedules; rotation is managed by Google, not per-tenant. - Fails the requirement for per-bank cryptographic isolation and custom key rotation policies. - Centralized retention and key rotation at the org level contradicts the requirement for per-bank policies. Therefore, B is the only option that satisfies strong per-tenant isolation, per-bank key and retention policies, separation of duties, and operational simplicity in a scalable, repeatable architecture.

Sample Question 3 — Designing and planning a cloud solution architecture

A global retail company is modernizing its on-premises e-commerce platform to Google Cloud. The platform is a monolithic Java application with the following requirements: - Must support seasonal traffic spikes up to 10x normal load for short periods. - Checkout and payment flows must maintain sub-200 ms latency for users in North America and Europe. - The company has a small operations team and wants to minimize day-2 operational overhead. - The application writes to a relational database and uses local disk for caching product catalog data. - The business wants to gradually refactor the monolith into microservices over the next 2–3 years. You need to design the initial target architecture on Google Cloud that best balances performance, cost, and long-term maintainability while enabling gradual modernization. What should you do?

  1. A. Lift and shift the monolith to a regional managed instance group of Compute Engine VMs behind a global external HTTP(S) load balancer, use Cloud SQL for the relational database, and use instance-local SSDs for caching.
  2. B. Containerize the monolith and deploy it to a regional GKE cluster with cluster autoscaling, use Cloud SQL for the relational database, and use a Redis cluster on Compute Engine VMs for caching.
  3. C. Containerize the monolith and deploy it to Cloud Run (fully managed) with minimum instances configured for baseline traffic, use Cloud SQL for the relational database, and use Memorystore for Redis for caching. (Correct answer)
  4. D. Refactor the monolith into separate microservices before migration, deploy each service to Cloud Run (fully managed), use Firestore in Native mode for all data storage, and use Cloud CDN for caching.

Correct answer: C

Explanation: Option C best aligns with the requirements and constraints: - **Performance & global reach**: Cloud Run (fully managed) can be fronted by a global external HTTP(S) load balancer, providing low-latency access for users in North America and Europe. It supports rapid scale-out to handle 10x traffic spikes. - **Operational simplicity**: Cloud Run is fully managed, removing the need to manage servers, clusters, or OS patching. This fits the small operations team and minimizes day-2 operations. - **Gradual modernization**: Containerizing the monolith is a natural first step that later allows splitting into multiple services, each deployable as separate Cloud Run services. This supports the 2–3 year refactoring plan. - **Stateful needs**: Cloud SQL satisfies the relational database requirement. Memorystore for Redis provides a managed, low-latency cache without the operational burden of managing Redis on VMs. - **Cost efficiency**: Cloud Run’s scale-to-zero and per-request billing help control costs outside peak seasons, while minimum instances can be tuned for latency and warm capacity. Why the other options are suboptimal: - **Option A (Compute Engine MIG + Cloud SQL + local SSD cache)**: - Technically viable but increases operational overhead: OS patching, capacity planning, instance templates, and autoscaling tuning. - Local SSD caching is tied to individual VMs, making cache warm-up and consistency more complex and less flexible when scaling. - Less aligned with the goal of minimizing operations and enabling gradual microservices adoption. - **Option B (GKE + Cloud SQL + Redis on VMs)**: - GKE reduces some operational burden but still requires cluster management, node pool sizing, upgrades, and Kubernetes expertise. - Running Redis on Compute Engine VMs adds more operational overhead (patching, failover, scaling) compared to a managed cache. - This is more complex than necessary for a team explicitly wanting minimal day-2 operations. - **Option D (Immediate refactor to microservices + Cloud Run + Firestore)**: - Requires a large up-front refactor before migration, increasing risk, timeline, and complexity; this contradicts the requirement to *gradually* refactor over 2–3 years. - Replacing a relational database with Firestore may require significant data model changes and application rewrites, which is not aligned with a phased approach. - While Cloud Run and Cloud CDN are good managed choices, the forced refactor and data store change make this option risky and misaligned with constraints. Therefore, option C provides the best balance of performance, cost, operational simplicity, and a clear path to gradual modernization.

Sample Question 4 — Designing and planning a cloud solution architecture

A financial services company is building a new customer analytics platform on Google Cloud. The platform will ingest transaction events from multiple regions and provide near-real-time dashboards to internal analysts. Requirements are: - Regulatory requirement: All customer-identifiable data for EU customers must remain within the EU. - Latency: Dashboards should reflect new transactions within 30 seconds. - Availability: The analytics platform must tolerate the loss of a single region without data loss. - Cost: The company wants to minimize operational overhead and avoid managing complex distributed databases. - Security: Data must be encrypted at rest and in transit, and access must be tightly controlled via IAM. You need to design the data storage and processing architecture. What should you do?

  1. A. Ingest all events into a global Pub/Sub topic, write them to a multi-region BigQuery dataset in `EU` for EU customers and `US` for non-EU customers using Dataflow, and build dashboards directly on BigQuery.
  2. B. Ingest events into regional Pub/Sub topics in each region, write them to regional Cloud SQL instances, then use cross-region replication to a central Cloud SQL instance in `EU` for analytics, and build dashboards on the central instance.
  3. C. Ingest events into regional Pub/Sub topics, use Dataflow in each region to write EU customer data to a regional BigQuery dataset in an EU region and non-EU data to a regional BigQuery dataset in a US region, and build dashboards using BigQuery BI Engine with authorized views that join across datasets. (Correct answer)
  4. D. Ingest all events into a global Pub/Sub topic, write them to a multi-region Cloud Spanner instance with read-write replicas in EU and US, and build dashboards using federated queries from BigQuery to Cloud Spanner.

Correct answer: C

Explanation: Option C best satisfies the regulatory, availability, latency, and operational requirements: - **Regulatory compliance**: EU customer data is written to a BigQuery dataset in an EU region; non-EU data is written to a US-region dataset. This ensures data residency per regulatory requirements. - **Availability & durability**: BigQuery regional datasets are highly durable and can be combined with regional processing via Dataflow. Pub/Sub and Dataflow provide at-least-once delivery and can be configured for high availability. - **Latency**: Pub/Sub + Dataflow streaming to BigQuery typically achieves latencies well under 30 seconds, meeting the near-real-time dashboard requirement. - **Operational simplicity**: BigQuery and Dataflow are fully managed. There is no need to manage database clusters, sharding, or complex replication. - **Security**: BigQuery and Pub/Sub encrypt data at rest and in transit by default, and IAM can be used to tightly control access. Authorized views allow secure, controlled cross-dataset access for dashboards. Why the other options are suboptimal: - **Option A (Global Pub/Sub + multi-region BigQuery)**: - Using a multi-region BigQuery dataset for EU customers in `EU` is acceptable, but the scenario implies a need for strict EU residency and resilience to regional loss. Multi-region can help, but ingesting *all* events into a single global Pub/Sub topic may route data through non-EU infrastructure, which can be problematic for strict residency requirements depending on interpretation. - It also doesn’t clearly separate processing paths for EU vs non-EU data, making compliance audits more complex. - **Option B (Regional Pub/Sub + Cloud SQL + cross-region replication)**: - Cloud SQL is not ideal for high-throughput streaming analytics; it is better suited for transactional workloads. - Cross-region replication for analytics at scale can be costly and complex to manage. - Meeting the 30-second latency SLA at scale with Cloud SQL and replication is challenging. - **Option D (Global Pub/Sub + Cloud Spanner + federated queries)**: - Cloud Spanner is powerful but is generally more expensive and operationally complex than BigQuery for analytics workloads. - Using Spanner as the primary analytics store is suboptimal; BigQuery is designed for analytics and integrates better with BI tools. - Federated queries from BigQuery to Spanner add complexity and may impact latency and cost. Option C uses regionally scoped, managed analytics services (BigQuery, Dataflow, Pub/Sub) to meet compliance, availability, latency, and operational simplicity goals, making it the best choice.

Sample Question 5 — Designing and planning a cloud solution architecture

A healthcare provider is migrating its patient portal to Google Cloud. The portal exposes REST APIs to mobile and web clients and must integrate with on-premises electronic health record (EHR) systems. Requirements are: - Compliance: All patient data must comply with HIPAA and be protected with strong access controls. - Connectivity: The portal must securely access on-premises EHR systems with low operational overhead. - Availability: The API layer must be highly available across zones within a single region. - Security: The company wants centralized API security policies (rate limiting, authentication, threat protection) and detailed audit logs. - Future-proofing: They plan to expose some APIs to third-party partners in the future. You need to design the architecture for the API layer and connectivity to on-premises systems. What should you do?

  1. A. Deploy the API services on a regional GKE cluster, expose them via an internal HTTP(S) load balancer, connect to on-premises via Cloud VPN, and manage authentication and rate limiting within the application code.
  2. B. Deploy the API services on Cloud Run (fully managed), expose them via a global external HTTP(S) load balancer with Cloud Armor, connect to on-premises via Cloud VPN, and use Cloud Endpoints for authentication and quota management.
  3. C. Deploy the API services on Cloud Run (fully managed), front them with Apigee X for API management, connect to on-premises via a Dedicated Interconnect, and configure VPC Service Controls around the project. (Correct answer)
  4. D. Deploy the API services on Compute Engine managed instance groups, expose them via a global external HTTP(S) load balancer with Cloud Armor, connect to on-premises via Cloud VPN, and use Identity-Aware Proxy (IAP) for API authentication.

Correct answer: C

Explanation: Option C best addresses compliance, security, availability, and future extensibility: - **Compliance & security**: Apigee X provides enterprise-grade API management with strong security features (OAuth2, JWT validation, threat protection, quotas, rate limiting) and detailed audit logging, which is important for HIPAA compliance. VPC Service Controls add an additional layer of defense-in-depth around data access. - **Centralized API security policies**: Apigee is designed for centralized API governance, making it easier to apply consistent policies across internal and future external APIs. - **Availability**: Cloud Run is regional and can be configured across multiple zones within a region, providing high availability. Apigee X is also designed for high availability. - **Connectivity**: Dedicated Interconnect offers more reliable, lower-latency connectivity than VPN, which is appropriate for critical healthcare integrations with EHR systems, especially at scale. - **Future-proofing**: Apigee is well-suited for exposing APIs to third-party partners with fine-grained control, monetization options, and developer portal support. Why the other options are suboptimal: - **Option A (GKE + internal LB + VPN + in-app security)**: - GKE adds operational complexity (cluster management, upgrades) compared to Cloud Run. - Managing authentication, rate limiting, and threat protection in application code increases development and maintenance burden and is error-prone. - Internal load balancer is not ideal for external mobile/web clients; you would need additional components to expose APIs externally. - **Option B (Cloud Run + external LB + Cloud Armor + Cloud Endpoints)**: - Cloud Run plus Cloud Endpoints can handle authentication and quotas, and Cloud Armor adds some security, but this combination is less feature-rich than Apigee for enterprise API management (e.g., advanced policies, partner onboarding, monetization, complex traffic management). - Cloud VPN may be sufficient initially but is less reliable and scalable than Dedicated Interconnect for mission-critical healthcare integrations. - While technically viable, it is less aligned with the long-term need for partner APIs and strong governance. - **Option D (Compute Engine MIG + LB + Cloud Armor + IAP)**: - Compute Engine requires more operational work (OS patching, capacity management) than Cloud Run. - IAP is well-suited for securing access to internal web apps and some APIs but is not a full-featured API management platform. It lacks advanced API lifecycle management and partner onboarding capabilities. - This design does not provide centralized, rich API management features needed for future third-party exposure. Option C combines fully managed compute (Cloud Run), enterprise API management (Apigee X), strong network connectivity (Dedicated Interconnect), and additional perimeter security (VPC Service Controls), making it the most appropriate architecture for a regulated healthcare API platform.

Sample Question 6 — Designing and planning a cloud solution architecture

A media streaming company is designing a new recommendation service on Google Cloud. The service will: - Receive user interaction events (views, likes) from clients worldwide. - Compute personalized recommendations using a machine learning model. - Serve recommendations via a low-latency API to users primarily in North America and Asia. Constraints and requirements: - Latency: API responses must be under 100 ms P95 for users in North America and Asia. - Availability: The service must remain available even if an entire region fails. - Consistency: Recommendation results can be slightly stale (up to a few minutes), but the system must not lose events. - Cost: The company wants to avoid overprovisioning and prefers pay-per-use where possible. - Operations: The team has limited SRE capacity and wants a design that is simple to operate. You need to design the serving and data pipeline architecture. What should you do?

  1. A. Ingest events into a global Pub/Sub topic, process them with a regional Dataflow streaming job that writes to a single Bigtable instance in `us-central1`, deploy the recommendation API on GKE in `us-central1`, and use a global external HTTP(S) load balancer to serve traffic worldwide.
  2. B. Ingest events into a global Pub/Sub topic, process them with Dataflow streaming jobs in two regions (one in North America, one in Asia) that each write to regional Bigtable instances, deploy the recommendation API on Cloud Run in both regions reading from the local Bigtable, and use a global external HTTP(S) load balancer with latency-based routing. (Correct answer)
  3. C. Ingest events into regional Pub/Sub topics in each region, process them with Cloud Functions that write to Cloud SQL in each region, deploy the recommendation API on Compute Engine managed instance groups in each region, and use Cloud DNS with geo-based routing.
  4. D. Ingest events into a global Pub/Sub topic, process them with a single Dataflow streaming job that writes to a multi-region BigQuery dataset, deploy the recommendation API on Cloud Run in two regions that query BigQuery directly for each request, and use a global external HTTP(S) load balancer with latency-based routing.

Correct answer: B

Explanation: Option B best meets the latency, availability, consistency, cost, and operational requirements: - **Latency**: Deploying the recommendation API on Cloud Run in both a North America and an Asia region, fronted by a global external HTTP(S) load balancer with latency-based routing, ensures users are served from the nearest region, helping meet the 100 ms P95 target. - **Availability & regional failure tolerance**: Having independent pipelines and serving stacks in two regions allows the system to continue operating if one region fails. Pub/Sub’s global topic can feed both Dataflow jobs, ensuring events are available to both regions. - **Consistency & durability**: Dataflow streaming jobs provide at-least-once processing semantics, and Bigtable offers low-latency reads and high write throughput. Slight staleness is acceptable, and the design ensures events are not lost. - **Cost & operations**: Cloud Run and Dataflow are managed services with autoscaling and pay-per-use pricing, reducing overprovisioning and operational overhead. Bigtable requires capacity planning but is appropriate for low-latency, high-throughput workloads. Why the other options are suboptimal: - **Option A (Single region Bigtable + GKE in `us-central1`)**: - Single-region deployment does not meet the requirement to remain available if an entire region fails. - Users in Asia would experience higher latency due to distance from `us-central1`, making it harder to meet the 100 ms P95 requirement. - GKE adds operational complexity compared to Cloud Run. - **Option C (Regional Pub/Sub + Cloud Functions + Cloud SQL + Compute Engine)**: - Cloud SQL is not ideal for high-throughput, low-latency recommendation lookups at global scale. - Compute Engine and Cloud SQL require more operational management (scaling, patching, capacity planning) than Cloud Run and Bigtable. - Cloud DNS geo-based routing is less flexible and feature-rich than a global external HTTP(S) load balancer for traffic management. - **Option D (BigQuery as online store)**: - BigQuery is optimized for analytics, not for per-request, low-latency online serving. Querying BigQuery on each API request is unlikely to meet the 100 ms P95 latency requirement. - A single Dataflow job and multi-region BigQuery dataset provide durability but do not provide the ultra-low-latency access pattern needed for recommendations. Option B uses regionally deployed, low-latency data stores (Bigtable), managed compute (Cloud Run), and managed streaming (Pub/Sub + Dataflow) to achieve global low-latency access, regional fault tolerance, and manageable operational overhead, making it the best architectural choice.

Sample Question 7 — Designing and planning a cloud solution architecture

A global media company is building a new video-on-demand platform on Google Cloud. The platform will serve users in North America, Europe, and Asia-Pacific. Requirements: • Users must experience initial video start times under 2 seconds in all regions. • The catalog and user profiles are read-heavy, with occasional writes (e.g., new subscriptions, profile updates). • The business expects traffic spikes during major events and wants to minimize operational overhead. • Data residency: User profile data for EU residents must remain in the EU region. • The team has limited SRE capacity and wants to avoid managing complex distributed databases. You are designing the data layer and content delivery architecture. What should you do?

  1. A. Store all user profiles and catalog data in a single multi-region Cloud Spanner instance in nam-eur-asia, and serve video content from a regional GCS bucket in us-central1 fronted by a global external HTTP(S) load balancer and Cloud CDN.
  2. B. Use regional Cloud SQL instances in each major region for user profiles and catalog data, with asynchronous cross-region replication, and store video content in a dual-region GCS bucket in each continent, fronted by Cloud CDN.
  3. C. Store user profiles in regional Firestore databases (one in europe-west, one in us-central, one in asia-southeast) with application-level routing based on user residency, store catalog data in a global Cloud Spanner instance, and host video content in a multi-region GCS bucket with Cloud CDN. (Correct answer)
  4. D. Use a single regional Firestore database in europe-west for all user profiles and catalog data to satisfy EU residency, and store video content in a regional GCS bucket in europe-west, fronted by a global external HTTP(S) load balancer and Cloud CDN.

Correct answer: C

Explanation: Option C best balances latency, compliance, and operational simplicity: • Latency and performance: – Firestore regional instances in europe-west, us-central, and asia-southeast keep user profile data close to users, reducing read/write latency. – Cloud Spanner for catalog data provides globally consistent, strongly consistent reads and writes with horizontal scalability. Catalog is read-heavy and global, making Spanner appropriate. – Multi-region GCS with Cloud CDN ensures low-latency content delivery and automatic caching close to users. • Compliance: – EU user profiles are stored in europe-west, satisfying data residency. Application-level routing ensures EU users are directed to the EU Firestore instance. – Non-EU users can be served from US or APAC regions without violating EU residency. • Operational overhead: – Firestore is fully managed, auto-scales, and avoids complex cluster management. – Spanner is managed and designed for global workloads, reducing the need to manage sharding or complex replication. – Cloud CDN + multi-region GCS is low-ops for content delivery. Why others are suboptimal: A) Single multi-region Spanner for all user profiles and catalog data + regional GCS in us-central1: – Latency: A single regional GCS bucket in us-central1 increases latency for EU and APAC users, especially for large video assets. – Compliance: Multi-region Spanner spanning multiple continents may not guarantee that EU user data remains strictly in the EU region; data may be stored and processed outside the EU. – Operationally simpler than some alternatives, but fails the data residency requirement and optimal content latency. B) Regional Cloud SQL instances with async replication + dual-region GCS per continent: – Latency: Regional Cloud SQL per region can be good for latency. – Compliance: You could keep EU data in an EU instance, but cross-region replication and routing logic become complex. – Operational overhead: Managing multiple Cloud SQL instances, replication, failover, and schema changes across regions is higher ops burden than Firestore/Spanner. Async replication also introduces potential consistency issues for global catalog data. D) Single regional Firestore and GCS in europe-west: – Compliance: EU residency is satisfied, but this over-constrains all data to EU. – Latency: Users in North America and APAC will experience higher latency for both metadata and video content, likely violating the <2s start time requirement under load. – This design prioritizes compliance at the expense of user experience and global performance. Therefore, C is the best trade-off across latency, compliance, and operational simplicity.

Sample Question 8 — Designing and planning a cloud solution architecture

A financial services company is modernizing a monolithic on-premises application that processes loan applications. They want to move to Google Cloud and gradually decompose the monolith into microservices. Requirements: • Regulatory requirement: All customer PII must remain in a specific country (single GCP region). • The application must support synchronous APIs for partners with a 300 ms p95 latency SLO within the region. • The company wants to minimize operational overhead while enabling blue/green deployments and canary releases. • The team has limited Kubernetes expertise but strong CI/CD practices. • They expect unpredictable spikes in traffic during marketing campaigns. You need to propose a target architecture for the application layer that meets these requirements and supports gradual modernization. What should you recommend?

  1. A. Lift and shift the monolith into a managed instance group of Compute Engine VMs in the required region, fronted by a regional external HTTP(S) load balancer. Use instance templates and rolling updates for deployments, and later introduce microservices as additional VM-based services.
  2. B. Containerize the monolith and deploy it to a regional GKE Standard cluster with cluster autoscaling. Use an internal HTTP(S) load balancer for partner access, and gradually add microservices as separate deployments in the same cluster.
  3. C. Containerize the monolith and deploy it to Cloud Run (fully managed) in the required region, fronted by a regional external HTTP(S) load balancer with Cloud Armor. Gradually extract microservices into separate Cloud Run services, using traffic splitting for blue/green and canary releases. (Correct answer)
  4. D. Refactor the monolith into microservices before migration, then deploy all services to a regional GKE Autopilot cluster with a global external HTTP(S) load balancer and Cloud Armor. Use canary deployments via a service mesh.

Correct answer: C

Explanation: Option C aligns best with the requirements and constraints: • Regulatory / residency: – Cloud Run services can be deployed in a single specified region, ensuring PII remains in-country. • Latency: – Cloud Run in-region with a regional external HTTP(S) load balancer can meet a 300 ms p95 SLO for synchronous APIs, assuming reasonable application performance. • Operational overhead: – Cloud Run (fully managed) abstracts away cluster management, node scaling, and patching, which is ideal for a team with limited Kubernetes expertise. – Autoscaling based on request load handles unpredictable spikes. • Modernization and deployments: – Containerizing the monolith allows an initial lift-and-shift with minimal code changes. – You can gradually extract microservices into separate Cloud Run services. – Cloud Run supports traffic splitting, enabling blue/green and canary releases with minimal operational complexity. Why others are suboptimal: A) Compute Engine managed instance group: – Meets residency and can meet latency, but: – Higher operational overhead: managing OS patching, capacity planning, autoscaling tuning, and deployment orchestration. – Blue/green and canary are possible but more complex to implement and manage compared to Cloud Run’s built-in traffic splitting. – Less aligned with the goal of minimizing operational overhead and enabling easy microservice decomposition. B) GKE Standard cluster: – Supports microservices and can meet latency and residency. – However, the team has limited Kubernetes expertise, and GKE Standard requires managing node pools, upgrades, and cluster configuration. – Operational overhead is significantly higher than Cloud Run, especially during the early modernization phase. D) Full refactor before migration + GKE Autopilot: – GKE Autopilot reduces some operational burden, but still requires Kubernetes knowledge and cluster-level considerations. – Refactoring into microservices before migration is high risk and delays value; it conflicts with the requirement to gradually decompose the monolith. – Service mesh and canary deployments add complexity that the current team may not be ready to manage. Thus, C provides a low-ops, region-bound, scalable platform that supports gradual modernization and advanced deployment strategies.

Sample Question 9 — Designing and planning a cloud solution architecture

A healthcare analytics startup is designing a new platform on Google Cloud to process and analyze sensitive patient data from multiple hospitals. Requirements: • All data is classified as PHI and must comply with HIPAA. • Raw data arrives as batch files (CSV, JSON) several times per day from each hospital. • The platform must support both scheduled batch analytics and near-real-time dashboards (latency < 1 minute) for aggregated, de-identified metrics. • The team wants to minimize the risk of data exfiltration and enforce least privilege. • They prefer managed services and want to avoid managing long-running servers. You need to design the ingestion and analytics architecture. Which approach best meets these requirements?

  1. A. Ingest files into a regional Cloud Storage bucket with uniform bucket-level access and CMEK. Use Cloud Functions triggered on object finalize to load data into BigQuery. Build dashboards directly on the raw tables, and use IAM to restrict access to only analysts.
  2. B. Ingest files into a regional Cloud Storage bucket with VPC Service Controls and CMEK. Use Cloud Dataflow batch jobs scheduled via Cloud Scheduler to load and transform data into separate raw and de-identified BigQuery datasets. Use BigQuery row-level security and authorized views for dashboards. (Correct answer)
  3. C. Ingest files into a multi-region Cloud Storage bucket with default encryption. Use Cloud Run jobs triggered via Pub/Sub notifications to load data into a single BigQuery dataset. Use Data Studio dashboards directly on the dataset, and rely on project-level IAM for access control.
  4. D. Ingest files into a regional Cloud Storage bucket with CMEK. Use a persistent Dataproc cluster to run scheduled Spark jobs that load and transform data into Cloud SQL. Build dashboards on Cloud SQL using a BI tool, and restrict access via database user accounts.

Correct answer: B

Explanation: Option B best addresses compliance, security, and operational needs: • Compliance and security: – Regional Cloud Storage with CMEK supports HIPAA and strong encryption controls. – VPC Service Controls reduce data exfiltration risk by creating a security perimeter around Cloud Storage, BigQuery, and Dataflow. – BigQuery row-level security and authorized views allow fine-grained access control and de-identification for analytics consumers. • Architecture and latency: – Dataflow batch jobs can be scheduled frequently (e.g., every few minutes) to approach near-real-time for aggregated metrics while processing batch files. – Separating raw and de-identified datasets enforces least privilege: only a small set of users/services access raw PHI, while most users access only de-identified data. • Operational simplicity: – Dataflow is fully managed and serverless for data processing; no need to manage clusters. – Cloud Scheduler + Dataflow templates provide repeatable, low-ops batch pipelines. Why others are suboptimal: A) Cloud Functions loading directly into BigQuery raw tables: – Cloud Functions can handle ingestion, but: – Dashboards directly on raw tables containing PHI increase risk and complicate least-privilege enforcement. – No explicit de-identification layer or separate datasets for PHI vs non-PHI. – Lacks VPC Service Controls, which are highly recommended for PHI and HIPAA workloads. C) Multi-region bucket, Cloud Run jobs, single BigQuery dataset: – Multi-region storage may not align with hospital or regulatory requirements for data locality. – Default encryption is less controlled than CMEK for PHI. – Single dataset without clear separation of raw vs de-identified data makes least privilege and de-identification harder. – Relying only on project-level IAM is coarse-grained for sensitive healthcare data. D) Dataproc + Cloud SQL: – Persistent Dataproc cluster contradicts the desire to avoid managing long-running servers. – Cloud SQL is not ideal for large-scale analytics; BigQuery is more appropriate for analytical workloads. – Managing database users and scaling Cloud SQL for analytics is more operationally complex. Therefore, B provides a secure, compliant, and low-ops architecture with clear separation of PHI and de-identified analytics.

Sample Question 10 — Designing and planning a cloud solution architecture

An e-commerce company is re-architecting its order processing system on Google Cloud. The system consists of: • A public-facing API that receives orders. • A set of backend services that validate payments, update inventory, and send notifications. Requirements: • Orders must not be lost. In case of partial failures, the system must be able to retry processing without duplicating orders. • The public API must respond within 500 ms, even during peak traffic. • The architecture should support independent scaling of the public API and backend services. • The company wants to minimize operational overhead and avoid managing message brokers. • Security: Only backend services should be able to consume order messages; external clients must not directly access internal queues. You are designing the communication pattern between the public API and backend services. What should you do?

  1. A. Deploy the public API on Cloud Run and backend services on GKE. Use a regional internal HTTP(S) load balancer to route synchronous REST calls from the API to each backend service. Implement retries and idempotency in the API layer.
  2. B. Deploy both the public API and backend services on Cloud Run. Use Pub/Sub for asynchronous communication: the API publishes order messages to a topic, and each backend service subscribes to the topic. Use Pub/Sub dead-letter topics for failed messages and IAM to restrict subscriber identities. (Correct answer)
  3. C. Deploy the public API on App Engine and backend services on Compute Engine. Use Cloud Tasks to enqueue an HTTP task per order, targeting each backend service endpoint. Configure retries and idempotency keys in Cloud Tasks.
  4. D. Deploy the public API on Cloud Run and backend services on Cloud Run. Use Pub/Sub for asynchronous communication: the API publishes order messages to a topic, and a single order-orchestrator Cloud Run service subscribes to the topic and calls backend services synchronously via internal HTTP. Use Pub/Sub IAM and service accounts to secure access.

Correct answer: B

Explanation: Option B aligns best with Google Cloud best practices for a decoupled, scalable, and resilient architecture. Using Pub/Sub for asynchronous communication ensures the public API can respond quickly (under 500ms) by simply acknowledging the message receipt. Pub/Sub provides 'at-least-once' delivery and supports fan-out, allowing multiple backend services (payment, inventory, notifications) to process the same order independently via separate subscriptions. Cloud Run is a fully managed serverless platform that minimizes operational overhead and scales independently. Security is handled via IAM and service accounts, ensuring only authorized backend services can consume messages. Dead-letter topics handle persistent failures, and idempotency (required by the prompt) is a standard requirement for handling Pub/Sub's at-least-once delivery model.

How to Study Google Cloud Architect Designing and planning a cloud solution architecture

Combine these Google Cloud Architect Designing and planning a cloud solution architecture practice questions with Google Cloud's official learning path and hands-on practice in the Google Cloud free tier. The PCA exam rewards applied knowledge, so always tie concepts back to real solutions you've designed and deployed.

About the Google Professional Cloud Architect Exam

Other Google Cloud Architect Domains

Start the free Google Cloud Architect Designing and planning a cloud solution architecture practice test now | 10-question quick start | All GCP PCA domains