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

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 — Analyzing and optimizing technical and business processes

A financial services company runs a portfolio risk analytics platform on Google Cloud. The platform consists of: - A batch computation engine that runs nightly risk calculations on large datasets. - An API that provides intraday risk snapshots to internal trading desks. Current architecture: - Batch jobs run on a large Compute Engine managed instance group that is overprovisioned to meet peak month-end workloads. - The API runs on a separate managed instance group behind a regional HTTP(S) Load Balancer. - All data is stored in a single regional Cloud SQL instance. Business and technical constraints: - Regulatory requirements mandate that all data and processing remain in a single region. - The risk calculations must complete within a 4-hour nightly window, including month-end peaks. - The API must meet a 99.9% availability SLO with p95 latency under 200 ms for internal users in the same region. - The finance team reports that the environment is significantly underutilized outside the nightly batch window and wants to reduce costs without compromising SLOs. - The operations team wants to reduce manual capacity planning and simplify incident response. You are asked to redesign the architecture and operational model to optimize cost and operational efficiency while meeting the constraints. Which approach should you recommend?

  1. A. Move the batch computation engine to a regional GKE cluster with cluster autoscaling and use preemptible node pools for batch workloads. Keep the API on the existing managed instance group for stability. Retain Cloud SQL as the single data store. Use custom autoscaling policies to scale the cluster up before the nightly window and down afterward.
  2. B. Migrate both the batch engine and the API to a single regional GKE cluster. Use separate node pools: one with preemptible VMs for batch jobs and one with regular VMs for the API. Use horizontal pod autoscaling for the API and a Kubernetes job scheduler for batch. Keep Cloud SQL as the backend and enable high availability for the database.
  3. C. Move the batch computation engine to Cloud Dataflow using autoscaling and flexible resource scheduling. Keep the API on a smaller managed instance group with autoscaling based on request latency. Migrate the data from Cloud SQL to BigQuery for batch analytics while keeping a smaller Cloud SQL instance for transactional needs. Use Cloud Monitoring SLOs and alerting for both batch completion time and API latency. (Correct answer)
  4. D. Refactor the batch engine into Cloud Functions triggered by Cloud Scheduler and Pub/Sub, each processing a subset of the data. Move the API to Cloud Run with concurrency enabled for cost efficiency. Keep Cloud SQL as the single data store and enable read replicas to offload batch reads from the primary instance.

Correct answer: C

Explanation: Option C provides the best balance of cost optimization, performance, and operational simplicity while respecting regulatory and SLO constraints. Analysis of Option C (Correct): - **Cost optimization for batch:** Moving the batch computation to **Cloud Dataflow** leverages autoscaling and managed infrastructure. Dataflow can scale resources up during the nightly window (including month-end peaks) and scale down to zero afterward, eliminating overprovisioned Compute Engine instances. - **Performance and batch window:** Dataflow is designed for large-scale batch processing and can be tuned to meet the 4-hour completion window. Autoscaling and parallelism can be adjusted based on job characteristics. - **API SLOs:** Keeping the API on a **smaller managed instance group with autoscaling based on latency** maintains control over performance and availability (99.9% SLO, p95 < 200 ms) while reducing baseline capacity. - **Data architecture optimization:** Moving analytical workloads to **BigQuery** separates analytical and transactional concerns. BigQuery is optimized for large-scale analytics, improving batch performance and simplifying schema evolution. Keeping a smaller Cloud SQL instance for transactional needs reduces cost and risk for the API. - **Operational excellence:** Dataflow and BigQuery are fully managed, reducing operational overhead. Using **Cloud Monitoring SLOs and alerting** for both batch completion time and API latency aligns with the Well-Architected Framework’s reliability and operations pillars. - **Regulatory constraint:** All services (Dataflow, BigQuery, Cloud SQL, MIG) can be configured to run in a single region, satisfying data residency requirements. Why other options are suboptimal: A) Batch on GKE with preemptible nodes, API on existing MIG - GKE with preemptible nodes can reduce batch costs, but introduces **cluster management complexity** and requires careful handling of preemptions to meet the 4-hour window. - Custom autoscaling policies and pre-scaling the cluster before the batch window add operational overhead and manual tuning. - Retaining Cloud SQL as the single store for both transactional and heavy analytical workloads can become a bottleneck and limit scalability. B) Both batch and API on a single GKE cluster - Consolidating onto GKE can improve utilization, but significantly **increases operational complexity** (cluster operations, node pools, HPA, job scheduling) for the operations team. - Running both latency-sensitive API and heavy batch workloads on the same cluster increases the risk of resource contention, which can threaten the API’s 99.9% SLO and latency targets unless carefully isolated and tuned. - Still relies on Cloud SQL as the single backend, which is not ideal for large-scale analytics. D) Batch via Cloud Functions and API on Cloud Run - Cloud Functions are not ideal for **large, long-running batch computations** on large datasets due to execution time limits, concurrency model, and orchestration complexity. - Orchestrating a large portfolio risk calculation via many functions and Pub/Sub increases complexity and risk of partial failures, making it harder to guarantee the 4-hour completion window. - Keeping all analytics on Cloud SQL, even with read replicas, is not optimal for large-scale batch analytics and can still stress the database. Therefore, Option C most effectively optimizes technical and business processes: it uses the right managed services for batch (Dataflow, BigQuery), keeps the API simple and autoscaled, reduces overprovisioning, and improves observability and SLO-based operations.

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

A healthcare analytics company processes sensitive patient data for multiple hospital customers on Google Cloud. They must comply with HIPAA and each hospital’s data residency requirements. New requirements include: • All Protected Health Information (PHI) must remain within the customer’s chosen region • Strong tenant isolation: no hospital’s data may be accessible by another hospital • Centralized security governance and monitoring by the company’s security team • Minimal operational overhead for onboarding new hospital tenants • Ability to securely expose analytics dashboards to each hospital over the internet You are designing a multi-tenant architecture for a new analytics platform that will ingest PHI, store it, and serve dashboards. The platform will use managed services wherever possible. What should you do to best meet these requirements?

  1. A. Create a single project per region and store all hospitals’ PHI in separate datasets in a regional BigQuery instance. Use dataset-level IAM to restrict access per hospital. Use a single regional GKE cluster per region to host all tenants’ analytics services, and use Kubernetes namespaces and NetworkPolicies for isolation. Use a global external HTTPS Load Balancer to route traffic to the appropriate tenant dashboards.
  2. B. Create a single global project and use multi-regional BigQuery datasets for PHI. Use row-level security and column-level security to isolate each hospital’s data. Deploy analytics services on Cloud Run in multiple regions and use IAM conditions to restrict access per hospital. Use a global external HTTPS Load Balancer with Cloud Armor to protect the endpoints.
  3. C. Create a separate project per hospital tenant, in the tenant’s required region. In each project, use regional BigQuery datasets for PHI and regional Cloud Storage buckets for raw data, both with CMEK. Use per-project service accounts and least-privilege IAM. Use VPC Service Controls per project to limit data exfiltration. Expose dashboards via regional HTTPS Load Balancers with Cloud Armor. Centralize security governance and monitoring using an organization-level security project with Cloud Logging sinks, Cloud Monitoring, and Security Command Center. (Correct answer)
  4. D. Create a shared VPC host project per region and use multiple service projects, one per hospital, attached to the shared VPC. Store PHI in a single regional BigQuery dataset per region, with table-level IAM per hospital. Deploy analytics services on a single regional GKE cluster per region shared by all tenants. Use Org Policy to restrict resource locations and Cloud Armor for external protection. Aggregate logs in a central logging project.

Correct answer: C

Explanation: Option C provides the strongest tenant isolation, clear data residency guarantees, and centralized governance with manageable operational overhead. Why C is best: 1. **Data residency and regionality** - Per-tenant projects created in the tenant’s required region, with **regional BigQuery datasets** and **regional Cloud Storage buckets**, ensure PHI remains in the specified region. - This aligns with both HIPAA and hospital-specific residency requirements. 2. **Strong tenant isolation** - A **separate project per hospital** provides clear administrative, billing, and security boundaries. This is stronger and easier to reason about than logical isolation within a single project. - Per-project IAM and service accounts minimize the risk of cross-tenant access and simplify demonstrating isolation to auditors. 3. **Security and compliance controls** - **CMEK** for BigQuery and Cloud Storage supports customer-managed encryption requirements and fine-grained key control. - **VPC Service Controls per project** add a strong perimeter to reduce data exfiltration risk, which is critical for PHI. - **Cloud Armor** on regional HTTPS Load Balancers provides protection for internet-facing dashboards (e.g., WAF, IP-based rules). 4. **Centralized governance and monitoring** - An **organization-level security project** with log sinks from all tenant projects centralizes: - Cloud Logging and Monitoring - Security Command Center findings - This allows the security team to maintain a unified view of security posture and incidents while preserving tenant isolation. 5. **Operational overhead vs scalability** - While per-tenant projects introduce some overhead, this can be automated with infrastructure-as-code and project factory patterns. - The trade-off is justified for PHI and strict tenant isolation requirements. Why the other options are suboptimal: A) Single project per region with shared BigQuery and GKE - Dataset-level IAM and namespaces/NetworkPolicies provide logical isolation but not the strong administrative and blast-radius isolation that separate projects offer. - A compromise or misconfiguration in the shared project or cluster could impact multiple hospitals, which is risky for PHI. - Harder to prove strict tenant isolation to auditors compared to project-per-tenant. B) Single global project with multi-regional datasets - Multi-regional BigQuery datasets conflict with strict data residency requirements; PHI may be stored or processed outside the mandated region. - Row-level and column-level security are powerful but still operate within a single dataset and project, which is weaker isolation than separate projects. - A global project also complicates enforcement of per-tenant regional constraints. D) Shared VPC host per region with service projects and shared BigQuery - Service projects per tenant improve isolation somewhat, but **storing PHI in a single regional BigQuery dataset per region** shared across hospitals weakens data isolation. - Table-level IAM is less granular and more error-prone for strict multi-tenant PHI isolation than per-project datasets. - A shared GKE cluster per region for all tenants again introduces cross-tenant risk at the cluster level. Option C most directly satisfies: regional residency, strong tenant isolation, centralized governance, and use of managed services, while following Google Cloud’s security and compliance best practices for sensitive healthcare data.

Sample Question 7 — 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 8 — Ensuring solution and operations excellence

A financial services company is migrating a critical payment-processing application to Google Cloud. The application consists of stateless API services and a stateful transaction-processing component. Current on-premises operations challenges include: - Inconsistent backup and restore procedures across environments - Manual runbooks for incident response - Difficulty proving RPO/RTO compliance to auditors New requirements for the cloud deployment include: - RPO of 5 minutes and RTO of 30 minutes for the transaction data - End-to-end encryption in transit and at rest, with customer-managed keys - Clear, testable disaster recovery (DR) procedures with minimal operational overhead - Ability to demonstrate to auditors that DR is regularly tested and that changes to DR configuration are controlled and auditable - Cost must be optimized; a fully active-active multi-region architecture is not required You are designing the DR and operations strategy. What should you do?

  1. A. Deploy the application in a single region using regional managed instance groups and regional persistent disks. Configure scheduled snapshots to another region and document manual DR steps in runbooks stored in a version-controlled repository. Use CMEK for disks and rely on Cloud Audit Logs for snapshot operations.
  2. B. Deploy the stateless APIs on Cloud Run in one region and the stateful component on a regional Cloud SQL instance with high availability. Enable point-in-time recovery and cross-region read replicas. Use CMEK for Cloud SQL, configure automated backups and DR runbooks, and periodically export Cloud SQL logs to Cloud Storage for audit.
  3. C. Deploy the application in one primary region and one DR region. Use Cloud SQL with CMEK in the primary region and a cross-region read replica in the DR region. Automate DR failover and validation using Infrastructure as Code and a CI/CD pipeline that runs scheduled DR drills (including controlled failover and rollback). Store DR pipeline definitions and policies in a version-controlled repository and rely on Cloud Audit Logs and Cloud Monitoring dashboards to demonstrate DR tests and compliance. (Correct answer)
  4. D. Deploy the application on GKE in a single region with regional persistent disks and configure asynchronous replication to another region using application-level logic. Use CMEK for disks and configure a Cloud Function that triggers DR failover scripts stored in Cloud Storage. Provide auditors with logs from the Cloud Function and application logs as evidence of DR capability.

Correct answer: C

Explanation: Option C best addresses RPO/RTO, security, DR testability, and operational excellence with controlled cost. Analysis against requirements: - **RPO 5 minutes / RTO 30 minutes**: - Cloud SQL with a cross-region read replica provides near-real-time replication, typically meeting a 5-minute RPO under normal conditions. - Having a warm standby in a DR region plus automated failover procedures supports a 30-minute RTO. - **Encryption and CMEK**: - Cloud SQL supports CMEK, satisfying customer-managed encryption requirements for data at rest. - Standard Google Cloud networking and load balancing can ensure encryption in transit. - **Clear, testable DR procedures with minimal overhead**: - A defined primary and DR region with a cross-region replica is simpler and cheaper than full active-active. - Automating DR failover and validation with Infrastructure as Code (e.g., Terraform) and CI/CD (e.g., Cloud Build/Cloud Deploy) reduces manual steps and human error. - Scheduled DR drills validate that RPO/RTO targets are achievable and keep runbooks current. - **Auditability and compliance**: - Storing DR pipeline definitions and policies in version control provides change history and approvals. - Cloud Audit Logs capture changes to Cloud SQL, networking, and IAM. - Cloud Monitoring dashboards and logs from scheduled DR drills provide concrete evidence to auditors that DR is regularly tested and that changes are controlled. - **Cost optimization**: - Primary + DR region with a read replica is more cost-effective than full active-active while still meeting the stated RPO/RTO. Why the other options are suboptimal: - **Option A**: - Snapshots to another region are periodic and may not reliably meet a 5-minute RPO, especially under load. - Manual DR steps, even if documented, are error-prone and may not consistently meet a 30-minute RTO. - While version-controlled runbooks and Audit Logs help, the lack of automated DR drills and failover reduces operational excellence and makes it harder to prove RPO/RTO in practice. - **Option B**: - Cloud SQL with HA and cross-region read replicas is good, but the scenario only mentions enabling point-in-time recovery and cross-region read replicas, not a clear, automated DR failover process. - Relying primarily on runbooks and periodic log exports is weaker from an audit and operational standpoint than automated, scheduled DR drills. - There is no explicit mechanism to regularly test DR end-to-end or to tightly couple DR configuration changes with approvals and version control. - **Option D**: - Application-level asynchronous replication is complex to implement and maintain, increasing operational risk. - It is harder to guarantee a 5-minute RPO consistently compared to managed database replication. - Triggering DR via a Cloud Function that runs scripts from Cloud Storage is brittle and less transparent than a CI/CD-based DR pipeline with version control and approvals. - Evidence for auditors is limited to logs and ad-hoc scripts rather than structured, repeatable DR drills and pipeline histories. Therefore, Option C provides the strongest alignment with the company’s RPO/RTO, security, DR testability, auditability, and cost optimization requirements while embodying Google Cloud’s Well-Architected principles for reliability and operational excellence.

Sample Question 9 — 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 10 — 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.

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.

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