A Decade of GCP Sprawl, Part 2: The Golden Path

The Identity Chain That Governance Depends On

Governance starts with identity. Before any project factory, any org policy, any Terraform import workflow makes sense, the organization needs deterministic ownership, lifecycle, and access boundaries. The golden path is downstream of the identity chain. When a project is created, the factory needs to know who owns it, which group gets edit, and which group gets read. Those questions resolve to identity. When an employee leaves, the deprovisioning chain has to terminate cleanly across every credential they touched. That also resolves to identity. The most expensive governance failures in brownfield GCP are not policy violations - they are stale credentials that survive offboarding because the identity chain has a break in it.

In a GCP-native organization, the chain runs from the HR system through to IAM. When any link in the chain breaks, credentials outlive the employee.

The Provisioning and Deprovisioning Chain

The standard enterprise identity chain looks like this:

HRIS (HR source of truth)
    ↓ [employment status changes trigger automation]
IdP (identity lifecycle manager)
    ↓ [SCIM provisioning]
Google Workspace / Cloud Identity (Google's identity layer)
    ↓ [Google groups → IAM bindings]
GCP IAM (resource access control)

SCIM (System for Cross-domain Identity Management) handles automated user and group sync from the IdP to Cloud Identity. The conceptual flow is straightforward: the IdP becomes the source of truth for identity state, and SCIM propagates that state into the Google Workspace / Cloud Identity boundary, where Google Groups then become the principals for IAM bindings.

The IdP-side configuration requires four steps - create a SCIM tenant and token in Google Cloud, configure the IdP with the endpoint URL and bearer token, enable user creation, attribute updates, and deactivation, then map IdP attributes to Google attributes. The Google Cloud side is bootstrapped with gcloud iam workforce-pools providers scim-tenants create; the IdP side uses its own SCIM connector configuration.

Two limitations matter here. First, full SCIM-based automated provisioning in Google requires a Cloud Identity Premium or Google Workspace edition that includes the automated user lifecycle features - the Cloud Identity Free tier does not include automated SCIM provisioning [23]. Second, SCIM handles user and group sync only - IAM role assignments require separate management. The correct pattern is to manage IAM bindings through Terraform with Google Groups as the principal, where group membership flows through the IdP. That way IAM is declarative and audit-trailed in Terraform state, while the people inside each group are managed once at the HR system.

The deprovisioning chain terminates properly for human identities when SSO suspension revokes console access. The chain does not terminate properly for service account keys, long-lived tokens, or credentials embedded in applications outside the SSO perimeter. Those require a separate revocation workflow.

The Offboarding Gap: Service Account Keys

GCP service account keys have no default expiration - keys remain valid indefinitely unless an organization policy enforces a maximum lifetime. Keys can live in container images, config files, source code, and CI/CD environment variables - anywhere a developer needed a credential and chose the easy path. When an engineer leaves, their human identity is deprovisioned through the IdP. Their service account keys are not.

The audit command to find old keys is:

gcloud asset search-all-resources \
  --scope="organizations/123456789012" \
  --query="createTime < 2023-01-01" \
  --asset-types="iam.googleapis.com/ServiceAccountKey" \
  --order-by="createTime"

The rotation workflow from GCP documentation involves five steps: identify keys needing rotation, create replacement keys, update all consuming applications, disable the old keys while monitoring for breakage, then delete [2]. The "monitor for breakage" step is where the process typically stalls - identifying all the places a key is used requires the same inventory work described in Part 1.

Workload Identity Federation: Replacing Static Keys

Workload Identity Federation allows external workloads to authenticate to GCP using their native identity - GitHub Actions OIDC tokens, AWS instance credentials, Kubernetes ServiceAccount tokens - exchanging them for short-lived federated tokens through Google's Security Token Service [3]. The default service account token lifetime issued through federation is one hour; the minimum is 10 minutes and the maximum is 12 hours, with lifetimes greater than one hour requiring an organization policy exception via constraints/iam.allowServiceAccountCredentialLifetimeExtension [24].

Supported external identity sources include AWS, Azure, GitHub Actions (OIDC), GitLab, Kubernetes clusters, on-premises Active Directory, Okta (OIDC/SAML), and any OIDC or SAML 2.0 compliant IdP.

The direct IAM binding pattern (recommended over service account impersonation) grants GCP access directly to the federated identity:

# Grant GCP storage access directly to a GitHub Actions workflow
gcloud iam service-accounts add-iam-policy-binding \
  [email protected] \
  --role=roles/iam.workloadIdentityUser \
  --member="principal://iam.googleapis.com/projects/PROJECT_NUM/locations/global/workloadIdentityPools/POOL_ID/subject/repo:owner/repo:ref:refs/heads/main"

For GKE workloads, Workload Identity Federation for GKE automates pool and provider setup. Pods authenticate using their Kubernetes ServiceAccount token, mapped to a GCP IAM principal.

Domain-Wide Delegation: Isolation as the Control

DWD allows a GCP service account to impersonate any Google Workspace user in the organization. Some Workspace API integrations require it. The risk is that the delegation is attached to the service account's OAuth client ID, not to specific private keys. Restricting key creation does not restrict existing delegation.

The governance controls for DWD service accounts require four practices. First, isolate DWD-enabled service accounts in a dedicated project where only Super Admins have SA key creation permissions. Second, place that project high in the org hierarchy to prevent lower-level editors from accessing it. Third, minimize OAuth scopes - avoid admin.googleapis.com/auth/admin and similarly broad scopes. Fourth, audit regularly using Cloud Asset Inventory to find service accounts with oauth2ClientId fields, then cross-reference the Workspace Admin SDK.

Hunters' DeleFriend research identified DWD as a design-flaw-class risk, demonstrating that an attacker with permissions to create service account keys in a project containing a DWD-enabled service account can pivot to impersonate any Workspace user [4]. The Palo Alto Networks Unit 42 team documented the same attack surface independently, reaching the same conclusion: the risk is architectural, not a bug [5]. Isolation and access restriction are the only reliable mitigations.

The Project Factory: Consistent Provisioning at Scale

A project factory is a Terraform module that creates every new GCP project with the same baseline configuration. Instead of console-created projects that vary by who created them, the factory enforces billing attachment, folder placement, API enablement, VPC configuration, and IAM bindings consistently.

Google Cloud Foundation Toolkit

The Cloud Foundation Toolkit provides the reference implementation. The terraform-example-foundation repository stages the bootstrap in sequence:

1. 0-bootstrap: Create required permissions and set up Cloud Build for subsequent stages
2. 1-org: Top-level folders, monitoring projects, org-level logging, baseline security via org policy
3. 2-environments: Development, non-production, and production environments with shared VPCs
4. 3-networks: VPC topology per environment (dual shared VPC or hub-and-spoke)
5. 4-projects: Folder structure and application projects connected as Shared VPC service projects

GitHub: https://github.com/terraform-google-modules/terraform-example-foundation

The Project Factory Module

The official module is terraform-google-modules/terraform-google-project-factory/google, currently at v18.0.0 (January 2025) [1].

module "project-factory" {
  source  = "terraform-google-modules/project-factory/google"
  version = "~> 18.0"

  name                 = "my-app-prod"
  random_project_id    = true
  org_id               = "1234567890"
  billing_account      = "ABCDEF-ABCDEF-ABCDEF"
  svpc_host_project_id = "shared-vpc-host-project"
  folder_id            = google_folder.production.id

  shared_vpc_subnets = [
    "projects/base-project/regions/us-central1/subnetworks/default",
  ]

  activate_apis = [
    "container.googleapis.com",
    "cloudbuild.googleapis.com",
  ]
}

The module performs nine actions on every invocation: creates the project, attaches the shared VPC if specified, deletes the default compute service account, creates a replacement service account for the project, attaches billing, grants controlling group access, enables required APIs, deletes the default network, and enables GCE usage reporting to a central bucket [1]. The default network deletion matters: it prevents accidental exposure through the implicit firewall rules GCP creates with the default VPC.

Landing Zone Folder Hierarchy

The recommended folder hierarchy creates four top-level zones with different security postures.

Organization
├── Shared/        (logging, networking, security tooling)
├── Production/
│   ├── Team-A/
│   └── Team-B/
├── Non-Production/
│   ├── Staging/
│   └── Development/
└── Sandbox/       (loose controls, time-limited, no production data)

Keep folder nesting to three levels or fewer. Deeper hierarchies make policy inheritance difficult to reason about.

Tiered Governance by Folder

Org policies applied at the folder level cascade to all child projects, enabling different security postures per environment without per-project configuration. Table 2 defines the governance tier matrix.

Folder	External IPs	Data Residency	VPC Service Controls	Audit Logging
Production	Disabled	Enforced	Required	Full
Staging	Disabled	Enforced	Recommended	Full
Development	Allowed with approval	Recommended	Optional	Sampled
Sandbox	Allowed	None	None	Minimal

The Terraform to enforce these controls at the folder level:

# Disable external IPs in production
resource "google_org_policy_policy" "disable_external_ip_prod" {
  name   = "folders/${google_folder.production.folder_id}/policies/compute.vmExternalIpAccess"
  parent = "folders/${google_folder.production.folder_id}"
  spec {
    rules {
      enforce = "TRUE"
    }
  }
}

# Require uniform bucket-level access org-wide
resource "google_org_policy_policy" "uniform_bucket_access" {
  name   = "organizations/${var.org_id}/policies/storage.uniformBucketLevelAccess"
  parent = "organizations/${var.org_id}"
  spec {
    rules {
      enforce = "TRUE"
    }
  }
}

Organization Policies in Brownfield: Dry-Run Before Enforcement

Organization Policy Service provides centralized control over GCP resources through constraints - rules that restrict which configurations resources can have. The service supports three constraint types.

Predefined constraints are built-in rules: compute.vmExternalIpAccess, storage.uniformBucketLevelAccess, and hundreds of others. Custom constraints use Common Expression Language (CEL) against resource metadata; as of May 2025, custom constraints cover 62 services [7]. Managed constraints are security-focused, built on the custom organization policy platform, and testable with dry-run and Policy Simulator.

The custom constraint example below enforces GKE release channel selection:

name: organizations/ORG_ID/customConstraints/custom.gkeReleaseChannel
resourceTypes:
  - container.googleapis.com/Cluster
methodTypes:
  - CREATE
  - UPDATE
condition: "resource.releaseChannel.channel != 'UNSPECIFIED'"
actionType: ALLOW
displayName: "Require GKE release channel"
description: "GKE clusters must use a managed release channel"

The Dry-Run Workflow

Enforcing an org policy against brownfield resources without testing first will break things. The safe workflow has five steps:

1. Run Policy Simulator to model impact on existing resources before any changes
2. Create the policy in dry-run mode - violations are audit-logged but not blocked
3. Monitor Cloud Audit Logs for dry-run violations for two to four weeks
4. Work with affected teams to remediate before enforcement
5. Set the policy to enforce

The dry-run mode behavior is explicit in GCP documentation: an organization policy in dry-run mode does not block any operations when enforced - it logs what would have been blocked, so the audit logs become the test results [8]. The two-to-four-week window matters because monthly batch jobs and scheduled maintenance tasks will not appear in shorter test periods.

The Terraform dual-spec pattern enforces the current policy while testing a stricter version:

resource "google_org_policy_policy" "location_restriction" {
  name   = "organizations/${var.org_id}/policies/gcp.resourceLocations"
  parent = "organizations/${var.org_id}"

  # Currently enforced: US and EU regions
  spec {
    rules {
      values {
        allowed_values = ["in:us-locations", "in:eu-locations"]
      }
    }
  }

  # Testing stricter US-only for future enforcement
  dry_run_spec {
    rules {
      values {
        allowed_values = ["in:us-locations"]
      }
    }
  }
}

VPC Service Controls serve as the last-resort enforcement layer for highly sensitive projects in PCI or PHI scope. The same dry-run principle applies: simulate first, enforce later. The VPC-SC violation dashboard reached GA on July 31, 2025, providing an org-wide aggregated view of all access denials by service perimeters [9]. Before the dashboard, perimeter denial debugging required per-perimeter log queries - a significant friction point that pushed teams toward keeping VPC-SC perimeters in dry-run indefinitely.

Terraform in Brownfield: State, Drift, and Import at Scale

Bringing brownfield GCP resources under Terraform management requires three capabilities: stable remote state, drift detection to catch divergence, and import workflows to pull existing resources in.

GCS Backend Configuration

GCS is the natural Terraform state backend for GCP workloads. State locking works natively via a lock file in the bucket - no DynamoDB equivalent needed [16].

terraform {
  backend "gcs" {
    bucket  = "my-org-terraform-state"
    prefix  = "environments/prod/networking"
    # Optional: CMEK encryption for sensitive environments
    kms_encryption_key = "projects/my-gcp-project/locations/us-central1/keyRings/terraform-state/cryptoKeys/terraform-state-key"
  }
}

Use environment-specific prefixes, enable bucket versioning from day one, and keep separate state files per environment and per component. A monolithic state file for the entire organization creates blast radius and lock contention problems.

gs://org-terraform-state/
  bootstrap/terraform.tfstate
  org/terraform.tfstate
  environments/prod/networking/terraform.tfstate
  environments/prod/team-a/terraform.tfstate
  environments/staging/networking/terraform.tfstate

Drift Detection

Drift occurs when infrastructure diverges from the Terraform-declared configuration, typically through console changes (ClickOps), automated systems operating outside Terraform, or cloud provider updates.

The baseline drift check uses terraform plan exit codes:

# Exit codes: 0=no changes, 1=error, 2=changes detected (drift)
terraform plan -detailed-exitcode -no-color -out=driftcheck.tfplan
EXIT_CODE=$?
if [ $EXIT_CODE -eq 2 ]; then
  echo "DRIFT DETECTED"
fi

Table 3 compares drift detection tooling at the platform level.

Tool	Approach	Strength	Limitation
HCP Terraform	Daily health assessments	Native UI, drift dashboard	HCP Standard plan required; daily cycle only
Spacelift	Configurable periodic detection with auto-remediation	Flexible scheduling; Slack/webhook alerts	Commercial
env0	Instant detection with AI-powered drift analysis	Severity classification; cause identification	Commercial
Atlantis	PR-based plan/apply review	Open-source, GitOps-native	Prevents drift by review; does not detect it after the fact
driftctl	Dedicated drift coverage measurement	Multi-provider, IaC coverage metrics	Maintenance mode

A GitHub Actions workflow for scheduled drift detection:

name: Drift Detection
on:
  schedule:
    - cron: '0 6 * * *'  # Run daily at 6 AM
jobs:
  drift-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v2
      - name: Terraform Plan
        run: |
          terraform init
          terraform plan -detailed-exitcode -no-color 2>&1 | tee plan-output.txt
          echo "EXIT_CODE=$?" >> $GITHUB_ENV
      - name: Alert on Drift
        if: env.EXIT_CODE == '2'
        run: |
          echo "Drift detected in ${{ matrix.environment }}"

Import Workflows

Two import methods exist in current Terraform. The CLI import (terraform import) is imperative and available in all versions, but updates only the state file - it does not generate configuration code:

terraform import google_compute_instance.web my-project/us-central1-a/my-instance

Import blocks (Terraform 1.5+, 2023) are declarative and support automatic configuration generation with terraform plan -generate-config-out=generated.tf:

import {
  to = google_compute_instance.legacy_web_server
  id = "projects/my-project/zones/us-central1-a/instances/my-instance"
}

The safe import workflow backs up state before any operation:

#!/bin/bash
# 1. Back up current state
terraform state pull > state-backup-$(date +%Y%m%d%H%M%S).json

# 2. Import the resource
terraform import "$RESOURCE_ADDRESS" "$RESOURCE_ID"

# 3. Verify with a targeted plan
terraform plan -target="$RESOURCE_ADDRESS" 2>&1 | tee plan-output.txt

# 4. Confirm no unintended changes
if grep -q "No changes" plan-output.txt; then
  echo "SUCCESS: Import matches existing resource"
fi

Add lifecycle { ignore_changes = all } initially after import, then remove it incrementally as configuration is validated. Add lifecycle { prevent_destroy = true } for critical data resources.

For bulk import of many existing resources, Terraformer reverse-engineers GCP resources into Terraform configuration and state files. GCP support covers compute, IAM, GCS, GKE, and more:

terraformer import google \
  --resources=project,iam,gcs \
  --regions=us-central1 \
  --projects=my-existing-project

Phased Brownfield Approach

Importing an entire organization's existing infrastructure at once is not practical. A phased approach reduces risk by tackling lower-blast-radius resource types first. Table 4 defines the phase sequence.

Phase	Scope	Duration	Risk Level
1 - Foundation	VPCs, subnets, routes, NAT	2 weeks	Low (read-only initially)
2 - Security	IAM roles and policies, KMS keys	3 weeks	Medium (IAM changes need testing)
3 - Compute	Instances, GKE, Cloud Run	4 weeks	Medium (instance changes can cause downtime)
4 - Data	Cloud SQL, GCS, BigQuery	4 weeks	High (data resources are critical)

For resources too complex to import accurately, a pragmatic alternative is a frozen state entry: add lifecycle { prevent_destroy = true; ignore_changes = all } and govern the resource through Security Command Center findings until it can be properly migrated or decommissioned.

Measuring Governance by Adoption, Not Audit

The final shift in the governance model is how compliance is measured. Mandate compliance asks: what percentage of resources satisfy the policy? Golden path compliance asks: what percentage of new workloads flowed through the governed template?

The Golden Path vs. Gatekeeping Distinction

Gatekeeping and golden paths achieve different results with the same stated goal. Table 5 contrasts the two approaches.

Dimension	Gatekeeping	Golden Path
Provisioning model	Approval gates block deployment	Templates enable self-service
Policy violations	Trigger rejections	Prevented by template design
Platform team role	Bottleneck and reviewer	Guardrail provider
Developer response	Route around controls (shadow IT)	Adopt the path because it reduces friction
Compliance measurement	Audit percentage	Adoption percentage

The golden path concept originated at Spotify, where autonomous team culture led to what they internally called "rumour-driven development" - engineers could only learn how to do something by asking a colleague who had already done it [10]. Netflix calls its version the paved road. Jason Chan, former Netflix VP of Information Security, described the model as creating shared tooling for the most common challenges in building and deploying applications, ensuring that what gets deployed is secure and compliant by default [11].

The key characteristic separating a golden path from a golden cage is that the path is opinionated but not mandatory. Teams can deviate when they have a legitimate reason. Deviation should require explicit acknowledgment of the tradeoff, not a support ticket. A useful working definition: the golden path is what is opinionated-but-optional, the org policies enforced at the folder level are what is mandatory, and the exception register is how teams request deviations from either. Without that three-way distinction, "golden path" devolves into platform-team rhetoric that developers correctly ignore.

Adoption Metrics

The following metrics track golden path adoption rather than policy compliance:

• Percentage of new projects created via project factory template (vs. console/ClickOps)
• Percentage of services with a catalog entry (ownership coverage)
• Percentage of new service accounts using Workload Identity Federation (vs. key-based auth)
• Time-to-first-deploy for new teams using the golden path vs. without

Internal Developer Platforms

Golden paths are delivered through Internal Developer Platforms (IDPs). Gartner projects that 80% of large software engineering organizations will establish platform engineering teams as internal providers of reusable services, components, and tools by 2026, up from 45% in 2022 [12].

Table 6 compares three widely used IDP tools. Backstage is the incumbent by adoption; the other two are commercial alternatives.

Tool	Strength	Best For
Backstage	Extensibility, CNCF backing, plugin ecosystem	Organizations with engineering resources to customize [13]
Port	Blueprints, flexible self-service, action hub	Complex engineering topologies needing custom workflows
Cortex	Scorecards, initiatives, standards enforcement	Driving measurable organizational standards improvement

Backstage began as a software catalog at Spotify - a single inventory service that identified all services and their owners. The Spotify engineering team described the underlying problem directly: as the organization grew, infrastructure became more fragmented and engineers spent more time looking for the right information just to get started than building and testing code [10]. Backstage expanded from that catalog into a plugin ecosystem and golden path delivery mechanism, joined the CNCF Sandbox in September 2020, and was promoted to CNCF Incubating in March 2022 [13][14].

In GCP context, Backstage integrates with GCP APIs to surface project ownership, IAM posture, cost data, and golden path templates for resource provisioning.

Scorecards in Port and Cortex define compliance rules per resource type - "GCP project must have owner label," "Kubernetes deployment must have resource limits" - and measure each resource continuously without blocking deployment. This surfaces posture without creating the rejection loops that drive shadow IT.

Policy-as-Code tools like Open Policy Agent (OPA), integrated with Terraform via Rego policies, push compliance checks left into the terraform plan phase rather than waiting for cloud-side detection [15]. This is the operating-model complement to the golden path: the path makes the right thing easy, the PaC layer makes the wrong thing fail fast in CI rather than at runtime.

Recent GCP Governance Feature Changes (2025-2026)

Table 7 summarizes the GCP governance feature changes most relevant to the patterns in this article.

Date	Feature	Relevance
May 2025	Custom org policy constraints expanded to 62 services [7]	Broader enforcement coverage; fewer predefined constraint gaps
May 2025	Google Cloud Security Baseline GA [17]	Pre-configured org policy set automatically enabled for new orgs created in 2H 2025 onward
July 2025	VPC-SC violation dashboard GA [9]	Org-wide aggregated view of perimeter denials; enables enforcement progression
August 2025	SCC Compliance Manager (Preview) [18]	Unified compliance workflow with AI workload baselines; GA monitoring/auditing announced October 2025
October 2025	Cloud Armor Enterprise hierarchical policies GA [19]	Centralized control with policy inheritance; auto-protection for new projects
September 2025	New managed Compute Engine org constraints (Preview) [20]	Dry-run testable security constraints for VMs
2023-2025	SCC Premium PayGo pricing available at project and org level [21]	Lower barrier for SCC Premium adoption; per-service metered billing
December 2025	AI Protection GA in SCC Enterprise, Preview in Premium [22]	AI agent inventory; risk identification for AI workloads

---

References

[1] GitHub. "terraform-google-modules/terraform-google-project-factory." v18.0.0, January 2025. https://github.com/terraform-google-modules/terraform-google-project-factory

[2] Google Cloud. "Best practices for managing service account keys: Rotate service account keys." IAM Documentation. https://cloud.google.com/iam/docs/best-practices-for-managing-service-account-keys

[3] Google Cloud. "Workload Identity Federation." IAM Documentation. https://cloud.google.com/iam/docs/workload-identity-federation

[4] Hunters Security. "DeleFriend: Severe design flaw in Domain Wide Delegation could leave Google Workspace vulnerable for takeover." November 28, 2023. https://www.hunters.security/en/blog/delefriend-a-newly-discovered-design-flaw-in-domain-wide-delegation-could-leave-google-workspace-vulnerable-for-takeover

[5] Palo Alto Networks Unit 42. "Exploring a Critical Risk in Google Workspace's Domain-Wide Delegation Feature." November 30, 2023. https://unit42.paloaltonetworks.com/critical-risk-in-google-workspace-delegation-feature/

[6] GitHub. "terraform-google-modules/terraform-example-foundation." https://github.com/terraform-google-modules/terraform-example-foundation

[7] Google Cloud Blog. "What's new in IAM, Access Risk, and Cloud Governance." May 1, 2025. https://cloud.google.com/blog/products/identity-security/whats-new-in-iam-access-risk-and-cloud-governance/

[8] Google Cloud. "Test organization policies (dry-run mode)." Organization Policy Documentation. https://docs.cloud.google.com/organization-policy/test-policies

[9] Google Cloud. "VPC Service Controls release notes." July 31, 2025 entry. https://cloud.google.com/vpc-service-controls/docs/release-notes

[10] Spotify Engineering. "How We Use Golden Paths to Solve Fragmentation in Our Software Ecosystem." August 17, 2020. https://engineering.atspotify.com/2020/08/how-we-use-golden-paths-to-solve-fragmentation-in-our-software-ecosystem

[11] Chan, Jason. "Clint Collabs: Jason Chan on the Origins of the Paved Road." Interview, April 2024. https://www.youtube.com/watch?v=xijyr54FZn4

[12] Gartner. "What Is Platform Engineering?" Gartner research note, 2023. Cited in Puppet "State of Platform Engineering 2024" and Google Cloud platform engineering coverage. See also: https://www.gartner.com/en/articles/what-is-platform-engineering

[13] CNCF. "Backstage project joins the CNCF Incubator." March 15, 2022. https://www.cncf.io/blog/2022/03/15/backstage-project-joins-the-cncf-incubator/

[14] CNCF. "Backstage project page." https://www.cncf.io/projects/backstage/

[15] Firefly.ai. "Automate Terraform Security with OPA & Rego Policies." https://www.firefly.ai/academy/automating-terraform-security-checks-with-opa-and-rego-policies

[16] Google Cloud. "Store Terraform state in a Cloud Storage bucket." https://cloud.google.com/docs/terraform/resource-management/store-state

[17] Google Cloud. "Manage Google Cloud security baseline constraints." https://cloud.google.com/resource-manager/docs/manage-baseline-constraints

[18] Google Cloud Blog. "From silos to synergy: New Compliance Manager, now in preview." August 20, 2025. https://cloud.google.com/blog/products/identity-security/streamline-auditing-compliance-manager-is-now-in-preview

[19] Google Cloud. "Cloud Armor release notes." https://cloud.google.com/armor/docs/release-notes

[20] Google Cloud. "Organization Policy Service release notes." https://docs.cloud.google.com/organization-policy/release-notes

[21] Google Cloud. "Security Command Center pricing." https://cloud.google.com/security-command-center/pricing

[22] Google Cloud. "Security Command Center release notes." https://cloud.google.com/security-command-center/docs/release-notes

[23] Google Cloud. "Cloud Identity editions." https://cloud.google.com/identity/docs/editions

[24] Google AIP. "AIP-4117: External Account Credentials (Workload Identity Federation) - service account token lifetime." https://google.aip.dev/auth/4117