professional-cloud-data-engineer
Data sovereignty requires that digital information adheres to the legal frameworks and privacy regulations of the geographic location where it is collected, stored, and processed. In Google Cloud, administrators enforce data sovereignty across resource hierarchies by applying the resource location restriction constraint (gcp.resourceLocations) within the Organization Policy Service. This constraint restricts the provisioning of data storage and compute resources to an approved list of regions, multi-regions, or zones. When applied at the organization, folder, or project level via Resource Manager, the policy blocks any attempt to create non-compliant resources while permitting existing resources to continue running.
Organizations can define allowed locations using granular individual zones, specific regions such as europe-west1, or multi-region identifiers like eu and us. To simplify administration across multiple compliant territories, administrators can also apply predefined location value groups, such as in:eu-locations or in:us-locations. Beyond custom policies, Assured Workloads automatically enforces pre-configured regional boundaries and resource constraints for specific compliance regimes, such as the EU Data Boundary, US Data Boundary, Japan Data Boundary, and Australia Data Boundary. These controls help satisfy standard security frameworks, including NIST-800-53 controls for access enforcement (AC-3), remote access (AC-17), and information sharing (AC-20).
Organizations must also account for the functional boundaries of resource location constraints. Global resources, such as Identity and Access Management (IAM) policies and global load balancers, operate outside regional boundaries and cannot be restricted by gcp.resourceLocations. To maintain strict sovereignty, security teams combine location constraints with the gcp.restrictServiceUsage constraint to block unauthorized cloud services within the environment.
Exam tip: The gcp.resourceLocations constraint only evaluates and blocks newly provisioned resources; it does not automatically move, alter, or delete existing resources that reside outside the newly defined boundary.
Data residency requires storing and managing data within designated physical borders to comply with legal mandates like the General Data Protection Regulation (GDPR). When designing storage architectures in Google Cloud using services like Cloud Storage, BigQuery, and Cloud Spanner, engineers select specific regional topologies that balance legal restrictions against availability, cost, and disaster recovery needs. Choosing a topology dictates the physical boundaries of data at rest, replication paths, and recovery capabilities.
Storage topologies vary by the geographic distribution of their underlying infrastructure:
| Topology | Geographic scope | Availability and redundancy | Primary use case |
|---|---|---|---|
| Regional | A single geographic region (e.g., us-central1) | Redundant across zones in one region; lowest storage cost | Strict in-country data residency requirements and low-latency local processing |
| Dual-regional | Two specific regions within a continent (e.g., europe-west1 and europe-west4) | Geo-redundant replication across two specific regions | High availability and disaster recovery with strict cross-country residency limits |
| Multi-regional | Multiple regions across a large geographic area (e.g., US or EU) | Highest availability and durability against regional outages | Large-scale global services where regulations allow data movement anywhere within the multi-region boundary |
To preserve data residency during disaster recovery operations, secondary backup targets must remain inside compliant jurisdictions. For instance, Cloud SQL cross-region read replicas must be deployed strictly to secondary regions that satisfy regulatory limits, and BigQuery datasets should export data exclusively to co-located or legally compliant Cloud Storage buckets. Additionally, BigQuery provides dedicated regional API endpoints, such as bigquery.us-central1.rep.googleapis.com, which direct all request metadata and in-transit data exclusively through servers in that specific region.
Exam tip: Regional API endpoints confine both request traffic and query execution strictly to the target region, preventing management traffic or query metadata from traversing global endpoints.
Regional data processing mandates that compute workloads, such as Dataproc clusters and Dataflow pipelines, operate in the exact same physical region where their input and output data resides. If a data pipeline reads from a regional Cloud Storage bucket in europe-west1, the Dataproc or Dataflow compute instances must execute within europe-west1 to prevent unauthorized cross-border network transfers. This geographical alignment ensures that intermediate shuffle data, temporary execution files, and analytical outputs never leave the defined sovereignty boundary.
Cryptographic security must also respect data sovereignty through localized customer-managed encryption keys (CMEK) managed by Cloud Key Management Service (Cloud KMS). While Google Cloud automatically manages low-level data encryption keys (DEKs), organizations maintain control over the key encryption keys (KEKs) by hosting the CMEK in the identical region as the storage or compute resource being encrypted. To enable automated encryption and decryption across processing workflows, the Cloud KMS CryptoKey Encrypter/Decrypter role must be granted to the following service agents:
To prevent data exfiltration across network boundaries, organizations deploy VPC Service Controls (VPC SC) to create secure service perimeters around cloud resources. VPC Service Controls restrict communication to authorized networks and prevent data from moving outside the perimeter without explicit ingress and egress policy rules. To ensure network traffic stays on private Google networks and avoids public exposure, internal Domain Name System (DNS) records route API requests to the restricted.googleapis.com domain, which restricts communication only to Google APIs supported by VPC Service Controls.
Exam tip: A Cloud KMS key used for Customer-Managed Encryption Keys (CMEK) must be provisioned in the exact same region as the resource it encrypts; cross-region key binding is not supported for regional resources.
StudyCerts
StudyCertsgcp.resourceLocations organization policy constraint restricts the geographic provisioning of new storage and compute resources without modifying pre-existing resources or global services like Identity and Access Management (IAM).restricted.googleapis.com virtual IP to prevent data exfiltration across jurisdictional boundaries.Prepare and test your skills
Prepare and test your skills
The resource location restriction constraint restricts the provisioning of data storage and compute resources to an approved list of regions, multi-regions, or zones. When enforced through the Organization Policy Service, the policy blocks attempts to create non-compliant new resources while permitting existing resources to continue running. It does not apply to global resources such as Identity and Access Management (IAM) policies or global load balancers.
Regional storage maintains data redundancy within a single geographic region for strict in-country residency at the lowest storage cost. Dual-regional storage provides geo-redundant replication across two specific regions within a continent for disaster recovery with strict cross-country residency limits. Multi-regional storage distributes data across multiple regions over a large geographic area to deliver the highest availability and durability against regional outages.
A customer-managed encryption key (CMEK) managed by Cloud Key Management Service (Cloud KMS) must be provisioned in the exact same region as the storage or compute resource it encrypts. Google Cloud does not support cross-region key binding for regional resources. To enable automated encryption and decryption, the Cloud KMS CryptoKey Encrypter/Decrypter role must be granted to the respective service agents, such as Compute Engine, Cloud Storage, or Dataproc.
Compute workloads like Dataproc clusters and Dataflow pipelines must execute in the exact physical region where their input and output data resides to prevent unauthorized cross-border network transfers. This geographical alignment ensures that intermediate shuffle data, temporary execution files, and analytical outputs remain strictly within the defined data sovereignty boundary.
A multinational enterprise is building a big data analytics pipeline on Google Cloud to process regulated healthcare data subject to strict data sovereignty laws in Germany. The compliance mandates require that all compute execution, key material, and at-rest storage remain strictly localized within the europe-west3 (Frankfurt) region, with controls in place to prevent data exfiltration.
You need to architect the Dataproc infrastructure, Customer-Managed Encryption Keys (CMEK), and perimeter security to enforce these data sovereignty requirements.
Which configuration should you deploy?