Free Google Professional Cloud Architect Practice Test 2026 — GCP PCA Certification Questions

Last updated: June 2026 · Aligned with the current Google Professional Cloud Architect exam · 350+ questions across all 6 domains

This free Google Professional Cloud Architect practice test covers all 6 official GCP PCA exam domains. Each question includes a detailed explanation grounded in real Google Cloud architecture scenarios — perfect for PCA exam prep.

About the Google Professional Cloud Architect Exam

The 6 Google Professional Cloud Architect Exam Domains

GCP Professional Cloud Architect Case Study Practice

The standard exam includes 2 case studies selected from 4 available scenarios, and case-study questions make up 20–30% of the exam. Practice identifying business requirements, constraints, security needs, reliability targets, and cost trade-offs before choosing a Google Cloud design.

Altostrat Media

Media delivery, global scale, data and AI workloads, reliability, and cost-aware architecture decisions.

Cymbal Retail

Retail modernization, customer experiences, analytics, security, resilience, and operational trade-offs.

EHR Healthcare

Healthcare data, compliance, privacy, interoperability, availability, and secure cloud transformation.

KnightMotives Automotive

Automotive data and AI solutions, connected systems, governance, performance, and scalable operations.

Read Mastering Google Professional Cloud Architect Case Study Questions for an exam-day analysis framework and original practice scenarios.

6 Sample Google Cloud Architect Practice Questions

Sample Question 1 — Analyzing and optimizing technical and business processes

A global retail company runs a monolithic e-commerce application on-premises. They are migrating to Google Cloud to reduce operational overhead and improve release velocity. The application has the following characteristics and constraints: - The checkout flow is latency-sensitive and must respond in under 300 ms for 95% of requests from North America and Europe. - Traffic is highly variable, with 10x spikes during flash sales. - The security team requires that payment processing components be isolated from other workloads and that PCI-DSS controls be enforceable and auditable. - The finance team wants predictable monthly costs and visibility into cost drivers per business unit. - The operations team has limited SRE experience and wants to minimize custom automation and complex runbooks. You are asked to propose a target architecture and operational model that optimizes both technical and business processes. Which approach best meets these requirements?

  1. A. Refactor the monolith into multiple microservices and deploy them on a regional GKE cluster in each major geography. Use horizontal pod autoscaling for traffic spikes, separate Kubernetes namespaces for payment services, and custom Prometheus/Grafana stacks for observability and cost allocation. Implement PCI controls through network policies and custom admission controllers.
  2. B. Lift-and-shift the monolith into Managed Instance Groups behind a global external HTTP(S) Load Balancer with autoscaling. Place payment processing instances in a separate MIG and subnet with firewall rules and Cloud Armor policies. Use Cloud Monitoring and Cloud Logging for observability and export billing data to BigQuery for cost analysis by business unit.
  3. C. Refactor the application into a small set of domain-aligned services. Deploy stateless web and catalog services on Cloud Run with global HTTP(S) Load Balancing and Cloud CDN. Deploy payment processing as a separate service on Cloud Run in a dedicated PCI-focused project with VPC Service Controls and tighter IAM. Use Cloud Monitoring, Cloud Logging, and exported billing data to BigQuery with cost labels per service and business unit. (Correct answer)
  4. D. Deploy the monolith as a single containerized application on a multi-regional GKE cluster with cluster autoscaling. Use a service mesh for traffic management and mTLS, and configure network policies to isolate payment components. Use custom scripts to tag resources for cost allocation and build internal dashboards on top of exported logs.

Correct answer: C

Explanation: Option C best balances latency, security, cost visibility, and operational simplicity while aligning with Google Cloud’s Well-Architected Framework. Analysis of Option C (Correct): - **Latency and scalability:** Cloud Run with global HTTP(S) Load Balancing and Cloud CDN provides low-latency access for static and cacheable content to users in North America and Europe. Cloud Run autoscaling handles 10x traffic spikes without complex capacity planning. - **Security and PCI isolation:** Placing payment processing in a **separate service and dedicated project** allows strong isolation boundaries. Using **VPC Service Controls**, tighter IAM, and separate networking for the PCI scope aligns with security-by-design and compliance requirements. This makes PCI-DSS controls more auditable and reduces blast radius. - **Operational simplicity:** Cloud Run is fully managed, reducing the need for deep SRE or Kubernetes expertise. Autoscaling, health checks, and rolling updates are handled by the platform, minimizing custom automation and runbooks. - **Cost predictability and visibility:** Exporting billing data to BigQuery and using **labels per service and business unit** enables detailed cost attribution. Cloud Run’s per-use pricing is transparent, and the ability to break down costs by service and BU supports finance’s needs. - **Process optimization:** Refactoring into a small set of domain-aligned services (not an overly granular microservice mesh) improves release velocity and maintainability without incurring the full complexity of a large microservice architecture. Why other options are suboptimal: A) GKE microservices with custom observability and PCI controls - Technically viable but **operationally complex** for a team with limited SRE experience. Managing GKE, HPA, Prometheus/Grafana, network policies, and admission controllers increases operational burden. - PCI controls via custom Kubernetes constructs are more complex and less straightforward to audit than using project-level isolation and VPC Service Controls. - This option optimizes for flexibility and control, but not for **operational simplicity** and process efficiency. B) Lift-and-shift to Managed Instance Groups - Simpler than GKE, but still requires **instance-level management**, OS patching, and capacity planning. - While MIG autoscaling and global HTTP(S) Load Balancing can handle spikes, the monolith limits independent scaling of payment vs other components. - PCI isolation via separate MIG and subnet is weaker than **project-level isolation** and VPC Service Controls; the PCI scope is not as cleanly separated. - Does not significantly improve release velocity or long-term maintainability; it mostly replicates the existing operational model in the cloud. D) Monolith on multi-regional GKE with service mesh - Multi-regional GKE and service mesh (e.g., mTLS, traffic management) provide strong capabilities but at **high operational complexity**—contrary to the operations team’s constraints. - A single monolith in a large cluster does not provide clean PCI isolation; network policies help but are more complex to manage and audit than separate projects and services. - Custom scripts for tagging and internal dashboards add maintenance overhead compared to using labels and standard billing export to BigQuery. Thus, Option C most effectively optimizes technical and business processes by using managed services, clear security boundaries, and built-in cost and operations tooling, while keeping the architecture and operations model manageable for the existing team.

Sample Question 2 — 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 3 — Designing for security and compliance

A global financial services company is migrating a customer-facing web application handling payment card data to Google Cloud. The application is currently monolithic and runs in a private data center. New regulatory requirements mandate: • PCI DSS compliance and strict segregation of cardholder data • All cardholder data must be encrypted in transit and at rest with customer-managed keys • Access to cardholder data must be tightly controlled, auditable, and follow least privilege • The security team must be able to centrally define and enforce security policies across environments The application will be re-architected into microservices. Some services will handle cardholder data (CHD), while others (e.g., catalog, recommendations) will not. The business wants to minimize operational overhead while enabling rapid feature releases. You need to design a secure architecture on Google Cloud that best meets these requirements. What should you do?

  1. A. Create a single GKE cluster in one project for all microservices. Use Kubernetes namespaces to separate CHD and non-CHD services, and apply Kubernetes NetworkPolicies to restrict traffic. Use Cloud KMS with customer-managed keys for encryption and Cloud Audit Logs for auditing. Manage security policies via Kubernetes admission controllers.
  2. B. Create two separate projects: one for CHD microservices and one for non-CHD microservices. In the CHD project, deploy services on a private GKE cluster with Workload Identity, VPC Service Controls, and Cloud KMS with customer-managed keys. Use separate service accounts with least-privilege IAM roles and enable Cloud Audit Logs and Cloud Logging. Use an organization-level policy to enforce encryption and restrict public IPs. Expose both environments through a global external HTTPS Load Balancer with appropriate routing. (Correct answer)
  3. C. Deploy all microservices on Compute Engine managed instance groups in a single project. Use instance tags and firewall rules to isolate CHD workloads. Use OS-level disk encryption with customer-supplied keys and install a host-based intrusion detection system. Configure Cloud Armor to protect the external endpoints and use Cloud Logging for auditing.
  4. D. Use Cloud Run for all microservices in a single project to minimize operational overhead. Use separate Cloud Run services for CHD and non-CHD workloads and restrict access with IAM. Enable Cloud KMS for encryption and Cloud Audit Logs for auditing. Use a global external HTTPS Load Balancer to route traffic to the appropriate Cloud Run services.

Correct answer: B

Explanation: Option B best aligns with PCI DSS requirements and security-by-design principles while balancing operational overhead and agility. Key reasons B is best: 1. **Segregation of cardholder data** - Separate projects for CHD and non-CHD workloads provide strong administrative and blast-radius isolation, which is more robust and auditable than just logical separation within a single project or cluster. - This aligns with PCI DSS guidance to segment cardholder data environments from other systems. 2. **Defense in depth for CHD workloads** - **Private GKE cluster**: No public control plane endpoint; nodes have no public IPs, reducing exposure. - **Workload Identity**: Maps Kubernetes service accounts to Google service accounts, enabling fine-grained, auditable IAM and avoiding long-lived secrets. - **VPC Service Controls**: Adds a perimeter around CHD data and services to mitigate data exfiltration risks. - **Cloud KMS with CMEK**: Satisfies customer-managed key requirements for encryption at rest. 3. **Least privilege and auditability** - Separate service accounts with least-privilege IAM roles enforce minimal access to CHD data and supporting services. - Cloud Audit Logs and Cloud Logging provide centralized, immutable audit trails for access and administrative actions. 4. **Central policy enforcement** - Organization-level policies (Org Policy) can enforce encryption, restrict public IP usage, and standardize security baselines across both projects, satisfying the requirement for centrally defined and enforced security policies. 5. **Operational balance** - GKE provides a good balance between control (for compliance) and agility (for microservices and rapid releases), while managed services like Cloud KMS, Logging, and Org Policy reduce operational overhead. - A single global HTTPS Load Balancer simplifies external exposure while allowing routing to different backends (CHD vs non-CHD) with consistent security controls. Why the other options are suboptimal: A) Single GKE cluster with namespaces and NetworkPolicies - While technically feasible, relying solely on namespaces for CHD vs non-CHD separation is weaker than project-level isolation and may be harder to demonstrate as strong segmentation to auditors. - Security policy management via Kubernetes admission controllers is more complex and less standardized than using Org Policy and IAM at the organization/project level. - Lacks mention of VPC Service Controls, which are valuable for data exfiltration protection in a PCI context. C) Compute Engine managed instance groups - Using VMs increases operational overhead (OS patching, configuration management, intrusion detection) compared to managed container environments. - Instance tags and firewall rules provide network isolation but do not provide as strong or as easily auditable segmentation as separate projects plus VPC Service Controls. - Host-based controls add complexity and may be necessary in some cases, but this design does not leverage Google Cloud’s higher-level security controls and managed services as effectively. D) Cloud Run for all microservices in a single project - Cloud Run simplifies operations, but a single project for CHD and non-CHD workloads weakens segmentation compared to separate projects. - The scenario explicitly calls out strict segregation of cardholder data; project-level isolation is a stronger, more auditable control than just separating services within one project. - The answer does not mention additional controls like VPC Service Controls or private networking for CHD workloads, which are important in a PCI context. Therefore, option B provides the most appropriate architecture for PCI DSS compliance, strong segregation, centralized policy enforcement, and manageable operational overhead.

Sample Question 4 — Ensuring solution and operations excellence

A global retail company runs its e-commerce platform on Google Cloud. The platform is a set of microservices deployed on GKE in a single production cluster in us-central1. The company has the following requirements: - The platform must meet a 99.95% availability SLO for customer-facing APIs. - Releases must be frequent (multiple times per day) with minimal customer impact. - The operations team wants to reduce manual intervention during rollouts and rollbacks. - Compliance requires that any production-impacting change be auditable and traceable to an approved change request. - The company wants to avoid doubling infrastructure costs if possible. You are asked to improve the deployment and operations strategy while meeting these requirements. What should you do?

  1. A. Implement blue/green deployments by creating a second production GKE cluster in a different region. Route traffic using Cloud Load Balancing with weighted backends, and switch all traffic to the new cluster after validation. Use a change management tool outside of Google Cloud to track approvals.
  2. B. Use GKE in the existing region with canary deployments managed by a GitOps pipeline (e.g., Cloud Build + Cloud Deploy) that progressively shifts traffic using a service mesh (e.g., Anthos Service Mesh). Integrate the pipeline with Cloud Audit Logs and an external approval step that gates production promotions. (Correct answer)
  3. C. Enable GKE Autopilot and use rolling updates with maxUnavailable set to 0 and maxSurge set to 1. Require manual kubectl-based rollbacks for failed releases and store change approvals in a shared document repository for audit purposes.
  4. D. Create separate GKE clusters for staging and production in the same region. Use manual image promotion from staging to production and perform rolling updates with a 50% surge. Capture change approvals in a ticketing system that is periodically exported to Cloud Storage for audit.

Correct answer: B

Explanation: Option B best balances availability, deployment safety, operational excellence, and compliance. Analysis against requirements: - **99.95% availability SLO**: - Canary deployments with a service mesh allow gradual traffic shifting and fast, automated rollback on error budgets or SLO violations, minimizing blast radius and downtime. - Staying in a single region is acceptable for 99.95% if the cluster and application are designed for high availability within that region. - **Frequent releases with minimal impact**: - Canary + progressive delivery (Cloud Deploy or similar) is designed for high-frequency, low-risk releases. - Service mesh can provide traffic splitting, health-based routing, and observability to detect issues early. - **Reduced manual intervention**: - A GitOps-style pipeline automates build, test, deploy, and rollback based on metrics or release policies. - This reduces human error and operational toil, aligning with operational excellence. - **Compliance and auditability**: - Integrating approvals into the CI/CD pipeline and capturing events in Cloud Audit Logs provides a traceable change history. - The external approval step (e.g., via ticketing or approval gate) ensures that production changes are tied to an approved request. - **Cost considerations**: - This approach reuses the existing cluster and region, avoiding the cost of fully duplicated production environments. Why the other options are suboptimal: - **Option A**: - Blue/green with a second production cluster in another region significantly increases infrastructure cost (compute, networking, data replication) and operational complexity. - While it improves resilience, the question explicitly states the company wants to avoid doubling infrastructure costs if possible. - Also, relying on a change management tool entirely outside Google Cloud without tight integration into the deployment pipeline weakens end-to-end traceability of *what* was deployed *when* and *by which pipeline run*. - **Option C**: - GKE Autopilot simplifies operations but does not by itself provide safe, progressive rollouts. - Rolling updates with manual kubectl-based rollbacks are error-prone and increase MTTR during incidents. - Storing approvals in a shared document repository is weak from an audit and traceability standpoint; it’s not tightly coupled to the actual deployments. - This approach does not significantly reduce manual intervention and does not leverage advanced deployment strategies. - **Option D**: - Separate staging and production clusters are good practice, but the deployment strategy is still largely manual (manual image promotion, manual rolling updates). - A 50% surge increases risk during rollout and can cause resource pressure or transient instability. - Exporting ticketing data to Cloud Storage is passive and not integrated with the deployment pipeline; it provides weaker operational control and traceability compared to pipeline-gated approvals. Therefore, Option B provides the best combination of high availability, safe and frequent releases, automation, and compliance-aligned auditability without unnecessarily doubling infrastructure costs.

Sample Question 5 — 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 6 — Managing implementation

Your company is migrating a mission-critical order processing system from an on-premises data center to Google Cloud. The application consists of a stateless REST API layer and a stateful order-processing worker service that consumes messages from a queue and writes to a relational database. The business requires: • Zero data loss for processed orders • RPO of 0 and RTO of 15 minutes • Ability to deploy new versions weekly with minimal operational overhead • Strict separation of duties: developers must not have direct production database access • Compliance with regional data residency: all data must remain in the same region You are leading the implementation and must design the deployment and rollout strategy for production. Which approach best meets the requirements while minimizing operational complexity?

  1. A. Deploy the API and worker services on a regional GKE cluster with a single primary Cloud SQL instance in the same region. Use a blue/green deployment strategy with two identical GKE namespaces (blue and green) pointing to the same Cloud SQL instance. Switch traffic using an external HTTP(S) Load Balancer. Restrict database access using IAM database authentication and separate service accounts for each namespace.
  2. B. Deploy the API and worker services on Cloud Run (fully managed) in the same region, backed by a regional Cloud SQL instance with high availability enabled. Use Cloud Build to implement canary deployments by gradually shifting traffic between revisions. Use separate service accounts for API and worker services, and enforce IAM roles so only the worker service account can write to the database. Use point-in-time recovery for Cloud SQL. (Correct answer)
  3. C. Deploy the API on Cloud Run and the worker service on a zonal GKE cluster in the same region. Use a single-zone Cloud SQL instance with automated backups. Implement rolling updates for both services and use Cloud SQL IAM authentication. Allow developers read-only access to the production database for troubleshooting via IAM roles.
  4. D. Deploy both services on managed instance groups behind a regional HTTP(S) Load Balancer. Use a regional persistent disk–backed MySQL instance on Compute Engine configured with asynchronous replication to a secondary instance in the same region. Implement blue/green deployments by creating separate instance templates and switching the backend service. Manage access control using OS Login and database user accounts.

Correct answer: B

Explanation: Option B best aligns with the requirements and emphasizes managed services, operational simplicity, and compliance. Analysis of requirements: - Zero data loss for processed orders & RPO = 0: Requires durable, strongly consistent storage with point-in-time recovery and HA for the database. Cloud SQL with HA and PITR in a single region satisfies this, assuming the region itself is available. - RTO of 15 minutes: Managed services with automatic failover and no need to manually recreate infrastructure help meet this. Cloud Run and Cloud SQL HA support fast recovery. - Weekly deployments with minimal operational overhead: Cloud Run revisions and Cloud Build–driven canary deployments reduce operational burden compared to managing clusters or VMs. - Strict separation of duties: IAM-based access control with distinct service accounts and least privilege is straightforward with Cloud Run + Cloud SQL IAM. - Regional data residency: All services and data are deployed in a single region. Why B is best: - Cloud Run (fully managed) removes cluster/VM management, reducing operational complexity. - Cloud SQL HA in the same region with point-in-time recovery supports RPO 0 (within the region) and rapid recovery. - Canary deployments via Cloud Build and Cloud Run traffic splitting provide controlled rollouts with minimal downtime. - Separate service accounts for API and worker services allow fine-grained IAM: for example, API can read, worker can read/write, and developers can be restricted from direct DB access. - All resources are regional, satisfying data residency. Why not A: - GKE adds operational overhead (cluster management, upgrades, node pools) compared to Cloud Run, conflicting with the requirement for minimal operational overhead. - Blue/green namespaces sharing the same database can work, but managing two full environments in a cluster is more complex than using Cloud Run revisions and traffic splitting. - While IAM DB auth and service accounts help with separation of duties, this design is more complex to operate and maintain than necessary. Why not C: - Uses a zonal GKE cluster and a single-zone Cloud SQL instance, which weakens availability and RTO. A zonal failure could violate the 15-minute RTO and RPO 0 objective. - Automated backups without HA and PITR are less robust for RPO 0; recovery from backups can exceed the RTO and may lose recent transactions. - Explicitly grants developers read-only access to production DB, violating the strict separation of duties requirement. Why not D: - Running MySQL on Compute Engine with regional PD and custom replication significantly increases operational complexity (patching, backups, failover logic) compared to Cloud SQL. - Asynchronous replication risks data loss on failover, conflicting with RPO 0 and zero data loss for processed orders. - Managing access with OS Login and DB user accounts is more manual and error-prone than IAM-based access with managed services. - Blue/green via instance templates and backend switching is viable but more operationally heavy than Cloud Run’s built-in revision management. Therefore, option B provides the best balance of reliability, security, compliance, and operational simplicity for managing the implementation.

Start the Quick GCP PCA Practice Exam

Use the 10-question mixed-domain quick start for a fast readiness check across all six exam domains.

Recommended 6-Week GCP PCA Study Plan

  1. Week 1: Designing and planning cloud solution architecture.
  2. Week 2: Managing and provisioning cloud infrastructure.
  3. Week 3: Security, compliance, identity, and encryption.
  4. Week 4: Technical and business process optimization.
  5. Week 5: Implementation management and operations excellence.
  6. Week 6: Timed mock exams and review of all four available standard-exam case studies.

GCP PCA Exam Cost, Format, and Renewal

The standard exam costs $200 USD plus applicable taxes, contains 50–60 multiple-choice and multiple-select questions, and lasts 2 hours. The certification is valid for 2 years. Eligible holders can renew through the standard exam, a shorter renewal exam, or designated Google Skills courses or skill badges.

Verify current Professional Cloud Architect exam and renewal details with Google Cloud.

Professional Cloud Architect vs Associate Cloud Engineer

The Professional Cloud Architect (PCA) is Google's flagship design-focused certification for senior cloud professionals, while the Associate Cloud Engineer (ACE) is the entry-level, deployment-focused credential. If you're new to Google Cloud, start with the ACE to build hands-on fluency, then move up to the PCA. Experienced architects can target PCA directly — just be ready for the case-study-driven design questions.

Google Professional Cloud Architect FAQ

What is the Google Professional Cloud Architect exam?

The Google Professional Cloud Architect exam validates your ability to design, develop, and manage secure, scalable, highly available, cost-effective solutions on Google Cloud. The standard exam has 50–60 questions over 2 hours and includes case studies.

How much does the Google Professional Cloud Architect exam cost?

The standard exam registration fee is $200 USD plus applicable taxes. Google lists online-proctored and testing-center delivery options.

How do Google Professional Cloud Architect case studies work?

Each standard exam includes 2 case studies per standard exam, selected from 4 available case studies. Case-study questions make up 20–30% of the standard exam and test how you apply architecture knowledge to a realistic business situation.

Which case studies should I review for the GCP PCA exam?

Google's current standard exam guide lists Altostrat Media, Cymbal Retail, EHR Healthcare, KnightMotives Automotive.

How long is the Professional Cloud Architect certification valid, and how can I renew it?

The certification is valid for 2 years. Eligible holders can renew through the standard exam, a shorter renewal exam, or designated Google Skills courses or skill badges.

What passing score do I need?

Google does not publish a passing score and reports the result as pass or fail. Use practice-test performance to find weak areas rather than treating an unofficial percentage as Google's cutoff.

How much experience should I have before taking the exam?

Google recommends 3+ years of industry experience, including 1+ year designing and managing solutions on Google Cloud.

Are these Google Professional Cloud Architect practice tests free?

Yes. FlashGenius offers free domain practice tests and a 10-question mixed-domain quick start with scoring and explanations, with no signup required.

Start the free Google Cloud Architect quick practice test now | All GCP PCA domains | Get the full GCP PCA question bank