GCP PCA Drill: Organization Policy Enforcement - The Centralized Control vs. Network-Level Trade-off

While preparing for the GCP Professional Cloud Architect (PCA), many candidates get confused by Organization Policy vs. Network-Level Controls. In the real world, this is fundamentally a decision about Centralized Governance vs. Manual Network Configuration. Let’s drill into a simulated scenario.

The Scenario

#

TerraLogistics, a global supply chain management company, operates 47 regional distribution centers across 6 continents. Each distribution center runs real-time inventory tracking systems on Google Cloud, deployed across 12 different VPCs (organized by region and environment).

The CISO has mandated that external IP addresses must be restricted to only a handful of approved bastion hosts and CI/CD runners—all other Compute Engine instances must communicate through Cloud NAT or Internal IP addresses only. The security team needs this policy enforced organization-wide with minimal ongoing maintenance, as new VPCs are regularly created for expansion into new markets.

Key Requirements

#

Enforce a restriction on external IP address usage across all current and future VPCs, allowing only explicitly approved instances to have external IPs, without requiring manual network reconfiguration for each VPC.

The Options

#

• A) Remove the default route on all VPCs. Move all approved instances into a new subnet that has a default route to an internet gateway.
• B) Create a new VPC in custom mode. Create a new subnet for the approved instances, and set a default route to the internet gateway on this new subnet.
• C) Implement a Cloud NAT solution to remove the need for external IP addresses entirely.
• D) Set an Organization Policy with a constraint on constraints/compute.vmExternalIpAccess. List the approved instances in the allowedValues list.

Correct Answer

#

Option D.

The Architect’s Analysis

#

Correct Answer

#

Option D - Set an Organization Policy with constraints/compute.vmExternalIpAccess.

Step-by-Step Winning Logic

#

This solution embodies three critical SRE principles:

1. Policy as Code: Organization Policies are declarative, version-controlled constraints that automatically apply to all resources within the organization hierarchy (folders, projects, VPCs). This eliminates the operational toil of per-VPC manual configuration.

2. Cattle, Not Pets: Instead of treating each VPC as a unique snowflake requiring custom network topology changes, the policy treats all infrastructure uniformly. New VPCs inherit the restriction automatically.

3. Principle of Least Privilege at Scale: The allowedValues list explicitly names approved instances (by project/instance ID or labels), providing fine-grained control without overly permissive network-level workarounds.

How it works technically: When an Organization Policy constraint is set on compute.vmExternalIpAccess, the Compute Engine API rejects any request to assign an external IP to instances not in the allowlist. This happens at the control plane level before network configuration even matters.

The Traps (Distractor Analysis)

#

Why not Option A? Removing default routes from all VPCs is an infrastructure-as-hostage approach. You’re breaking internet connectivity for legitimate workloads (updates, package downloads, external API calls) and then selectively restoring it via subnets. This violates the SRE principle of “error budgets”—you’re spending availability on policy enforcement. Additionally, this requires redeploying instances into new subnets, causing downtime and migration complexity.

Why not Option B? Creating a single “approved VPC” is architecturally backwards. TerraLogistics has 12 VPCs for valid reasons (regional isolation, blast radius containment, environment separation). Consolidating approved instances into one VPC destroys these boundaries and creates a single point of failure. This also doesn’t scale—what happens when a new region requires approved instances?

Why not Option C? Cloud NAT is excellent for egress-only traffic (instances without external IPs accessing the internet), but it doesn’t enforce the policy requirement. The question states that some instances (bastions, CI/CD) should have external IPs. Option C removes all external IPs, which over-restricts and fails to meet the “approved instances” requirement. Cloud NAT is part of the solution architecture but not the enforcement mechanism.

The Architect Blueprint

#

Diagram Note: The Organization Policy constraint cascades down the resource hierarchy, automatically enforcing the external IP restriction across all VPCs while allowing explicitly approved instances to maintain external connectivity.

The Decision Matrix

#

FinOps Winner: Option D saves approximately $6,300 in year one and $4,600 annually compared to Option A, while providing superior security posture and SRE operational efficiency.

Real-World Practitioner Insight

#

Exam Rule

#

“For the GCP PCA exam, when you see ’enforce across all VPCs/projects’ + ‘approved instances’, always select Organization Policy constraints. Keywords: organization-wide, inherited, centralized control.”

Real World

#

In production environments at companies like TerraLogistics, we’d implement Option D (Organization Policy) as the enforcement layer, then complement it with Cloud NAT (Option C) for egress traffic from non-approved instances. The architecture becomes:

1. Organization Policy: Hard constraint preventing unauthorized external IP assignment
2. Cloud NAT: Enables internet egress for instances without external IPs (OS updates, API calls)
3. Cloud Armor + Identity-Aware Proxy: Additional layers for approved bastion/CI instances

The exam tests whether you understand Organization Policy is the enforcement mechanism, not the entire solution. In the real world, you’d combine multiple GCP services, but the policy is foundational.

Common Production Pattern:

# Terraform example
resource "google_organization_policy" "external_ip_policy" {
  org_id     = "123456789"
  constraint = "constraints/compute.vmExternalIpAccess"
  
  list_policy {
    allow {
      values = [
        "projects/prod-bastion/zones/us-central1-a/instances/bastion-01",
        "projects/prod-cicd/zones/us-central1-a/instances/jenkins-master"
      ]
    }
  }
}

This Infrastructure-as-Code approach ensures policy changes go through peer review, CI/CD pipelines, and audit trails—exactly what SRE teams need for compliance.