Free Google Cloud Architect Managing and provisioning a cloud solution infrastructure Practice Test 2026 — GCP PCA Questions

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

This free Google Cloud Architect Managing and provisioning a cloud solution infrastructure practice test covers configuring and deploying Google Cloud resources — VPC networking, Compute Engine, GKE, storage, databases, and infrastructure automation. Each question includes a detailed explanation with real Google Cloud context — perfect for GCP PCA exam prep.

Key Topics in Google Cloud Architect Managing and provisioning a cloud solution infrastructure

10 Free Google Cloud Architect Managing and provisioning a cloud solution infrastructure 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 Managing and provisioning a cloud solution infrastructure domain (17.5% of the exam).

Sample Question 1 — Managing and provisioning a cloud solution infrastructure

A global retail company is migrating its order-processing platform from an on-premises data center to Google Cloud. The platform consists of: - A stateless REST API layer currently running on VMs - A stateful order-processing service that uses a relational database - A nightly batch job that recalculates inventory and pricing Business and technical requirements: - The REST API must serve customers in North America and Europe with p95 latency under 200 ms. - The order-processing database must remain strongly consistent and support multi-region disaster recovery with an RPO of 5 minutes and RTO of 1 hour. - The company has a small operations team and wants to minimize ongoing infrastructure management. - The solution must support gradual migration, allowing some traffic to continue to be served from the on-premises environment during the transition. - Cost should be optimized, but not at the expense of availability and operational simplicity. You are designing the target architecture and provisioning approach on Google Cloud. Which architecture best meets these requirements while aligning with operational simplicity and long-term maintainability?

  1. A. Deploy the REST API and order-processing service on a regional GKE cluster in us-central1 with multi-zone node pools. Use a regional Cloud SQL instance in us-central1 for the database and set up read replicas in europe-west1. Use Cloud VPN to connect to on-premises and configure traffic splitting at the application level for gradual migration. Run the nightly batch job as a Kubernetes CronJob.
  2. B. Deploy the REST API as Cloud Run services in us-central1 and europe-west1 behind a global external HTTP(S) load balancer with traffic steering based on client location. Use Cloud Spanner with multi-region configuration spanning North America and Europe for the order-processing database. Use Database Migration Service for phased data migration from on-premises. Implement the nightly batch job as a Cloud Run job triggered by Cloud Scheduler. (Correct answer)
  3. C. Deploy the REST API and order-processing service on managed instance groups in us-central1 and europe-west1 behind a global external HTTP(S) load balancer. Use a primary Cloud SQL instance in us-central1 with cross-region read replica in europe-west1 and promote the replica during failover. Use Cloud Interconnect for hybrid connectivity and run the nightly batch job on a dedicated Compute Engine instance with a startup script.
  4. D. Deploy the REST API on App Engine standard in us-central1 and europe-west1 with traffic splitting for gradual migration. Keep the order-processing database on-premises and access it over Cloud VPN. Use Memorystore for caching to reduce latency for European users. Run the nightly batch job as an App Engine cron task that calls the on-premises database.

Correct answer: B

Explanation: Option B best aligns with the requirements and the Google Cloud Well-Architected Framework: - **Global low-latency API**: Deploying the REST API on Cloud Run in both us-central1 and europe-west1 behind a global external HTTP(S) load balancer allows traffic to be routed to the nearest region, helping meet the p95 < 200 ms latency requirement for North America and Europe. - **Strong consistency and multi-region DR**: Cloud Spanner with a multi-region configuration spanning North America and Europe provides strongly consistent, horizontally scalable, multi-region replication with low RPO and RTO built-in. This directly addresses the RPO 5 minutes / RTO 1 hour requirement without complex custom failover logic. - **Operational simplicity**: Cloud Run and Cloud Spanner are fully managed services, significantly reducing operational overhead for a small operations team. Cloud Run jobs plus Cloud Scheduler provide a managed, serverless pattern for the nightly batch job. - **Gradual migration**: Database Migration Service supports phased migration from on-premises to Cloud Spanner, enabling a controlled cutover strategy. The global load balancer can be used to gradually shift client traffic from on-prem to Cloud Run services. - **Cost vs reliability**: While Cloud Spanner is more expensive than Cloud SQL, the scenario explicitly prioritizes availability and operational simplicity over pure cost optimization, making this trade-off appropriate. Why the other options are suboptimal: - **Option A**: - Uses a single-region Cloud SQL primary with read replicas in europe-west1. This does not provide a multi-region, strongly consistent setup. Failover to a read replica requires promotion and may exceed the RPO 5 minutes / RTO 1 hour objectives, especially under operational stress. - GKE, while powerful, introduces more operational complexity (cluster management, node pools, upgrades) than Cloud Run, which conflicts with the small operations team and desire for minimal infrastructure management. - Latency for European users may be impacted if writes must go to us-central1, and read replicas do not solve write latency or strong consistency across regions. - **Option C**: - Uses managed instance groups on Compute Engine, which require more operational management (instance templates, autoscaling policies, OS patching) compared to serverless Cloud Run. - Cloud SQL with a primary in us-central1 and read replica in europe-west1 does not provide strongly consistent multi-region writes. Failover is manual and may not reliably meet the RPO/RTO requirements, especially in a complex failure scenario. - The nightly batch job on a dedicated VM with startup scripts is less operationally simple and resilient than Cloud Run jobs with Cloud Scheduler. - **Option D**: - Keeps the order-processing database on-premises, which makes it difficult to meet the RPO 5 minutes / RTO 1 hour requirement for a cloud-centric DR strategy. The on-prem environment remains a single point of failure. - Latency for European users is constrained by the round-trip to the on-premises database, even with caching. Strong consistency for order processing is hard to guarantee with a remote database. - This option does not fully leverage managed, cloud-native database capabilities and prolongs dependency on the on-premises environment, contrary to the migration goal. Therefore, Option B is the best answer.

Sample Question 2 — Managing and provisioning a cloud solution infrastructure

A financial services company is designing a new analytics platform on Google Cloud to process sensitive transaction data. The platform will: - Ingest transaction events in near real time from multiple regions - Store raw and processed data for 7 years to meet regulatory requirements - Provide internal analysts with interactive SQL-based analytics - Run scheduled machine learning training jobs on historical data Constraints and requirements: - Data is classified as highly sensitive and must never be exposed to the public internet. - Access must be tightly controlled and auditable at the column and row level. - The platform must support petabyte-scale storage and query workloads. - The operations team wants to minimize infrastructure management and avoid managing large clusters. - Costs should be predictable and controllable, especially for long-term storage. You are asked to propose an architecture and provisioning approach that balances security, scalability, and operational simplicity. Which design best meets these requirements?

  1. A. Ingest data into regional Cloud Storage buckets using Private Service Connect. Use Dataproc clusters for batch processing and store processed data in Cloud Storage. Provide analysts access via Dataproc HiveServer2 endpoints reachable only over Cloud VPN. Implement IAM controls at the bucket level and use CMEK for encryption. Run ML training on Dataproc using scheduled workflows.
  2. B. Ingest data into regional Pub/Sub topics using VPC Service Controls. Stream data into BigQuery datasets using Dataflow. Store both raw and processed data in BigQuery with table partitioning and clustering. Use BigQuery row-level and column-level security for fine-grained access control. Restrict access to BigQuery via private IP using a VPC peering or Private Service Connect, and enable CMEK for BigQuery. Run scheduled ML training using BigQuery ML and orchestrate with Cloud Composer. (Correct answer)
  3. C. Ingest data into Cloud Storage buckets using signed URLs. Use Dataflow to load data into a regional Cloud SQL instance for structured storage and query. Provide analysts access via a bastion host in a private subnet that connects to Cloud SQL. Implement database-level roles for access control and use CMEK for Cloud SQL. Run ML training on AI Platform (Vertex AI) using data exported from Cloud SQL to Cloud Storage.
  4. D. Ingest data into Pub/Sub over the public internet with TLS. Use Dataflow to write raw data to Cloud Storage and processed data to Bigtable. Provide analysts access via a custom analytics service running on GKE that queries Bigtable and exposes a private HTTP API. Implement IAM at the service level and use CMEK for Cloud Storage and Bigtable. Run ML training on Vertex AI using data exported from Bigtable.

Correct answer: B

Explanation: Option B most effectively balances security, scalability, and operational simplicity for a sensitive, large-scale analytics platform: - **Security and no public internet exposure**: Using VPC Service Controls around Pub/Sub, Dataflow, and BigQuery significantly reduces the risk of data exfiltration and ensures that data access does not require exposure to the public internet. Access to BigQuery via private IP (through VPC peering or Private Service Connect) keeps traffic within Google’s network. - **Fine-grained access control**: BigQuery natively supports **row-level** and **column-level** security, which directly addresses the requirement for tightly controlled and auditable access at both levels. - **Petabyte-scale storage and analytics**: BigQuery is designed for petabyte-scale storage and interactive SQL analytics, with built-in partitioning and clustering to optimize performance and cost. It removes the need to manage clusters, aligning with the operations team’s desire to avoid large cluster management. - **Long-term storage and cost control**: BigQuery’s storage pricing (including automatic transition to long-term storage) provides predictable and controllable costs for 7-year retention, while still enabling performant queries. - **Operational simplicity**: Dataflow is fully managed for streaming ingestion and transformation, and BigQuery ML allows ML training directly in BigQuery without moving data, simplifying the architecture. Cloud Composer provides managed orchestration for scheduled ML and ETL workflows. - **Encryption and compliance**: CMEK for BigQuery supports strict regulatory and compliance requirements for sensitive financial data. Why the other options are suboptimal: - **Option A**: - Relies heavily on Dataproc clusters (managed Hadoop/Spark), which require more operational management (cluster sizing, scaling, patching) than serverless BigQuery and Dataflow. - Storing data only in Cloud Storage and querying via Hive on Dataproc is less suitable for interactive, ad-hoc SQL analytics at petabyte scale compared to BigQuery. - IAM at the bucket level does not provide the required **row-level and column-level** access control granularity. - **Option C**: - Cloud SQL is not designed for petabyte-scale analytics workloads; it has size and performance limits that make it unsuitable for this scale and use case. - Signed URLs for ingestion expose an interface over the public internet, which conflicts with the requirement that data must never be exposed to the public internet. - Fine-grained, auditable row/column security at large scale is more complex and less native in Cloud SQL compared to BigQuery’s built-in mechanisms. - **Option D**: - Ingesting data into Pub/Sub over the public internet, even with TLS, violates the requirement that data must never be exposed to the public internet. - Bigtable is optimized for low-latency key-value and wide-column workloads, not for ad-hoc, interactive SQL analytics. Providing SQL-like analytics would require a custom service layer, increasing complexity and operational burden. - Row-level and column-level access control would need to be implemented in the custom analytics service, which is more error-prone and less auditable than using BigQuery’s native capabilities. Therefore, Option B is the best answer.

Sample Question 3 — Managing and provisioning a cloud solution infrastructure

A global retail company is migrating its on-premises order processing system to Google Cloud. The system consists of a stateless API layer and a stateful order processing engine that runs long-lived workflows (up to 45 minutes). The company has these requirements: - Must support traffic spikes during seasonal sales without manual intervention. - Minimize operational overhead for infrastructure management. - Ensure that failed workflows can be resumed or retried without data loss. - Keep costs predictable and avoid overprovisioning for peak load. - Production workloads must be isolated from development and testing. You are designing the initial deployment architecture. What should you do?

  1. A. Deploy the stateless API layer on Cloud Run with automatic scaling and the order processing engine on a regional GKE cluster using node auto-provisioning. Use separate GKE namespaces for production and non-production workloads, and store workflow state in a regional Cloud SQL instance.
  2. B. Deploy both the stateless API layer and the order processing engine on a single regional GKE cluster with cluster autoscaling. Use separate node pools and namespaces for production and non-production workloads, and store workflow state in a regional Cloud Spanner instance.
  3. C. Deploy the stateless API layer on Cloud Run with automatic scaling and the order processing engine on Compute Engine managed instance groups with autoscaling. Use separate projects for production and non-production, and store workflow state in a regional Cloud SQL instance. (Correct answer)
  4. D. Deploy both the stateless API layer and the order processing engine on Compute Engine managed instance groups with autoscaling. Use instance templates with different machine types for production and non-production, and store workflow state in a zonal Cloud SQL instance.

Correct answer: C

Explanation: Option C best balances operational simplicity, scalability, and cost while meeting the requirements. Reasoning: - Stateless API layer: - Cloud Run is fully managed, scales automatically with request volume, and minimizes operational overhead for the API layer. - Order processing engine: - Long-lived workflows (up to 45 minutes) are not ideal for Cloud Run (request timeouts) or Cloud Functions. Compute Engine managed instance groups (MIGs) with autoscaling are appropriate for long-running, stateful processes that still need elasticity. - State management: - Storing workflow state in a regional Cloud SQL instance provides durability and the ability to resume or retry workflows without data loss. - Environment isolation: - Using separate projects for production and non-production provides strong isolation for security, governance, and quota management, aligning with Google Cloud best practices. - Cost and predictability: - MIG autoscaling allows scaling based on load while avoiding permanent overprovisioning. Cloud Run’s scale-to-zero for non-peak times further optimizes cost. Why not A: - Running the order processing engine on GKE adds operational complexity (cluster management, upgrades, capacity planning) compared to MIGs, which conflicts with the requirement to minimize operational overhead. - Namespaces alone do not provide as strong isolation as separate projects for production vs non-production. Why not B: - GKE for both layers increases operational burden (cluster lifecycle, node management) compared to using Cloud Run + MIGs. - Cloud Spanner is a globally distributed, strongly consistent database that is likely overkill and more expensive than Cloud SQL for a single-region workflow state store, conflicting with cost predictability and avoiding overprovisioning. Why not D: - Running both layers on Compute Engine increases operational overhead compared to using a managed platform (Cloud Run) for the stateless API. - Using a zonal Cloud SQL instance introduces a single-zone failure risk, which is not appropriate for a critical order processing system that must reliably resume workflows. - Environment separation via machine types and templates is weaker than project-level isolation.

Sample Question 4 — Managing and provisioning a cloud solution infrastructure

A financial services company is building a new analytics platform on Google Cloud. The platform ingests transaction data from multiple regions and runs batch risk calculations every hour. Requirements are: - Data must be stored in a way that supports strong access controls and auditability for regulatory compliance. - Compute resources for risk calculations should be provisioned and deprovisioned automatically based on the batch schedule. - The platform must be able to scale to 10x current volume over the next 2 years without major re-architecture. - Operations team wants to minimize manual infrastructure management and avoid managing OS-level security patches. - The solution must support separate environments (dev, test, prod) with clear separation of duties. What should you design?

  1. A. Store raw and processed data in regional Cloud Storage buckets with uniform bucket-level access. Use a regional GKE cluster with node auto-provisioning to run containerized batch jobs on a schedule. Use separate namespaces for dev, test, and prod, and manage access via Kubernetes RBAC.
  2. B. Store raw and processed data in BigQuery datasets with fine-grained access controls. Use scheduled queries and BigQuery reservations to run hourly risk calculations. Use separate projects for dev, test, and prod, and manage access via IAM roles on projects and datasets. (Correct answer)
  3. C. Store raw data in Cloud Storage and processed data in Cloud SQL. Use Compute Engine managed instance groups with autoscaling to run batch jobs triggered by Cloud Scheduler. Use separate folders in a single project for dev, test, and prod, and manage access via IAM on folders.
  4. D. Store raw and processed data in Bigtable. Use Dataflow streaming jobs to continuously compute risk metrics, and scale workers automatically. Use a single project with separate service accounts for dev, test, and prod, and manage access via IAM on service accounts.

Correct answer: B

Explanation: Option B aligns best with the requirements for compliance, scalability, and minimal infrastructure management. Reasoning: - Data storage and compliance: - BigQuery supports fine-grained access controls at the dataset, table, and column level, and has built-in audit logging, which is well-suited for regulatory compliance and separation of duties. - Compute provisioning: - BigQuery scheduled queries and reservations provide serverless, managed compute for batch analytics. There is no need to manage VMs or containers, and scaling is handled by the service. - Scalability: - BigQuery is designed to scale to very large datasets and query volumes without re-architecting the platform. - Operational overhead: - BigQuery is fully managed; there are no OS-level patches or cluster management tasks, satisfying the operations team’s requirement. - Environment separation: - Using separate projects for dev, test, and prod is a best practice for strong isolation and clear separation of duties. IAM at the project and dataset level enables precise access control. Why not A: - GKE requires cluster and node management, including OS patching and upgrades, which conflicts with the desire to avoid OS-level security patch management. - Uniform bucket-level access is coarser than BigQuery’s fine-grained controls and may not meet strict regulatory access control requirements. - Namespaces provide weaker isolation than separate projects. Why not C: - Cloud SQL is not ideal for large-scale analytics workloads and may not scale easily to 10x volume without re-architecture. - Compute Engine MIGs still require OS patching and more infrastructure management. - Using folders in a single project for environment separation is weaker than using separate projects and complicates quota and policy isolation. Why not D: - Bigtable is optimized for low-latency key-value and time-series workloads, not ad-hoc analytics and complex batch queries. - Dataflow streaming jobs imply continuous processing, whereas the requirement is for hourly batch risk calculations. - A single project for all environments weakens separation of duties and isolation compared to separate projects.

Sample Question 5 — Managing and provisioning a cloud solution infrastructure

A healthcare SaaS provider is designing a new multi-tenant platform on Google Cloud to host electronic medical records (EMR) for hospitals in a single country. Requirements include: - Strict data residency: all patient data must remain in a single region. - Each hospital must be logically isolated from others, with separate encryption keys and access controls. - The platform must support zero-downtime deployments and automatic rollback. - The operations team wants a consistent way to provision and update infrastructure across tenants with minimal manual steps. - The application consists of a stateless web/API tier and a relational database per tenant. What should you do to design the infrastructure provisioning and deployment approach?

  1. A. Use a single regional GKE cluster for all tenants. Deploy the web/API tier as separate Kubernetes Deployments per tenant and use a single regional Cloud SQL instance with a separate database per tenant. Use Helm charts for application deployment and kubectl scripts for infrastructure changes.
  2. B. Use a separate project per tenant in the same region. Deploy the web/API tier on Cloud Run and a separate regional Cloud SQL instance per tenant. Use Terraform to provision projects, Cloud Run services, and Cloud SQL instances, and use Cloud Deploy for application rollouts with canary releases. (Correct answer)
  3. C. Use a single project with multiple regional GKE clusters, one per tenant. Deploy the web/API tier and a Cloud SQL instance per tenant in each cluster. Use Deployment Manager to provision clusters and Cloud SQL, and use rolling updates in GKE for zero-downtime deployments.
  4. D. Use a single project and a single regional GKE cluster. Deploy the web/API tier as a multi-tenant application and use a single regional Cloud SQL instance with row-level security per tenant. Use Terraform for infrastructure and GKE rolling updates for deployments.

Correct answer: B

Explanation: Option B best addresses data residency, tenant isolation, and operational consistency. Reasoning: - Data residency: - All resources (Cloud Run and Cloud SQL) are deployed in a single region, satisfying the residency requirement. - Tenant isolation and security: - A separate project per tenant provides strong isolation boundaries for IAM, networking, logging, and quotas. - A separate Cloud SQL instance per tenant allows distinct encryption keys (via CMEK if required) and independent access controls and maintenance windows. - Zero-downtime deployments and rollback: - Cloud Deploy supports progressive delivery strategies (e.g., canary) and automated rollbacks, enabling zero-downtime deployments for the web/API tier. - Operational consistency: - Terraform can declaratively provision and update projects, Cloud Run services, and Cloud SQL instances, enabling repeatable, auditable infrastructure changes across tenants. - Managed services: - Cloud Run and Cloud SQL minimize infrastructure management overhead compared to managing clusters or VMs. Why not A: - A single Cloud SQL instance with multiple databases per tenant weakens isolation; noisy neighbor issues and shared maintenance events can affect all tenants. - A single project and cluster for all tenants complicate per-tenant access control and encryption key separation. - Using kubectl scripts for infrastructure changes is less consistent and less auditable than using an IaC tool like Terraform. Why not C: - Multiple regional GKE clusters contradict the requirement that all data must remain in a single region. - Per-tenant GKE clusters add significant operational overhead (cluster lifecycle, upgrades) compared to using Cloud Run. - Deployment Manager is less flexible and widely adopted than Terraform for complex, multi-project provisioning. Why not D: - Single project and single Cloud SQL instance with row-level security provide weaker isolation than per-tenant projects and instances. - A multi-tenant database increases blast radius for performance and operational issues. - While Terraform and GKE rolling updates help, this design does not meet the requirement for separate encryption keys and strong isolation per hospital as well as option B.

Sample Question 6 — Managing and provisioning a cloud solution infrastructure

A media streaming company is re-architecting its recommendation service on Google Cloud. The service: - Receives user activity events in near real time. - Computes personalized recommendations that must be available to the frontend API with p95 latency under 50 ms. - Must handle unpredictable traffic spikes during popular live events. - Needs to be highly available across zones within a region. - Operations team wants a deployment model that supports blue/green releases and quick rollback with minimal manual intervention. You are designing the infrastructure and deployment strategy for the recommendation service backend. What should you do?

  1. A. Deploy the recommendation service on a regional GKE cluster with multiple node pools across zones. Use a Horizontal Pod Autoscaler based on CPU and custom metrics. Use a regional internal HTTP(S) Load Balancer for traffic and configure blue/green deployments using separate Kubernetes Services and manual traffic switching.
  2. B. Deploy the recommendation service on Compute Engine managed instance groups in multiple zones behind a regional external HTTP(S) Load Balancer. Use autoscaling based on CPU utilization and implement blue/green deployments by updating instance templates and gradually shifting traffic using load balancer URL maps.
  3. C. Deploy the recommendation service on Cloud Run (fully managed) in a single region with minimum instances configured to handle baseline load. Use Cloud Run revisions for blue/green deployments and traffic splitting, and configure autoscaling based on concurrent requests and custom metrics. (Correct answer)
  4. D. Deploy the recommendation service on Cloud Functions triggered by Pub/Sub events. Use multiple functions per recommendation type, and configure additional functions for blue/green deployments. Use IAM conditions to control which function version receives traffic.

Correct answer: C

Explanation: Option C provides a managed, highly available, and operationally simple solution that supports low latency, autoscaling, and blue/green deployments. Reasoning: - Latency and availability: - Cloud Run (fully managed) runs in a region and automatically spreads across zones, providing zonal redundancy. - With appropriate minimum instances, it can meet p95 latency under 50 ms by avoiding cold starts for baseline traffic. - Traffic spikes: - Cloud Run autoscaling based on concurrent requests and custom metrics can handle unpredictable spikes without manual intervention. - Deployment strategy: - Cloud Run revisions natively support blue/green and canary deployments via traffic splitting, with quick rollback by adjusting traffic percentages. - Operational overhead: - Fully managed platform: no cluster or VM management, aligning with the operations team’s desire for minimal manual intervention. Why not A: - GKE requires cluster management, node scaling, and upgrades, increasing operational complexity compared to Cloud Run. - Blue/green via separate Services and manual traffic switching is more complex and error-prone than Cloud Run’s built-in revision traffic splitting. - While it can meet latency and availability requirements, it does not minimize operational overhead as well as Cloud Run. Why not B: - Compute Engine MIGs require OS patching, capacity planning, and instance template management. - Blue/green using instance templates and URL maps is more manual and complex than Cloud Run’s revision-based deployment. - While technically viable, it is less aligned with the goal of minimizing manual intervention and operational complexity. Why not D: - Cloud Functions are event-driven and not ideal for low-latency, synchronous recommendation APIs that must respond within 50 ms. - Managing blue/green via multiple functions and IAM conditions is cumbersome and not a standard pattern for traffic shifting. - Cold starts and function-level granularity make it harder to guarantee consistent low latency under unpredictable spikes compared to Cloud Run.

Sample Question 7 — Managing and provisioning a cloud solution infrastructure

A global retail company is migrating its on-premises order processing system to Google Cloud. The system consists of a stateless API layer and a stateful order-processing worker that runs long-running tasks (up to 45 minutes). The company has these requirements: - Must support sudden traffic spikes during flash sales without manual intervention. - Minimize operational overhead for infrastructure management. - Ensure that a failed worker does not lose in-progress work; tasks must be retried safely. - Keep costs predictable and avoid overprovisioning idle capacity. - Production deployments must be roll-backed quickly if issues are detected. You are designing the target architecture on Google Cloud. What should you do?

  1. A. Deploy the stateless API on Cloud Run with automatic scaling. Use Pub/Sub for task queuing and Cloud Run jobs for the long-running workers, triggered by Pub/Sub push subscriptions. Use Cloud Build for container image builds and Cloud Deploy for progressive rollouts and rollbacks. (Correct answer)
  2. B. Deploy the stateless API on a regional GKE Autopilot cluster with a Horizontal Pod Autoscaler. Use a GKE-managed RabbitMQ deployment for task queuing and a separate worker Deployment for long-running tasks. Use rolling updates with a low maxUnavailable setting for safe rollouts.
  3. C. Deploy the stateless API on a regional managed instance group with autoscaling. Use Cloud Tasks for queuing and a separate managed instance group for workers that pull tasks from Cloud Tasks. Use instance templates and rolling updates for deployment management.
  4. D. Deploy the stateless API on App Engine standard. Use Pub/Sub for task queuing and App Engine flexible environment for the long-running workers. Use App Engine traffic splitting for canary deployments and rollbacks.

Correct answer: A

Explanation: Option A best satisfies the requirements with minimal operational overhead and strong reliability: - **Cloud Run for stateless API**: Fully managed, automatic scaling, no server management, good for sudden traffic spikes and cost efficiency (pay-per-use). - **Pub/Sub for task queuing**: Durable, at-least-once delivery, decouples producers and consumers, supports retries and backoff. - **Cloud Run jobs for long-running workers**: Designed for containerized batch/long-running tasks, supports up to 60 minutes per execution, integrates well with Pub/Sub via push or orchestration, and simplifies worker lifecycle management. If a job fails, it can be retried without losing tasks. - **Cloud Build + Cloud Deploy**: Provide CI/CD, progressive rollouts, and fast rollbacks with low operational overhead. This combination aligns with managed services, operational simplicity, and resilience. It also keeps costs predictable by scaling to zero when idle and scaling up automatically during flash sales. Why the other options are suboptimal: - **B (GKE Autopilot + RabbitMQ)**: Technically valid but higher operational complexity. Managing RabbitMQ (even on GKE) adds operational burden (upgrades, tuning, HA). GKE Autopilot reduces some infra management but still requires cluster and workload configuration. For a simple queue/worker pattern, Pub/Sub + Cloud Run is more aligned with managed, low-ops design. - **C (Managed instance groups + Cloud Tasks)**: Cloud Tasks is not ideal for long-running (45-minute) tasks; it is optimized for short-lived HTTP tasks and has execution time limits and semantics that make long-running processing more complex to manage. MIGs require more capacity planning and OS-level management than Cloud Run. This increases operational overhead and may lead to overprovisioning. - **D (App Engine standard + flexible)**: Mixing App Engine standard and flexible increases complexity (two runtimes, different scaling and deployment models). App Engine flexible is less responsive to sudden spikes and has longer startup times, which is problematic for flash sales. Cloud Run is generally preferred for new container-based workloads due to faster scaling and simpler ops. Therefore, option A provides the best balance of scalability, reliability, cost control, and operational simplicity.

Sample Question 8 — Managing and provisioning a cloud solution infrastructure

A financial services company is building a new analytics platform on Google Cloud. They must ingest transaction data from multiple regions into a central data lake and run batch analytics jobs nightly. Requirements: - Data must be stored in a single region due to regulatory constraints. - The platform must tolerate a zonal failure without data loss. - Storage costs should be minimized while supporting high-throughput batch reads. - The data ingestion pipeline should be simple to operate and easy to evolve. - Nightly analytics jobs will be written in Python and may need to scale to process tens of terabytes. You are designing the storage and compute architecture. What should you do?

  1. A. Store raw and processed data in a regional Cloud Storage bucket. Use Pub/Sub for ingestion and Dataflow for ETL into partitioned Parquet files in Cloud Storage. Run Dataproc clusters on demand for nightly batch jobs reading from Cloud Storage and shut them down after completion. (Correct answer)
  2. B. Store raw data in a multi-region Cloud Storage bucket and processed data in a regional BigQuery dataset. Use Dataflow for ingestion and transformation directly into BigQuery. Run nightly BigQuery scheduled queries for analytics.
  3. C. Store all data in a regional BigQuery dataset with table partitioning. Use Pub/Sub and Dataflow to ingest and transform data directly into BigQuery. Use Dataflow batch jobs for nightly analytics queries reading from BigQuery and writing results back to BigQuery.
  4. D. Store raw data in a regional Cloud Storage bucket and processed data in a regional Bigtable instance. Use Dataflow for ingestion and transformation into Bigtable. Run nightly analytics using a long-running GKE cluster with Spark reading from Bigtable.

Correct answer: A

Explanation: Option A best meets the regulatory, reliability, cost, and operational requirements: - **Regulatory single-region constraint**: A regional Cloud Storage bucket satisfies the requirement to keep data in a single region. - **Zonal failure tolerance**: Regional Cloud Storage is replicated across multiple zones in a region, providing durability and availability across zonal failures. - **Cost-efficient storage with high-throughput batch reads**: Cloud Storage with columnar formats like Parquet is cost-effective for large volumes and supports high-throughput batch reads for analytics. - **Simple ingestion and evolution**: Pub/Sub + Dataflow provides a managed, scalable, and flexible ETL pipeline that can be evolved with new transformations over time. - **Nightly analytics at scale**: On-demand Dataproc clusters allow you to spin up Spark/Hadoop clusters only when needed, process tens of terabytes from Cloud Storage, and then shut down clusters to control costs. This balances performance and cost while using familiar Python-based analytics. Why the other options are suboptimal: - **B (Multi-region Cloud Storage + BigQuery)**: Violates the regulatory requirement to keep data in a single region by using multi-region storage. Also splits raw and processed data across two different storage paradigms, which may be fine, but the multi-region aspect is a hard constraint violation. - **C (All data in BigQuery + Dataflow for analytics)**: BigQuery is excellent for analytics, but using Dataflow for nightly analytics queries on BigQuery is not optimal; BigQuery’s own query engine is more appropriate. Also, storing all raw data directly in BigQuery may be more expensive than using Cloud Storage for raw data, especially if not all raw data needs to be queried frequently. This may not minimize storage costs. - **D (Cloud Storage + Bigtable + GKE Spark)**: Bigtable is optimized for low-latency, high-throughput key-value access, not for large-scale batch analytics. Using a long-running GKE cluster for Spark increases operational overhead (cluster lifecycle, scaling, patching) compared to on-demand Dataproc. This design is more complex and less cost-efficient for nightly batch analytics. Thus, option A provides a compliant, cost-effective, and operationally manageable architecture that meets the stated requirements.

Sample Question 9 — Managing and provisioning a cloud solution infrastructure

A healthcare SaaS provider is designing a new multi-tenant application on Google Cloud. Each tenant has a web application, an API, and a PostgreSQL database. Requirements: - PHI (Protected Health Information) must be stored in a managed database service with automatic backups and point-in-time recovery. - Each tenant’s data must be logically isolated, but the platform team wants to minimize operational overhead and cost. - The application must be able to scale to hundreds of tenants over the next 2 years. - Maintenance windows for database upgrades should be centrally managed and predictable. - The provider must be able to quickly provision new tenants through an automated pipeline. You are designing the database provisioning strategy. What should you do?

  1. A. Create a separate Cloud SQL for PostgreSQL instance per tenant, each with its own database. Use an Infrastructure as Code (IaC) pipeline to provision instances and configure automated backups and point-in-time recovery for each instance.
  2. B. Create a single high-availability Cloud SQL for PostgreSQL instance. Create a separate database and database user per tenant within the same instance. Use IAM and application-level logic to ensure tenant isolation. Manage backups and point-in-time recovery at the instance level.
  3. C. Create a Cloud SQL for PostgreSQL read replica per tenant from a shared primary instance. Use separate databases per tenant on each replica and route tenant-specific traffic to its replica. Use the primary instance only for writes and global reporting.
  4. D. Create a regional AlloyDB for PostgreSQL cluster and a separate database per tenant within the same cluster. Use automated backups and point-in-time recovery at the cluster level. Use an automated provisioning pipeline to create new tenant databases and users. (Correct answer)

Correct answer: D

Explanation: The question asks for a database strategy that balances logical isolation, cost-efficiency, scalability (hundreds of tenants), and predictable maintenance for a healthcare SaaS (PHI). Option D (AlloyDB) is the most suitable for several reasons: 1) AlloyDB is specifically designed for high-scale, enterprise-grade PostgreSQL workloads and handles hundreds of databases within a single cluster more efficiently than standard Cloud SQL. 2) AlloyDB offers a 99.99% availability SLA that *includes* maintenance, making maintenance windows more predictable and less disruptive than Cloud SQL (where maintenance is typically excluded from the SLA). 3) Option D explicitly mentions an 'automated provisioning pipeline,' which is a specific requirement in the prompt. 4) While Cloud SQL (Option B) is also a managed service, AlloyDB's architecture (separated compute and storage) and 'no I/O charges' often provide better price-performance for demanding multi-tenant SaaS applications at this scale. Option A is rejected due to high cost and operational overhead of managing hundreds of instances. Option C is incorrect as read replicas are not a primary isolation strategy for writes.

Sample Question 10 — Managing and provisioning a cloud solution infrastructure

A global retail company is migrating its on-premises order-processing platform to Google Cloud. The platform consists of a stateless API layer and a stateful order-processing worker service. Orders are received from multiple regions worldwide and must be processed within 2 seconds on average. The company has the following requirements: • The platform must handle unpredictable traffic spikes during flash sales without manual intervention. • The architecture must minimize operational overhead for infrastructure management. • The company’s security team requires that only a small, controlled set of engineers can deploy new versions, and all deployments must be auditable. • The finance team wants predictable baseline costs, but is willing to pay more during spikes rather than overprovisioning. • The solution must support blue/green or canary-style rollouts with quick rollback. You are designing the deployment and provisioning strategy for this platform on Google Cloud. Which approach best meets these requirements while aligning with Google Cloud’s Well-Architected Framework?

  1. A. Deploy both the API and worker services on a regional GKE cluster with cluster autoscaling enabled. Use a GitOps tool integrated with Cloud Source Repositories for deployments, and configure Horizontal Pod Autoscalers based on CPU utilization. Use a private cluster with authorized networks for admin access.
  2. B. Deploy the stateless API on Cloud Run (fully managed) with request-based autoscaling, and deploy the worker service on a regional GKE Autopilot cluster with Workload Identity. Use Cloud Build with Cloud Deploy for controlled, auditable progressive rollouts, and restrict deploy permissions via IAM. Use Cloud Monitoring SLOs to tune autoscaling policies. (Correct answer)
  3. C. Deploy both services on managed instance groups with autoscaling based on CPU and request load. Use a custom deployment pipeline running on a bastion host in a private subnet, with firewall rules limiting SSH access to the bastion. Use startup scripts to pull application versions from a private artifact repository.
  4. D. Deploy both services on Cloud Run (fully managed) with maximum concurrency set to 1 for strict isolation. Use Cloud Build triggers on commits to the main branch for automatic deployments, and rely on Cloud Run’s default autoscaling. Allow all developers in the project to deploy to reduce operational bottlenecks.

Correct answer: B

Explanation: Option B best balances performance, cost, security, and operational excellence while leveraging managed services and aligning with the Well-Architected Framework. Analysis of requirements: • Unpredictable traffic spikes without manual intervention → Need elastic, automatic scaling. • Minimize operational overhead → Prefer fully managed or Autopilot services over self-managed infrastructure. • Strict deployment control and auditability → Need IAM-controlled deployment pipeline with audit logs. • Predictable baseline cost, pay more during spikes → Avoid always-on overprovisioning; use autoscaling and managed services with low idle cost. • Support blue/green or canary rollouts with quick rollback → Need first-class deployment strategies. Why B is best: • API on Cloud Run (fully managed): – Stateless HTTP workloads are a strong fit. – Request-based autoscaling handles flash-sale spikes automatically. – No server/cluster management, reducing operational overhead. • Worker on GKE Autopilot: – Autopilot removes node management and right-sizing concerns while still supporting more complex worker patterns (e.g., background processing, queues, sidecars). – Regional cluster improves availability within a region. – Workload Identity provides secure, managed identity for workloads without service account key management. • Cloud Build + Cloud Deploy: – Provides controlled, auditable CI/CD with IAM-based permissions. – Supports progressive delivery (canary/blue-green) and quick rollback. – All deployment actions are logged for compliance. • Cost and performance: – Cloud Run and Autopilot both scale to zero or near-zero for low baseline cost and scale up under load, matching the finance team’s preference. – Cloud Monitoring SLOs help tune autoscaling to maintain the 2-second processing requirement. Why not A: • GKE (standard) with cluster autoscaling: – More operational overhead: you must manage node pools, versions, and capacity planning. – Still viable technically, but less aligned with the requirement to minimize infrastructure management. • GitOps with Cloud Source Repositories: – Can be secure and auditable, but requires more custom tooling and operational ownership than Cloud Deploy’s managed rollout strategies. • Overall, A is technically valid but higher operational burden and more complexity than necessary. Why not C: • Managed instance groups: – Require more manual capacity planning and instance template management than Cloud Run or Autopilot. – Autoscaling is coarser-grained and slower to react than Cloud Run’s request-based scaling. • Custom deployment pipeline on a bastion host: – High operational overhead (patching, securing, monitoring the bastion and custom tooling). – More fragile and less auditable than a managed CI/CD pipeline. • Startup scripts for pulling versions: – Increases deployment complexity and risk; rollbacks are slower and less controlled. Why not D: • Both services on Cloud Run with concurrency=1: – Concurrency=1 can significantly increase cost and may not be necessary for both services. – Worker patterns may require long-running or non-HTTP processing that is less natural on Cloud Run. • Automatic deployments on every commit to main: – Reduces control; conflicts with the requirement that only a small, controlled set of engineers can deploy. – Increases risk of pushing unvetted changes directly to production. • Allowing all developers to deploy: – Violates the security team’s requirement for tightly controlled deployments. Thus, option B most effectively meets the business and technical constraints while using managed services, strong security controls, and operationally simple, scalable infrastructure.

How to Study Google Cloud Architect Managing and provisioning a cloud solution infrastructure

Combine these Google Cloud Architect Managing and provisioning a cloud solution infrastructure 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 Managing and provisioning a cloud solution infrastructure practice test now | 10-question quick start | All GCP PCA domains