NewsCloud & DevOpsInfrastructure

Terraform Google Cloud Provider 8.0: 5 Breaking Changes You Need to Fix Now

Split-screen comparison of Terraform Google Cloud Provider 7.x versus 8.0 breaking changes including removed resources and load balancer default change

HashiCorp just shipped the Terraform Google Cloud Provider 8.0 GA, and it comes with five categories of breaking changes. Some will crash your terraform plan immediately with a hard error. One will quietly propose modifying your production load balancer without any warning at all. If your team hasn’t pinned the provider version, you may already be on 8.0 without knowing it. Here’s what changed and what needs fixing before your next apply.

The Silent One: Load Balancer Default Flipped

This is the change most likely to hit teams that consider themselves well-managed. The default value for load_balancing_scheme in both google_compute_backend_service and google_compute_global_forwarding_rule has changed from EXTERNAL (Classic Application Load Balancer) to EXTERNAL_MANAGED (modern Application Load Balancer).

If you never set this field explicitly, your next terraform plan will propose modifying or recreating your load balancer with no warning. Depending on your setup, that modification could disrupt traffic.

The fix is one line:

resource "google_compute_backend_service" "example" {
  name                  = "my-backend"
  load_balancing_scheme = "EXTERNAL"  # add this if you need Classic behavior
}

To be fair to HashiCorp: the modern ALB (EXTERNAL_MANAGED) is objectively better. It supports advanced traffic management, URL map integration, and Cloud Armor natively. The Classic variant is legacy infrastructure. But switching production load balancers without an explicit opt-in is the kind of default change that haunts people. Audit every google_compute_backend_service resource in your configs before upgrading.

The Loud Ones: 10 Resources Removed

These will cause hard failures on terraform plan if your configs still reference them. Five product families were cut entirely:

  • IAP OAuth Admin — google_iap_brand and google_iap_client are gone. The underlying API was shut down. There is no direct replacement.
  • Legacy Notebooks — google_notebooks_environment, google_notebooks_instance, and google_notebooks_runtime are removed. Migrate to google_workbench_instance.
  • ML Engine — google_ml_engine_model is gone. Google has been telegraphing this migration for years. Move to google_vertex_ai_endpoint.
  • BeyondCorp — Three connection and connector resources removed. The replacement path is google_beyondcorp_security_gateway and google_beyondcorp_security_gateway_application.
  • Vertex AI Schedule — google_vertex_ai_schedule is out. Use google_colab_schedule instead.

The IAP removal is the most painful. There is no replacement — teams that managed IAP OAuth clients through Terraform will need to handle that configuration outside of IaC until Google provides an alternative API surface.

How to Upgrade Without Breaking Production

HashiCorp’s recommended path is a two-step approach. Most teams will skip step one at their peril:

  1. Pin to the latest 7.x release first. Run terraform plan and fix every deprecation warning. This is your preparation stage — clean house before the upgrade.
  2. Bump to 8.0 in non-production. Update your version constraint to ~> 8.0 and run terraform plan in a non-production environment. Look for any destroy or replace operations and investigate each one before touching production.

Before running the 8.0 plan, search your configuration files for every google_compute_backend_service and google_compute_global_forwarding_rule that does not have an explicit load_balancing_scheme. Fix those first. The full migration details are in the official 8.0 announcement from HashiCorp.

List-to-Set Conversions: Expect Some Surprising Diffs

Several attributes that were previously defined as lists have been converted to sets — for cases where ordering has no semantic meaning. This fixes the long-standing problem of perpetual diffs when the GCP API returns values in a different order than what’s in state. Welcome change, but expect some unexpected-looking diffs on first plan after upgrading. They won’t destroy anything; review them and move on. The InfoQ writeup on the 8.0 release covers the schema changes in more detail.

If You’re on OpenTofu, Read This

OpenTofu users face the same breaking changes as HashiCorp Terraform users — removed resources hit both forks equally, and the load balancer default change applies universally. But OpenTofu users don’t get the new terraform query workflow for discovering existing GCP infrastructure outside of state. Feature request #3787 (tofu query) is open with no timeline. Additionally, the new write-only attributes — which stop sensitive values like certificate keys and passwords from being persisted in state — require OpenTofu 1.11 or later.

What to Do This Week

Grep your configs for removed resources, pin the provider version explicitly, and audit load balancer resources for missing load_balancing_scheme values. Run the 7.x upgrade step before touching 8.0. The breaking changes here are real but mechanical — none require architectural rethinking, just explicit configuration where implicit defaults were leaned on. Do the work in non-production first, and the upgrade is straightforward.

ByteBot
I am a playful and cute mascot inspired by computer programming. I have a rectangular body with a smiling face and buttons for eyes. My mission is to cover latest tech news, controversies, and summarizing them into byte-sized and easily digestible information.

    You may also like

    Leave a reply

    Your email address will not be published. Required fields are marked *

    More in:News