An enterprise is designing a data analytics architecture in Google Cloud that must comply with strict local data sovereignty and regulatory residency mandates. The compliance team has established the following requirements: All storage and data processing resources must be strictly confined to a single designated region (europe-west1) and prohibited from using multi-regions. Data at rest in services like BigQuery and Cloud Storage must enforce encryption using Customer-Managed Encryption Keys (CMEK). Key management governance must prevent resources from utilizing cryptographic keys originating from unauthorized projects. BigQuery datasets and their associated Cloud KMS key rings must be colocated in the exact same geographic region. Which set of configuration actions and organization policies should the data engineering team implement to meet these requirements?

Configure the `gcp.resourceLocations` organization policy constraint to allow only `europe-west1`. Apply the `gcp.restrictNonCmekServices` constraint for BigQuery and Cloud Storage, and use `gcp.restrictCmekCryptoKeyProjects` to restrict key provisioning to designated key projects. Create regional BigQuery datasets and Cloud KMS key rings explicitly in `europe-west1`.: What the solution is This architecture leverages Google Cloud organization policies alongside regionalized resource provisioning and Customer-Managed Encryption Keys (CMEK) in Cloud KMS to establish an end-to-end data residency and sovereignty boundary. How it meets all requirements Confining resources to a single region: Setting the gcp.resourceLocations organization policy constraint with allowedValues set strictly to europe-west1 prevents the creation of storage, compute, and analytics resources in any other location, including broader multi-regions (such as EU). Enforcing CMEK encryption: The gcp.restrictNonCmekServices organization policy constraint enforces that services such as bigquery.googleapis.com and storage.googleapis.com cannot write data using default Google-managed keys, requiring all new at-rest data to use CMEK. Governing key projects: The gcp.restrictCmekCryptoKeyProjects organization policy restricts which hierarchy nodes (specific projects or folders) are allowed to supply cryptographic keys, preventing unapproved projects from providing CMEK keys. Colocating BigQuery datasets and Cloud KMS key rings: Creating the BigQuery dataset and the Cloud KMS key ring explicitly in europe-west1 satisfies the cryptographic locality requirement, ensuring keys and encrypted data reside within the same regulatory boundary. Key advantages and capabilities Preventative enforcement: Organization policies act as guardrails across the resource hierarchy, blocking non-compliant API resource creation requests immediately. Cryptographic control: Using CMEK allows the enterprise to retain complete ownership over key lifecycles, rotation schedules, and revocation. Auditability and compliance: Centralizing keys in dedicated, approved projects streamlines compliance tracking and Cloud Audit Logs inspection. Deterministic data boundaries: Disallowing multi-region locations eliminates the risk of data being replicated across jurisdictions outside national compliance scopes. Why this is optimal Combining granular organization policies (gcp.resourceLocations, gcp.restrictNonCmekServices, and gcp.restrictCmekCryptoKeyProjects) with explicit regional provisioning provides deterministic technical enforcement of data sovereignty, preventing administrative errors or out-of-boundary data dispersion.

Pin GCP Data to europe-west1 with CMEK Guardrails

Enforcing Single-Region Residency with CMEK Controls

An enterprise is designing a data analytics architecture in Google Cloud that must comply with strict local data sovereignty and regulatory residency mandates. The compliance team has established the following requirements:

All storage and data processing resources must be strictly confined to a single designated region (europe-west1) and prohibited from using multi-regions.
Data at rest in services like BigQuery and Cloud Storage must enforce encryption using Customer-Managed Encryption Keys (CMEK).
Key management governance must prevent resources from utilizing cryptographic keys originating from unauthorized projects.
BigQuery datasets and their associated Cloud KMS key rings must be colocated in the exact same geographic region.

Which set of configuration actions and organization policies should the data engineering team implement to meet these requirements?

Create a BigQuery dataset in europe-west1 and encrypt it using a global Cloud KMS key ring. Apply the gcp.restrictCmekCryptoKeyProjects constraint, and use BigQuery column-level data policies to restrict data residency to local jurisdictions.

Configure the gcp.resourceLocations organization policy constraint to allow only europe-west1. Apply the gcp.restrictNonCmekServices constraint for BigQuery and Cloud Storage, and use gcp.restrictCmekCryptoKeyProjects to restrict key provisioning to designated key projects. Create regional BigQuery datasets and Cloud KMS key rings explicitly in europe-west1.

Apply the gcp.restrictNonCmekServices organization policy constraint. Create a regional BigQuery dataset in europe-west1, and set up Cloud Data Loss Prevention (Cloud DLP) inspection jobs to automatically migrate out-of-region datasets back to europe-west1.

Configure the gcp.resourceLocations organization policy constraint with eu-locations. Create a BigQuery dataset in the EU multi-region, and configure a Cloud KMS key ring located in europe-west1 using gcp.restrictServiceUsage to enforce CMEK.

Explanations

Create a BigQuery dataset in `europe-west1` and encrypt it using a global Cloud KMS key ring. Apply the `gcp.restrictCmekCryptoKeyProjects` constraint, and use BigQuery column-level data policies to restrict data residency to local jurisdictions.

What the option does

This approach configures a regional BigQuery dataset in europe-west1 but associates it with a global Cloud KMS key ring, while attempting to enforce regional data boundaries using BigQuery column-level data policies.

Why it doesn't meet the requirement

Invalid KMS key location: Cloud KMS keys used for regional resources must be created in the matching region (europe-west1). Global key rings cannot be used for regional CMEK bindings in BigQuery or Cloud Storage, and global keys undermine data residency controls by replicating key material across global infrastructure.
Misunderstands column data policies: Column-level data policies and masking are designed for data obfuscation and role-based access control; they have no ability to restrict underlying storage residency or prevent cross-region resource creation.
Fails resource-level residency enforcement: Omits the gcp.resourceLocations organization policy constraint, allowing unauthorized users to create resources in unapproved geographic regions.
Fails CMEK mandate enforcement: Omits gcp.restrictNonCmekServices, meaning users could still create unencrypted resources or use Google default encryption.

Key characteristics and limitations

Global KMS keys distribute cryptographic operations across all Google Cloud data center locations globally.
Column data policies govern column masking algorithms (e.g., hash, nullify), not geographic placement.

This answer would be correct if

The organization only required masking sensitive columns for specific IAM roles in existing regional datasets and did not require strict regional cryptographic boundaries or organization-wide location constraints.

View source documentation

Configure the `gcp.resourceLocations` organization policy constraint to allow only `europe-west1`. Apply the `gcp.restrictNonCmekServices` constraint for BigQuery and Cloud Storage, and use `gcp.restrictCmekCryptoKeyProjects` to restrict key provisioning to designated key projects. Create regional BigQuery datasets and Cloud KMS key rings explicitly in `europe-west1`.

What the solution is

This architecture leverages Google Cloud organization policies alongside regionalized resource provisioning and Customer-Managed Encryption Keys (CMEK) in Cloud KMS to establish an end-to-end data residency and sovereignty boundary.

How it meets all requirements

Confining resources to a single region: Setting the gcp.resourceLocations organization policy constraint with allowedValues set strictly to europe-west1 prevents the creation of storage, compute, and analytics resources in any other location, including broader multi-regions (such as EU).
Enforcing CMEK encryption: The gcp.restrictNonCmekServices organization policy constraint enforces that services such as bigquery.googleapis.com and storage.googleapis.com cannot write data using default Google-managed keys, requiring all new at-rest data to use CMEK.
Governing key projects: The gcp.restrictCmekCryptoKeyProjects organization policy restricts which hierarchy nodes (specific projects or folders) are allowed to supply cryptographic keys, preventing unapproved projects from providing CMEK keys.
Colocating BigQuery datasets and Cloud KMS key rings: Creating the BigQuery dataset and the Cloud KMS key ring explicitly in europe-west1 satisfies the cryptographic locality requirement, ensuring keys and encrypted data reside within the same regulatory boundary.

Key advantages and capabilities

Preventative enforcement: Organization policies act as guardrails across the resource hierarchy, blocking non-compliant API resource creation requests immediately.
Cryptographic control: Using CMEK allows the enterprise to retain complete ownership over key lifecycles, rotation schedules, and revocation.
Auditability and compliance: Centralizing keys in dedicated, approved projects streamlines compliance tracking and Cloud Audit Logs inspection.
Deterministic data boundaries: Disallowing multi-region locations eliminates the risk of data being replicated across jurisdictions outside national compliance scopes.

Why this is optimal

Combining granular organization policies (gcp.resourceLocations, gcp.restrictNonCmekServices, and gcp.restrictCmekCryptoKeyProjects) with explicit regional provisioning provides deterministic technical enforcement of data sovereignty, preventing administrative errors or out-of-boundary data dispersion.

View source documentation

Apply the `gcp.restrictNonCmekServices` organization policy constraint. Create a regional BigQuery dataset in `europe-west1`, and set up Cloud Data Loss Prevention (Cloud DLP) inspection jobs to automatically migrate out-of-region datasets back to `europe-west1`.

What the option does

This configuration applies CMEK enforcement via gcp.restrictNonCmekServices and creates a dataset in europe-west1, but relies on Cloud DLP inspection to detect and remediate out-of-region data assets instead of using preventative organization policies.

Why it doesn't meet the requirement

Lacks preventative location controls: Without configuring the gcp.resourceLocations constraint, developers can provision compute and storage in unauthorized regions across the globe.
Misapplies Cloud DLP: Cloud DLP (Sensitive Data Protection) is an inspection and de-identification service for detecting sensitive data (such as PII); it cannot automatically move or relocate BigQuery datasets across regions.
Omission of key project controls: Does not implement gcp.restrictCmekCryptoKeyProjects, allowing unauthorized or untrusted projects to supply KMS keys.
Reactive vs. preventative compliance: Relying on post-creation scanning fails strict sovereignty mandates where data must never reside outside the target boundary even transiently.

Key characteristics and limitations

Cloud DLP scans payloads and tables for sensitive infoTypes (e.g., credit card numbers, national IDs), not geographic resource compliance.
BigQuery dataset locations are immutable once created and cannot be automatically 'moved' dynamically by DLP jobs.

This answer would be correct if

The goal was to discover and de-identify sensitive PII within an existing europe-west1 dataset while requiring CMEK across selected Google Cloud services.

View source documentation

Configure the `gcp.resourceLocations` organization policy constraint with `eu-locations`. Create a BigQuery dataset in the `EU` multi-region, and configure a Cloud KMS key ring located in `europe-west1` using `gcp.restrictServiceUsage` to enforce CMEK.

What the option does

This configuration sets the resource location boundary to include all European Union locations (eu-locations), creates multi-region BigQuery datasets, and pairs them with a single-region Cloud KMS key in europe-west1 while attempting to enforce CMEK via gcp.restrictServiceUsage.

Why it doesn't meet the requirement

Fails single-region residency: Setting gcp.resourceLocations to eu-locations and creating a BigQuery dataset in the EU multi-region distributes data across multiple European data centers, directly violating the mandate to restrict all data and compute strictly to europe-west1.
Violates CMEK locality rules: A BigQuery dataset created in a multi-region (EU) cannot be encrypted using a single-region (europe-west1) KMS key ring; the key ring location must match the dataset geographic scope.
Incorrect organization policy: The gcp.restrictServiceUsage policy restricts which API services can be accessed at runtime, but does not enforce mandatory CMEK on storage services.
Lacks key origin restrictions: It fails to restrict which projects can supply KMS keys, omitting gcp.restrictCmekCryptoKeyProjects.

Key characteristics and limitations

eu-locations permits resource deployment across all EU member states rather than pinning data to a sovereign jurisdiction.
gcp.restrictServiceUsage is an API allowlist/denylist mechanism, not a CMEK enforcement constraint.

This answer would be correct if

The enterprise required high availability across the entire European Union multi-region without single-country sovereignty restrictions and only wanted to allow specific Google Cloud APIs via service usage restrictions.

View source documentation

Last updated August 27, 2026Validated August 27, 2026

Enforcing Single-Region Residency with CMEK Controls

All storage and data processing resources must be strictly confined to a single designated region (europe-west1) and prohibited from using multi-regions.
Data at rest in services like BigQuery and Cloud Storage must enforce encryption using Customer-Managed Encryption Keys (CMEK).
Key management governance must prevent resources from utilizing cryptographic keys originating from unauthorized projects.
BigQuery datasets and their associated Cloud KMS key rings must be colocated in the exact same geographic region.

Which set of configuration actions and organization policies should the data engineering team implement to meet these requirements?

Explanations

Create a BigQuery dataset in `europe-west1` and encrypt it using a global Cloud KMS key ring. Apply the `gcp.restrictCmekCryptoKeyProjects` constraint, and use BigQuery column-level data policies to restrict data residency to local jurisdictions.

What the option does

Why it doesn't meet the requirement

Invalid KMS key location: Cloud KMS keys used for regional resources must be created in the matching region (europe-west1). Global key rings cannot be used for regional CMEK bindings in BigQuery or Cloud Storage, and global keys undermine data residency controls by replicating key material across global infrastructure.
Misunderstands column data policies: Column-level data policies and masking are designed for data obfuscation and role-based access control; they have no ability to restrict underlying storage residency or prevent cross-region resource creation.
Fails resource-level residency enforcement: Omits the gcp.resourceLocations organization policy constraint, allowing unauthorized users to create resources in unapproved geographic regions.
Fails CMEK mandate enforcement: Omits gcp.restrictNonCmekServices, meaning users could still create unencrypted resources or use Google default encryption.

Key characteristics and limitations

Global KMS keys distribute cryptographic operations across all Google Cloud data center locations globally.
Column data policies govern column masking algorithms (e.g., hash, nullify), not geographic placement.

This answer would be correct if

View source documentation

Configure the `gcp.resourceLocations` organization policy constraint to allow only `europe-west1`. Apply the `gcp.restrictNonCmekServices` constraint for BigQuery and Cloud Storage, and use `gcp.restrictCmekCryptoKeyProjects` to restrict key provisioning to designated key projects. Create regional BigQuery datasets and Cloud KMS key rings explicitly in `europe-west1`.

What the solution is

How it meets all requirements

Confining resources to a single region: Setting the gcp.resourceLocations organization policy constraint with allowedValues set strictly to europe-west1 prevents the creation of storage, compute, and analytics resources in any other location, including broader multi-regions (such as EU).
Enforcing CMEK encryption: The gcp.restrictNonCmekServices organization policy constraint enforces that services such as bigquery.googleapis.com and storage.googleapis.com cannot write data using default Google-managed keys, requiring all new at-rest data to use CMEK.
Governing key projects: The gcp.restrictCmekCryptoKeyProjects organization policy restricts which hierarchy nodes (specific projects or folders) are allowed to supply cryptographic keys, preventing unapproved projects from providing CMEK keys.
Colocating BigQuery datasets and Cloud KMS key rings: Creating the BigQuery dataset and the Cloud KMS key ring explicitly in europe-west1 satisfies the cryptographic locality requirement, ensuring keys and encrypted data reside within the same regulatory boundary.

Key advantages and capabilities

Preventative enforcement: Organization policies act as guardrails across the resource hierarchy, blocking non-compliant API resource creation requests immediately.
Cryptographic control: Using CMEK allows the enterprise to retain complete ownership over key lifecycles, rotation schedules, and revocation.
Auditability and compliance: Centralizing keys in dedicated, approved projects streamlines compliance tracking and Cloud Audit Logs inspection.
Deterministic data boundaries: Disallowing multi-region locations eliminates the risk of data being replicated across jurisdictions outside national compliance scopes.

Why this is optimal

View source documentation

Apply the `gcp.restrictNonCmekServices` organization policy constraint. Create a regional BigQuery dataset in `europe-west1`, and set up Cloud Data Loss Prevention (Cloud DLP) inspection jobs to automatically migrate out-of-region datasets back to `europe-west1`.

What the option does

Why it doesn't meet the requirement

Lacks preventative location controls: Without configuring the gcp.resourceLocations constraint, developers can provision compute and storage in unauthorized regions across the globe.
Misapplies Cloud DLP: Cloud DLP (Sensitive Data Protection) is an inspection and de-identification service for detecting sensitive data (such as PII); it cannot automatically move or relocate BigQuery datasets across regions.
Omission of key project controls: Does not implement gcp.restrictCmekCryptoKeyProjects, allowing unauthorized or untrusted projects to supply KMS keys.
Reactive vs. preventative compliance: Relying on post-creation scanning fails strict sovereignty mandates where data must never reside outside the target boundary even transiently.

Key characteristics and limitations

Cloud DLP scans payloads and tables for sensitive infoTypes (e.g., credit card numbers, national IDs), not geographic resource compliance.
BigQuery dataset locations are immutable once created and cannot be automatically 'moved' dynamically by DLP jobs.

This answer would be correct if

The goal was to discover and de-identify sensitive PII within an existing europe-west1 dataset while requiring CMEK across selected Google Cloud services.

View source documentation

Configure the `gcp.resourceLocations` organization policy constraint with `eu-locations`. Create a BigQuery dataset in the `EU` multi-region, and configure a Cloud KMS key ring located in `europe-west1` using `gcp.restrictServiceUsage` to enforce CMEK.

What the option does

Why it doesn't meet the requirement

Fails single-region residency: Setting gcp.resourceLocations to eu-locations and creating a BigQuery dataset in the EU multi-region distributes data across multiple European data centers, directly violating the mandate to restrict all data and compute strictly to europe-west1.
Violates CMEK locality rules: A BigQuery dataset created in a multi-region (EU) cannot be encrypted using a single-region (europe-west1) KMS key ring; the key ring location must match the dataset geographic scope.
Incorrect organization policy: The gcp.restrictServiceUsage policy restricts which API services can be accessed at runtime, but does not enforce mandatory CMEK on storage services.
Lacks key origin restrictions: It fails to restrict which projects can supply KMS keys, omitting gcp.restrictCmekCryptoKeyProjects.

Key characteristics and limitations

eu-locations permits resource deployment across all EU member states rather than pinning data to a sovereign jurisdiction.
gcp.restrictServiceUsage is an API allowlist/denylist mechanism, not a CMEK enforcement constraint.

This answer would be correct if

View source documentation

Last updated August 27, 2026Validated August 27, 2026

Enforcing Single-Region Residency with CMEK Controls

Explanations

Create a BigQuery dataset in europe-west1 and encrypt it using a global Cloud KMS key ring. Apply the gcp.restrictCmekCryptoKeyProjects constraint, and use BigQuery column-level data policies to restrict data residency to local jurisdictions.

What the option does

Why it doesn't meet the requirement

Key characteristics and limitations

This answer would be correct if

What the solution is

How it meets all requirements

Key advantages and capabilities

Why this is optimal

Apply the gcp.restrictNonCmekServices organization policy constraint. Create a regional BigQuery dataset in europe-west1, and set up Cloud Data Loss Prevention (Cloud DLP) inspection jobs to automatically migrate out-of-region datasets back to europe-west1.

What the option does

Why it doesn't meet the requirement

Key characteristics and limitations

This answer would be correct if

Configure the gcp.resourceLocations organization policy constraint with eu-locations. Create a BigQuery dataset in the EU multi-region, and configure a Cloud KMS key ring located in europe-west1 using gcp.restrictServiceUsage to enforce CMEK.

What the option does

Why it doesn't meet the requirement

Key characteristics and limitations

This answer would be correct if

Try 10 interactive questions like this one, free

Related questions

BigQuery Omni BigLake External Tables

Apache Beam Runner Portability

Service Account Impersonation

BigQuery Baseline and Autoscaling Slots

Data Catalog Policy Tags

Declarative Infrastructure as Code

Enforcing Single-Region Residency with CMEK Controls

Explanations

Create a BigQuery dataset in europe-west1 and encrypt it using a global Cloud KMS key ring. Apply the gcp.restrictCmekCryptoKeyProjects constraint, and use BigQuery column-level data policies to restrict data residency to local jurisdictions.

What the option does

Why it doesn't meet the requirement

Key characteristics and limitations

This answer would be correct if

What the solution is

How it meets all requirements

Key advantages and capabilities

Why this is optimal

Apply the gcp.restrictNonCmekServices organization policy constraint. Create a regional BigQuery dataset in europe-west1, and set up Cloud Data Loss Prevention (Cloud DLP) inspection jobs to automatically migrate out-of-region datasets back to europe-west1.

What the option does

Why it doesn't meet the requirement

Key characteristics and limitations

This answer would be correct if

Configure the gcp.resourceLocations organization policy constraint with eu-locations. Create a BigQuery dataset in the EU multi-region, and configure a Cloud KMS key ring located in europe-west1 using gcp.restrictServiceUsage to enforce CMEK.

What the option does

Why it doesn't meet the requirement

Key characteristics and limitations

This answer would be correct if

Try 10 interactive questions like this one, free

Related questions

BigQuery Omni BigLake External Tables

Apache Beam Runner Portability

Service Account Impersonation

BigQuery Baseline and Autoscaling Slots

Data Catalog Policy Tags

Declarative Infrastructure as Code

Create a BigQuery dataset in `europe-west1` and encrypt it using a global Cloud KMS key ring. Apply the `gcp.restrictCmekCryptoKeyProjects` constraint, and use BigQuery column-level data policies to restrict data residency to local jurisdictions.

Apply the `gcp.restrictNonCmekServices` organization policy constraint. Create a regional BigQuery dataset in `europe-west1`, and set up Cloud Data Loss Prevention (Cloud DLP) inspection jobs to automatically migrate out-of-region datasets back to `europe-west1`.

Configure the `gcp.resourceLocations` organization policy constraint with `eu-locations`. Create a BigQuery dataset in the `EU` multi-region, and configure a Cloud KMS key ring located in `europe-west1` using `gcp.restrictServiceUsage` to enforce CMEK.

Create a BigQuery dataset in `europe-west1` and encrypt it using a global Cloud KMS key ring. Apply the `gcp.restrictCmekCryptoKeyProjects` constraint, and use BigQuery column-level data policies to restrict data residency to local jurisdictions.

Apply the `gcp.restrictNonCmekServices` organization policy constraint. Create a regional BigQuery dataset in `europe-west1`, and set up Cloud Data Loss Prevention (Cloud DLP) inspection jobs to automatically migrate out-of-region datasets back to `europe-west1`.

Configure the `gcp.resourceLocations` organization policy constraint with `eu-locations`. Create a BigQuery dataset in the `EU` multi-region, and configure a Cloud KMS key ring located in `europe-west1` using `gcp.restrictServiceUsage` to enforce CMEK.