Free Google Cloud Architect Designing for security and compliance Practice Test 2026 — GCP PCA Questions

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

This free Google Cloud Architect Designing for security and compliance practice test covers designing secure, compliant Google Cloud solutions — IAM, identity federation, encryption with Cloud KMS, network security controls, and regulatory compliance. Each question includes a detailed explanation with real Google Cloud context — perfect for GCP PCA exam prep.

Key Topics in Google Cloud Architect Designing for security and compliance

10 Free Google Cloud Architect Designing for security and compliance Practice Questions with Answers

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

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

A multinational healthcare provider is migrating its patient portal to Google Cloud. The portal will be used by patients in the US and EU and must comply with HIPAA and GDPR. Requirements: • PHI and PII must never leave their originating region (US or EU). • Operations teams want a single global DNS entry and a unified deployment pipeline. • The security team mandates centralized policy enforcement and audit logging. • Latency must be minimized for users in each region. • The solution should minimize operational overhead while allowing independent regional failover. You need to design the high-level architecture for the web tier and data storage. What should you do?

  1. A. Deploy a single regional GKE cluster in us-central1 hosting the portal for all users. Store all PHI and PII in a multi-region Cloud SQL instance in us-central (US). Use Cloud Armor and Cloud CDN with global external HTTP(S) Load Balancing to front the application. Configure VPC Service Controls around the project.
  2. B. Deploy two separate regional Cloud Run services (one in a US region, one in an EU region) behind a global external HTTP(S) Load Balancer with geo-based routing. Store PHI and PII in separate regional Cloud SQL instances in each region. Use organization policies and VPC Service Controls to restrict data egress and centralize audit logging in a dedicated security project. (Correct answer)
  3. C. Deploy a single multi-region Cloud Run service in us-central (US) and use Cloud Spanner multi-region instance spanning US and EU for PHI and PII. Use global external HTTP(S) Load Balancing and Cloud Armor. Configure CMEK for all storage and centralize logs in a US logging project.
  4. D. Deploy separate GKE clusters in a US region and an EU region, each fronted by a regional internal HTTP(S) Load Balancer. Use a single multi-region Cloud SQL instance in us-central (US) for PHI and PII. Use Cloud VPN from EU to US for database access and centralize logs in a global logging project.

Correct answer: B

Explanation: Option B best satisfies data residency, compliance, and operational requirements while keeping complexity manageable. • Data residency and compliance: Separate regional Cloud SQL instances in US and EU ensure PHI/PII does not leave its originating region, aligning with HIPAA and GDPR. Geo-based routing at the global load balancer directs users to the correct regional backend. • Latency: Regional Cloud Run services close to users minimize latency. • Operational simplicity: Cloud Run is fully managed, reducing ops overhead compared to GKE. A single global external HTTP(S) Load Balancer with geo-based routing supports one global DNS name and unified deployment patterns (e.g., same CI/CD pipeline with region-specific configs). • Security and centralized control: Organization policies and VPC Service Controls around the projects containing Cloud Run and Cloud SQL, with logs exported to a dedicated security project, support centralized policy enforcement and audit. • Independent regional failover: Each region has its own stack; failover can be managed at the load balancer and DNS level, without cross-region PHI replication. Why others are suboptimal: A: Single-region GKE and multi-region Cloud SQL in US violate EU data residency because EU PHI/PII would be stored in US. Also, a single region is a resilience risk for a multinational healthcare provider. C: A single multi-region Cloud Run service in US and a Spanner instance spanning US and EU means data can move across regions within the Spanner configuration. This complicates strict residency guarantees (especially for GDPR) and centralizing logs only in US may conflict with EU data residency expectations. D: Separate GKE clusters increase operational overhead versus managed Cloud Run. A single multi-region Cloud SQL instance in US again violates EU data residency. Using VPN for EU-to-US database access adds latency and complexity and still doesn’t meet the requirement that PHI/PII never leave the originating region. Therefore, B is the best architecture given the compliance, latency, and operational constraints.

Sample Question 4 — Designing for security and compliance

A financial services company is building a new risk analytics platform on Google Cloud. The platform ingests sensitive trading data from on-premises systems into BigQuery for analysis. Requirements: • Regulatory rules require that only a small group of data scientists can query raw trading data. • Other internal teams can only access pre-aggregated, anonymized views. • Data must not be exfiltrated to personal Google accounts or external projects. • The security team wants to minimize custom code for access control and rely on declarative policies. • The platform must support future onboarding of new datasets with similar controls. You need to design a secure access pattern for BigQuery. What should you do?

  1. A. Create two separate BigQuery datasets: one for raw data and one for anonymized views. Grant the data scientists BigQuery Data Owner on the raw dataset and other teams BigQuery Data Viewer on the anonymized dataset. Use VPC Service Controls around the project to prevent exfiltration.
  2. B. Store all data in a single BigQuery dataset. Use column-level security to restrict access to sensitive columns for non-data-scientist groups. Use VPC Service Controls and an organization policy that restricts adding external principals to IAM policies.
  3. C. Store raw data in a restricted dataset and create authorized views in a separate dataset for anonymized access. Grant data scientists access to the raw dataset and other teams access only to the dataset containing authorized views. Enforce VPC Service Controls around the analytics perimeter and use organization policies to prevent sharing with external identities. (Correct answer)
  4. D. Store raw data in Cloud Storage and load it into BigQuery temporary tables only when needed. Use a custom proxy service that authenticates users and rewrites queries to enforce anonymization rules. Use VPC Service Controls around the project and Cloud Armor to protect the proxy.

Correct answer: C

Explanation: Option C aligns best with the requirements and uses native BigQuery and Google Cloud security features in a scalable, declarative way. • Strict separation of raw vs anonymized access: Raw data is in a restricted dataset; anonymized access is via authorized views in a separate dataset. Only data scientists are granted access to the raw dataset. Other teams can query only the views dataset, which exposes pre-aggregated/anonymized data. • Declarative access control: Authorized views and dataset-level IAM are declarative and managed via IAM and BigQuery metadata, minimizing custom code. • Exfiltration protection: VPC Service Controls define a security perimeter around BigQuery and related services, reducing risk of data exfiltration. Organization policies can prevent adding external principals (e.g., personal accounts) to IAM policies. • Future datasets: The pattern (raw dataset + views dataset + authorized views + perimeter) is repeatable for new datasets. Why others are suboptimal: A: Two datasets and simple IAM separation is good, but it doesn’t enforce that the anonymized dataset only contains safe views; someone with Data Owner on the anonymized dataset could accidentally or maliciously create non-anonymized tables. It also doesn’t explicitly leverage authorized views, which are designed for this pattern. B: Column-level security helps, but the requirement is that only a small group can query raw trading data, while others should only see pre-aggregated/anonymized views. Column-level security alone doesn’t enforce aggregation/anonymization logic; it just hides columns. Users could still infer sensitive information from non-masked columns. D: Using a custom proxy to rewrite queries introduces significant operational complexity and custom code, contrary to the requirement to minimize custom access-control logic. It also creates a single point of failure and is harder to maintain and validate for regulatory audits compared to native BigQuery controls. Therefore, C provides the most secure, compliant, and maintainable design.

Sample Question 5 — Designing for security and compliance

A global e-commerce company is moving its payment processing microservices to Google Cloud. The services will run on GKE and integrate with a third-party payment gateway over the internet. Requirements: • PCI DSS compliance is mandatory. • Outbound traffic to the payment gateway must be tightly controlled and auditable. • No public IPs should be assigned to GKE nodes or Pods. • The architecture should minimize operational overhead for managing certificates and firewall rules. • The company wants to avoid vendor lock-in at the network layer as much as possible. You need to design the network egress architecture for the payment services. What should you do?

  1. A. Deploy the GKE cluster with private nodes and use Cloud NAT for all outbound traffic. Configure firewall rules to allow egress to the payment gateway’s IP ranges. Use Cloud Logging to capture VPC Flow Logs for auditing.
  2. B. Deploy the GKE cluster with private nodes and configure a regional external HTTP(S) Load Balancer as an egress proxy. Route all outbound traffic through the load balancer using a custom routing configuration. Manage TLS certificates on the load balancer and restrict firewall rules to the load balancer’s IP.
  3. C. Deploy the GKE cluster with private nodes and use Private Service Connect (PSC) to connect to the payment gateway, requiring the gateway to expose a PSC endpoint. Enforce egress via PSC and use VPC Service Controls to restrict data exfiltration.
  4. D. Deploy the GKE cluster with private nodes and configure a dedicated Cloud NAT with a small, fixed set of external IPs reserved for payment traffic. Use egress firewall rules and custom routes to ensure payment microservices use only those IPs. Enable VPC Flow Logs and Cloud Logging for auditing, and manage TLS end-to-end from Pods to the payment gateway. (Correct answer)

Correct answer: D

Explanation: Option D best balances PCI DSS requirements, security, and operational simplicity while avoiding unnecessary lock-in. • PCI DSS and outbound control: A dedicated Cloud NAT with a fixed set of external IPs used only for payment traffic allows the payment gateway to whitelist those IPs. Egress firewall rules and custom routes ensure only specific services use those IPs and only to the gateway’s ranges. • No public IPs on nodes/Pods: Private GKE nodes with Cloud NAT satisfy this requirement. • Auditing: VPC Flow Logs plus Cloud Logging provide detailed records of outbound connections for compliance audits. • TLS and certificate management: End-to-end TLS from Pods to the payment gateway keeps certificate management at the application layer, which is typical for payment integrations and avoids complex egress proxies. • Vendor lock-in: Using standard NAT and routing is relatively portable conceptually; you’re not forcing the third-party to adopt a cloud-specific integration like PSC. Why others are suboptimal: A: A shared Cloud NAT for all outbound traffic makes it harder to isolate and control payment traffic separately from other workloads. While it can be made compliant, it complicates least-privilege and clear segmentation for PCI scope. B: Using an external HTTP(S) Load Balancer as an egress proxy is not a standard pattern for generic outbound traffic and adds complexity. It centralizes TLS termination at the load balancer, which may conflict with PCI expectations for end-to-end encryption and increases operational overhead for certificate and routing management. C: Private Service Connect would be ideal for private connectivity to Google or partners that support PSC, but most third-party payment gateways on the public internet do not. Requiring the gateway to expose a PSC endpoint is often unrealistic and increases vendor lock-in at the network layer. Also, PSC is not necessary to meet the stated requirements. Therefore, D provides a secure, auditable, and maintainable egress design aligned with PCI DSS and the company’s constraints.

Sample Question 6 — Designing for security and compliance

A SaaS provider hosts a multi-tenant analytics platform on Google Cloud. Each customer (tenant) uploads sensitive business data that must be logically isolated from other tenants. The platform uses a shared GKE cluster and a shared BigQuery project. Requirements: • Strong logical isolation between tenants at the data layer. • Minimize the number of Google Cloud projects to reduce management overhead. • Support thousands of tenants with dynamic onboarding and offboarding. • Allow the operations team to run cross-tenant operational queries (e.g., usage metrics) without exposing tenant data to other customers. • Ensure that a misconfiguration for one tenant cannot accidentally expose another tenant’s data. You need to design the data isolation strategy in BigQuery. What should you do?

  1. A. Create a separate BigQuery dataset per tenant in a single project. Use dataset-level IAM to grant each tenant access only to their dataset. Store shared operational metadata in a separate dataset with restricted access. Use a service account for the application to mediate all queries on behalf of tenants. (Correct answer)
  2. B. Use a single BigQuery dataset with a tenant_id column on all tables. Implement row-level security (RLS) policies based on tenant_id and map each tenant to a distinct IAM group. Allow tenants to query directly using their own identities, and grant the operations team a bypass role that ignores RLS for cross-tenant queries.
  3. C. Use a single BigQuery dataset with a tenant_id column and implement row-level security (RLS) policies that restrict access per tenant group. The application uses a central service account with BigQuery job execution permissions and applies a tenant filter in all queries. The operations team uses authorized views that aggregate data across tenants without exposing raw rows.
  4. D. Create a separate BigQuery project per tenant with identical datasets and tables. Use organization policies and folders to manage projects at scale. For cross-tenant operational queries, export data from each project to Cloud Storage and load it into a central BigQuery project for analysis.

Correct answer: A

Explanation: Option A provides strong logical isolation with manageable overhead and clear blast-radius boundaries. • Strong logical isolation: A dataset per tenant ensures that IAM misconfiguration for one dataset does not directly expose another tenant’s data. Dataset-level IAM is simple and robust. • Minimize projects: All datasets reside in a single BigQuery project, satisfying the requirement to avoid project sprawl. • Scale to thousands of tenants: Datasets are lightweight; creating one per tenant is generally feasible at this scale. Onboarding/offboarding is a matter of creating/deleting datasets and updating IAM. • Cross-tenant operational queries: Shared operational metadata can be stored in a separate dataset. The application and operations team can use service accounts and authorized views to run cross-tenant analytics without exposing tenant data to other customers. • Misconfiguration containment: IAM is scoped per dataset; a mistake on one dataset does not automatically affect others, reducing the risk of cross-tenant exposure. Why others are suboptimal: B: A single dataset with RLS is powerful, but granting a bypass role that ignores RLS is risky; a misconfiguration or misuse of that role could expose all tenants’ data. Also, relying on direct tenant identities for BigQuery access increases complexity in identity management and onboarding. C: Central service account plus application-enforced tenant filters reintroduces the risk that a bug or misconfiguration in application logic could bypass tenant filters, exposing cross-tenant data. RLS is mentioned, but if the central service account has broad access, the isolation depends heavily on application correctness rather than IAM boundaries. D: A project per tenant gives strong isolation but directly contradicts the requirement to minimize the number of projects. It also adds significant operational overhead for managing thousands of projects and complicates cross-tenant analytics with export/load workflows. Therefore, A offers a balanced, secure, and maintainable multi-tenant data isolation strategy in BigQuery.

Sample Question 7 — Designing for security and compliance

A global financial services company is migrating a customer-facing web application to Google Cloud. The application processes personally identifiable information (PII) for EU and US customers and must comply with GDPR and regional data residency requirements. Requirements: - PII for EU customers must not leave the EU at rest. - PII for US customers must not leave the US at rest. - The application must provide a single global HTTPS endpoint with low latency for users worldwide. - Operations teams want centralized security controls and logging. - The company wants to minimize operational overhead and avoid managing encryption keys directly. You are designing the architecture. What should you do to best meet these requirements?

  1. A. Deploy two regional backends (one in an EU region and one in a US region) behind a global external HTTP(S) load balancer. Use Cloud Storage and Cloud SQL in each region with default Google-managed encryption keys. Use Cloud Armor for WAF and Cloud Logging for centralized logs. Route users to the nearest backend using the load balancer’s global routing. (Correct answer)
  2. B. Deploy two regional backends (one in an EU region and one in a US region) behind a global external HTTP(S) load balancer. Store EU and US PII in separate regional Cloud SQL instances with customer-managed encryption keys (CMEK) scoped to each region. Use Cloud Armor for WAF, Cloud Logging and Cloud Monitoring centrally, and implement application logic to ensure EU users are served only from the EU backend and US users only from the US backend.
  3. C. Deploy a single multi-region backend in a dual-region (e.g., europe-west1+europe-west4) to simplify operations. Store all PII in a multi-region Cloud Spanner instance with CMEK. Use a global external HTTP(S) load balancer and Cloud Armor. Rely on Cloud Spanner’s multi-region replication to serve both EU and US users with low latency.
  4. D. Deploy separate projects for EU and US workloads, each with its own regional backend and regional Cloud SQL instance using default encryption. Use Cloud VPN between projects for centralized logging aggregation. Use regional external HTTP(S) load balancers in each project and configure DNS-based geo-routing to direct users to the appropriate region.

Correct answer: A

Explanation: Option A perfectly aligns with all the stated requirements. 1) Data Residency: Using regional Cloud SQL and Cloud Storage instances in the EU and US ensures that PII remains in its respective region 'at rest'. 2) Global Endpoint/Latency: A Global External HTTP(S) Load Balancer provides a single Anycast IP (global endpoint) and routes traffic to the nearest backend to minimize latency. 3) Encryption: The requirement to 'avoid managing encryption keys directly' is met by using Google-managed encryption keys rather than Customer-Managed Encryption Keys (CMEK). 4) Centralized Controls: Cloud Armor and Cloud Logging provide centralized security and monitoring. Option B is incorrect because it uses CMEK (increasing overhead). Option C violates data residency for US customers. Option D uses regional load balancers and DNS-based routing, which increases operational overhead and does not provide a single global HTTPS endpoint as effectively as a global load balancer.

Sample Question 8 — Designing for security and compliance

A healthcare analytics company processes sensitive medical records for multiple hospital customers on Google Cloud. They must comply with HIPAA and each hospital’s Business Associate Agreement (BAA). The platform ingests data from each hospital, runs analytics jobs, and exposes dashboards. Requirements: - Strict isolation of each hospital’s data and processing environment. - Centralized security policy management and monitoring by a small security team. - Minimize risk of misconfiguration leading to cross-tenant data access. - Use managed services where possible to reduce operational burden. - Support future onboarding of dozens of additional hospitals. You are designing the multi-tenant architecture. What should you do?

  1. A. Create a single shared project for all hospitals. Use a single VPC and a single BigQuery dataset with row-level security policies per hospital. Use IAM conditions to restrict access to rows per hospital. Centralize logging and monitoring in the same project.
  2. B. Create one project per hospital under a single Google Cloud organization. Use a shared VPC host project for networking and service projects per hospital for workloads. Use folder-level organization to group hospital projects and apply organization policies, centralized logging exports, and security controls from the organization and folder levels. (Correct answer)
  3. C. Create one organization per hospital to achieve maximum isolation. Within each organization, create separate projects for ingestion, processing, and dashboards. Configure Cloud Interconnect between organizations for centralized security monitoring and logging.
  4. D. Create a single project per environment (dev, test, prod) shared by all hospitals. Use separate VPCs per environment and separate BigQuery datasets per hospital. Use VPC Service Controls around the project perimeter and IAM to restrict access to each dataset.

Correct answer: B

Explanation: Option B provides strong tenant isolation, centralized security governance, and scalability while using managed services and standard Google Cloud patterns. Analysis: - Isolation: One project per hospital clearly separates resources, IAM policies, and quotas. This reduces the blast radius of misconfigurations and simplifies reasoning about access boundaries. - Centralized control: A single organization with folders allows the security team to apply organization policies (e.g., restrict services, enforce CMEK, restrict external sharing) and consistent security baselines. Shared VPC allows central network control while keeping per-hospital workloads in separate service projects. - Compliance: HIPAA and BAAs often require clear tenant isolation and strong access controls. Project-level isolation is a recommended pattern for multi-tenant regulated workloads. - Operational simplicity: Centralized logging exports (e.g., from all projects to a security monitoring project) and consistent folder-level policies simplify operations while maintaining isolation. - Scalability: Adding a new hospital is as simple as creating a new project under the appropriate folder and attaching it to the shared VPC and logging/export policies. Why others are suboptimal: - A: A single project with row-level security and IAM conditions can technically isolate data, but it significantly increases the risk of misconfiguration leading to cross-tenant data access. In a highly regulated healthcare context, this logical-only isolation is often insufficient from a risk and compliance perspective. - C: One organization per hospital provides very strong isolation but is operationally heavy and contrary to recommended practices for a single enterprise. Managing multiple organizations, inter-org networking, and centralized security monitoring becomes complex and error-prone, especially as the number of hospitals grows. - D: A single project per environment with per-hospital datasets and VPC Service Controls improves security but still mixes all tenants in the same project. Misconfigurations in IAM or dataset permissions could lead to cross-tenant access. VPC Service Controls protect against data exfiltration but do not solve intra-project tenant isolation concerns as effectively as per-project isolation.

Sample Question 9 — Designing for security and compliance

A retail company is building a new payment processing microservices platform on Google Cloud. The platform will handle credit card data and must comply with PCI DSS. The architecture uses GKE for microservices, Cloud SQL for transactional data, and Pub/Sub for asynchronous events. Requirements: - Minimize the PCI DSS scope of the environment. - Prevent data exfiltration of cardholder data to the public internet or non-compliant services. - Support secure integration with a third-party fraud detection SaaS provider over HTTPS. - Maintain operational simplicity and avoid self-managing complex network appliances. You are designing the network and security architecture. What should you do?

  1. A. Place all GKE clusters, Cloud SQL instances, and Pub/Sub topics in a dedicated PCI project. Use private GKE clusters, private IP for Cloud SQL, and configure firewall rules to deny all egress except to the fraud detection provider’s IP range. Use Cloud NAT for outbound traffic and Cloud Armor for inbound protection.
  2. B. Use VPC Service Controls to create a service perimeter around the PCI-related projects and services (GKE, Cloud SQL, Pub/Sub). Configure private GKE clusters and private IP for Cloud SQL. Use a dedicated egress VPC with a proxy to the fraud detection provider and configure VPC Service Controls egress rules and access levels to allow only that destination. Export logs to a separate security project. (Correct answer)
  3. C. Deploy the PCI workloads in a separate VPC with no internet access. Use Cloud VPN to connect to the fraud detection provider’s network. Use private GKE clusters and private IP for Cloud SQL. Configure firewall rules to allow only VPN traffic and internal communication. Use Cloud Armor for additional protection.
  4. D. Use a single shared VPC for both PCI and non-PCI workloads. Segment PCI workloads into a dedicated subnet with strict firewall rules. Use private GKE clusters and private IP for Cloud SQL. Use Cloud NAT for outbound traffic and rely on IAM to prevent non-PCI services from accessing PCI data.

Correct answer: B

Explanation: Option B best aligns with PCI DSS requirements by minimizing scope, preventing data exfiltration, and using managed controls while maintaining operational simplicity. Analysis: - Minimizing PCI scope: Placing PCI workloads in dedicated projects and wrapping them in a VPC Service Controls perimeter limits which services and identities can access sensitive data, reducing the effective scope. - Data exfiltration protection: VPC Service Controls are designed to mitigate data exfiltration risks from Google-managed services (e.g., Cloud Storage, BigQuery, Pub/Sub, Cloud SQL via APIs). Egress rules and access levels can tightly control which destinations are allowed, including the specific fraud detection provider endpoint. - Secure third-party integration: A dedicated egress VPC with a controlled proxy path to the SaaS provider allows you to tightly manage outbound connections while still using HTTPS. This pattern is compatible with VPC Service Controls and avoids broad internet access. - Operational simplicity: Using managed services (VPC Service Controls, private GKE, private IP for Cloud SQL, centralized logging) avoids self-managing complex appliances and aligns with Google Cloud’s recommended patterns for regulated workloads. Why others are suboptimal: - A: Private GKE and Cloud SQL with strict firewall rules improve security, but firewall-based egress control alone is weaker than VPC Service Controls for preventing data exfiltration from managed services. It does not minimize PCI scope at the control-plane/API level and relies heavily on IP-based controls, which are harder to maintain and audit. - C: A separate VPC with no internet and Cloud VPN to the provider is secure but may not be feasible if the SaaS provider only exposes public internet endpoints and does not support VPN. It also adds operational complexity in managing VPNs and may not integrate as cleanly with managed services and VPC Service Controls. - D: A single shared VPC mixes PCI and non-PCI workloads, increasing the PCI scope and risk of lateral movement. While subnet segmentation and IAM help, this design complicates compliance audits and increases the blast radius of misconfigurations. It does not provide strong exfiltration protection for managed services like VPC Service Controls does.

Sample Question 10 — Designing for security and compliance

A global media company is migrating its content management system (CMS) and media asset storage to Google Cloud. The CMS is used by internal editors and external partners. The company must comply with strict internal security policies and regional regulations. Requirements: - All media assets must be encrypted with customer-managed keys. - Access to media assets must be tightly controlled by user identity and project. - External partners should only access specific assets via signed URLs, without gaining broader project access. - Security team needs centralized visibility into key usage and access logs. - Minimize custom code for access control and key management. You are designing the storage and access control architecture. What should you do?

  1. A. Store media assets in regional Cloud Storage buckets with default encryption. Use IAM to grant editors and partners access at the bucket level. Generate signed URLs for partners using a service account key stored in Secret Manager. Enable Cloud Audit Logs for access visibility.
  2. B. Store media assets in multi-region Cloud Storage buckets with CMEK managed in Cloud KMS. Use IAM on buckets and objects to grant editors access. For partners, use signed URLs generated by a dedicated service account that has objectViewer on specific buckets. Enable Cloud Audit Logs and Cloud KMS key usage logs in a centralized security project.
  3. C. Store media assets in regional Cloud Storage buckets with CMEK managed in Cloud KMS. Use per-object ACLs to control access for editors and partners. Generate signed URLs using HMAC keys associated with specific service accounts. Export Cloud Storage access logs to BigQuery for analysis.
  4. D. Store media assets in regional Cloud Storage buckets with CMEK managed in Cloud KMS. Use IAM Conditions on buckets and objects to restrict access based on user identity and project. For partners, generate V4 signed URLs using a dedicated service account with limited permissions. Centralize Cloud Audit Logs and Cloud KMS key usage logs in a separate security project. (Correct answer)

Correct answer: D

Explanation: Option D best meets the encryption, fine-grained access control, partner access, and centralized visibility requirements while minimizing custom code. Analysis: - CMEK: Regional Cloud Storage buckets with CMEK in Cloud KMS satisfy the requirement that all media assets are encrypted with customer-managed keys and allow the security team to control key rotation and revocation. - Fine-grained access: IAM Conditions allow attribute-based access control (e.g., based on user identity, project, or other context) without resorting to legacy ACLs. This provides tight control aligned with internal policies and is easier to manage at scale than per-object ACLs. - Partner access: V4 signed URLs generated by a dedicated, least-privilege service account allow partners to access only specific assets without granting them IAM roles on the project or bucket. This matches the requirement for limited, URL-based access. - Centralized visibility: Centralizing Cloud Audit Logs and Cloud KMS key usage logs in a security project gives the security team a single place to monitor access and key usage, supporting compliance and incident response. - Operational simplicity: Using managed IAM Conditions and KMS reduces the need for custom access control code and complex key management logic. Why others are suboptimal: - A: Uses default encryption instead of CMEK, which violates the explicit requirement for customer-managed keys. Bucket-level IAM for partners is too coarse and may grant broader access than intended. - B: Uses multi-region buckets, which may conflict with regional regulatory requirements if data residency is important. It also relies on bucket/object IAM without IAM Conditions, making fine-grained, context-aware access control harder. Still, it is closer but not as aligned as D with regional and conditional access needs. - C: Uses CMEK but relies on per-object ACLs, which are harder to manage at scale and are generally discouraged in favor of IAM. HMAC keys add additional key material to manage and rotate, increasing operational overhead and risk. While technically workable, it is more complex and less aligned with modern best practices than IAM Conditions and V4 signed URLs.

How to Study Google Cloud Architect Designing for security and compliance

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

About the Google Professional Cloud Architect Exam

Other Google Cloud Architect Domains

Start the free Google Cloud Architect Designing for security and compliance practice test now | 10-question quick start | All GCP PCA domains