HashiCorp has made version 8.0 of the Terraform provider for Google Cloud generally available. The release landed in the registry on 22 September and was covered by InfoQ this week. Major provider versions come around roughly once a year, and they are where breaking changes pile up.
Most of 8.0 is housekeeping. One change is not, because it can alter live traffic paths without anyone writing a new line of code.
The default that changed
For two common resources, the global forwarding rule and the backend service, the default load balancing scheme moves from EXTERNAL to EXTERNAL_MANAGED. In plain terms, any configuration that never set this value explicitly will now get Google's newer external Application Load Balancer instead of the classic one.
The newer load balancer is where Google is putting its effort, so this is the right long-term direction. But a switch between load balancer types is not a cosmetic change. Depending on the setup, Terraform may plan to replace resources rather than update them. On a public entry point, replace can mean a gap in service.
HashiCorp's advice is direct: if you still need classic behaviour, set the old value explicitly before you upgrade.
Resources that are gone
Version 8.0 also removes resources tied to Google services that have been shut down or replaced:
- IAP brand and client resources, after Google turned off the IAP OAuth admin APIs.
- The old Notebooks resources, replaced by Workbench instances.
- The ML Engine model resource, with workloads moving to Vertex AI.
- Three BeyondCorp app connection resources, replaced by Security Gateway resources.
- The Vertex AI schedule resource, replaced by a Colab schedule resource.
If any of these are in your code, the upgrade will stop until you deal with them. That is the good kind of breakage. It is loud and it happens before anything changes in the cloud.
Smaller changes worth knowing
Some fields where order never mattered are now treated as sets, which should cut down the annoying plans that show changes when nothing really changed. A few fields have stricter rules, for example workflows now require their source contents. And sensitive values such as certificate private keys and some database passwords can now be written without being stored in Terraform state, which is a real security gain.
Why leaders should care
Provider upgrades are often treated as routine dependency updates, merged by whoever is on rotation. That works for minor versions. Major versions deserve the same attention as a change to production networking, because that is sometimes what they are.
The deeper issue is defaults. Any setting your code leaves blank is a setting someone else controls. When a vendor changes it, your infrastructure changes with it.
What to do before upgrading
- Upgrade to the latest 7.x first and clear every deprecation warning. HashiCorp recommends this order.
- Search for load balancers that rely on the default. Set the scheme explicitly on every forwarding rule and backend service, whichever type you want.
- Remove or migrate the deleted resources using the version 8 upgrade guide.
- Run the plan in a non-production project and read it line by line. Any resource marked for replacement on a public entry point needs a named person to approve it.
- Pin the provider version in every root module so nobody picks up 8.0 by accident.
None of this is hard. It just needs someone to treat the upgrade as a change with risk, rather than a version bump.
