StudyCerts
StudyCertsProfessional Cloud Data Engineer
professional-cloud-data-engineer
Advanced
Gauge your current knowledge
Advanced
Gauge your current knowledge
Regional considerations (data sovereignty) for data access and storage
...
professional-cloud-data-engineer
Gauge your current knowledge
Gauge your current knowledge
Data sovereignty means that data must follow the laws of the country or region where it is collected, stored, and processed. Google Cloud lets organizations enforce this through organization policies, which are rules that control how cloud resources can be set up across the entire environment. The main tool for data sovereignty is the resource location restriction constraint (called gcp.resourceLocations), which stops data storage and processing resources from being created outside approved geographic areas. This constraint helps organizations meet legal requirements by keeping data within specific borders.
The gcp.resourceLocations constraint works by creating an allowedValues list that specifies which Google Cloud regions, zones, or multi-regions can be used. When this policy is turned on, any attempt to create resources in unapproved locations gets blocked, while resources already created continue working normally. Organizations set these constraints using the Organization Policy Service together with Resource Manager, and they can apply them at the organization, folder, or project level. The constraint supports different location types including multi-regions (like us or eu), specific regions (like us-central1), and zones for the most precise control.
Google Cloud also offers Assured Workloads, a managed service that automatically sets up data boundaries for specific regulations. This includes the EU Data Boundary, US Data Boundary, Japan Data Boundary, and several others. Each boundary has predefined location values that restrict resource creation to specific regions. For example, the EU Data Boundary limits resources to European locations like europe-west1, while the US Data Boundary restricts to US regions like us-central1.
Organizations should know that some Google Cloud resources are global (like IAM policies or global load balancers) and cannot be restricted by this policy. Teams should also use additional constraints like gcp.restrictServiceUsage to control which services can be used within specific boundaries, and they should protect automated policy management to prevent changes that could break data residency rules.
Data residency means controlling the physical location of data to follow local laws about storage, encryption, and access. Data engineers design systems where sensitive information like personally identifiable information (PII) stays within geographic boundaries required by regulations such as GDPR. GCP provides tools that let teams choose exactly where data is stored and prevent it from being placed in unapproved locations.
When choosing storage options, teams must balance data residency rules against cost, availability, and disaster recovery needs. Regional storage keeps data in one geographic area (like us-central1) and works well for lower costs or applications needing low latency. Dual-regional and multi-regional configurations replicate data across two or more regions within a large area (like the US multi-region), giving higher availability and protection against regional outages. The decision depends on whether regulations allow data to leave a specific country or require it to stay within exact borders.
Teams configure storage locations when creating resources. For example, selecting a region when creating a BigQuery dataset or Cloud SQL instance sets where that data lives. For stronger control, organizations use the resource locations constraint to block creation of resources outside approved regions. Services like BigQuery also offer regional API endpoints (such as bigquery.us-central1.rep.googleapis.com) that keep all request traffic and data in transit within a specific region.
For disaster recovery while following residency rules, teams keep backups within allowed geographic zones. This includes using cross-region read replicas for Cloud SQL that can be promoted in a secondary approved region, exporting BigQuery data to Cloud Storage buckets in the same region or a compliant dual-region, and using native multi-region replication in services like Spanner or Firestore when the geographic scope satisfies sovereignty requirements.
Google Cloud keeps data resident by ensuring customer data stays within specified regional locations. Organizations use the resource locations constraint (constraints/gcp.resourceLocations) to limit where projects and services can be created, which prevents accidental cross-border data movement. This constraint requires all input and output data to stay in the same physical region as the processing workloads, such as Dataproc clusters or Dataflow pipelines.
To secure storage and processing, organizations deploy customer-managed encryption keys (CMEK) using Cloud Key Management Service (Cloud KMS). The CMEK must always stay in the exact same region as the resources it protects to maintain residency compliance. While Google manages the underlying data encryption keys (DEKs), users control the key encryption keys (KEKs) and assign access roles. Service accounts need the Cloud KMS CryptoKey Encrypter/Decrypter role, and service agents for Compute Engine, Cloud Storage, and Dataproc must also have proper permissions.
To prevent data from leaving the organization improperly, teams implement VPC Service Controls, which create security perimeters that block external requests and restrict data flow to trusted networks. A single unified perimeter is recommended over multiple smaller ones because it reduces management complexity and secures traffic between services. Administrators configure ingress and egress rules that allow secure data exchange only with explicitly trusted projects.
For safe API access, organizations configure DNS records to resolve through private API endpoints using the restricted Google APIs domain (restricted.googleapis.com). This domain blocks access to external services that do not support perimeter controls. When workloads must access storage outside their immediate perimeter, ingress and egress rules enable secure data transfer—for example, Dataflow pipeline workers need specific permissions to safely read and write data to resources in different perimeters.