Cloud migration is not just a technical exercise—it is a compliance exercise. Every byte of data that moves from on-premises to Google Cloud must satisfy regulatory requirements for encryption, data residency, and access control. The PCNE exam tests your understanding of how Google Cloud’s networking features support these compliance mandates, and how you design migration strategies that maintain connectivity throughout the transition.
Encryption in Transit: The Three Layers
Layer 1: Google’s Default Encryption
All traffic between Google Cloud data centers is automatically encrypted. Google uses their proprietary ALTS (Application Layer Transport Security) protocol to encrypt traffic as it moves between machines within their infrastructure. You do not configure this—it happens by default.
Layer 2: IPsec (VPN)
Traffic over Cloud VPN is encrypted with IPsec. This satisfies most compliance requirements for in-transit encryption on hybrid connections. But IPsec operates at Layer 3 and adds overhead.
Layer 3: MACsec (Interconnect)
For Dedicated Interconnect, MACsec provides Layer 2 encryption directly on the physical link. It is line-rate encryption—zero latency overhead—but requires the Interconnect hardware to support it.
If the exam asks “How do you encrypt traffic on a Dedicated Interconnect?” the answer is MACsec, not VPN. VPN encrypts at Layer 3; MACsec encrypts at Layer 2 with no performance penalty.
Data Residency and Sovereignty
Some regulations require that data never leaves a specific geographic boundary. Google Cloud supports this through:
- Regional resource placement: Choose regions that comply with your data residency requirements (e.g.,
europe-west3for Germany). - Organization Policy constraints: Use
constraints/gcp.resourceLocationsto prevent resources from being created in non-compliant regions. - VPC-SC perimeters: Prevent data from being copied to projects or buckets in unauthorized regions.
Migration Strategies: The Network Perspective
Lift and Shift (Rehosting)
- Establish hybrid connectivity (Interconnect or VPN).
- Replicate data incrementally using Transfer Service or
gsutil rsync. - Migrate VMs using Migrate to Compute Engine.
- Network consideration: DNS cutover. When you switch prod traffic to GCP, update your DNS records from on-prem IPs to GCP IPs. Use low TTLs during the transition window.
Hybrid Coexistence (Long-Term)
Some workloads stay on-premises permanently. The network must support bidirectional traffic:
- On-prem applications calling GCP services (via Interconnect/VPN + Private Google Access).
- GCP applications calling on-prem services (via Forwarding Zones in Cloud DNS).
- Shared DNS: Use DNS Peering or Forwarding to ensure both environments can resolve each other’s hostnames.
Strangler Pattern (Gradual Migration)
- Put a Global HTTPS Load Balancer in front of both old and new systems.
- Use URL Maps to progressively route traffic paths from on-prem backends (Internet NEGs) to GCP backends.
- Each path is migrated independently.
/api/v1might stay on-prem while/api/v2moves to GKE.
Putting it Together: A Pro-Engineer View
Imagine you are migrating a healthcare system from an on-premises data center to Google Cloud. HIPAA requires encryption in transit. You deploy a Dedicated Interconnect with MACsec for Layer 2 encryption and HA VPN as a backup with IPsec encryption. You set Organization Policies to restrict all resources to us-central1 and us-east1 for data residency. You use the Strangler Pattern: your Global LB routes /patient-portal to the new GKE cluster while /legacy-records still goes to on-prem via an Internet NEG. DNS is managed centrally with Cloud DNS Forwarding Zones pointing to your on-prem Active Directory DNS. Each week, another path is migrated. No downtime. No compliance violations. No drama.
