The Google Cloud Terraform provider 8.0 has been released as GA, bringing a new default for Application Load Balancers, removing resources tied to retired services, and tightening schema validation. Engineers who codify infrastructure, especially those managing AI workloads, Kubernetes clusters, or security‑focused resources, need to understand how these adjustments affect plan diffs, state security, and migration effort.
Changed Defaults and Schema Behavior
The default load_balancing_scheme for google_compute_backend_service and google_compute_global_forwarding_rule now switches from EXTERNAL to EXTERNAL_MANAGED. Configurations that omit this attribute will automatically adopt the modern external Application Load Balancer model. Teams that rely on the classic scheme must explicitly set load_balancing_scheme = "EXTERNAL" to preserve existing behavior.
Several attributes that previously used ordered lists have been re‑typed as sets—examples include fields in Compute Service Attachments, GKE logging/monitoring blocks, and Cloud Security Compliance Framework definitions. This change eliminates perpetual diffs caused by API‑returned ordering variations. Validation rules are also stricter: source_contents is now mandatory for google_workflows_workflow, and claim_mapping must be provided when creating Workforce Identity Pool Provider SCIM tenants.
Retired Resources and Migration Path
Version 8.0 drops a set of resources and data sources linked to services that have been shut down or superseded. The affected items include:
google_iap_brandandgoogle_iap_client– IAP OAuth Admin APIs are no longer available.google_notebooks_environment,google_notebooks_instance,google_notebooks_runtime– Notebooks products reached end‑of‑life; migrate togoogle_workbench_instance.google_ml_engine_model– Machine‑learning workloads have moved to Vertex AI.google_beyondcorp_app_connection,google_beyondcorp_app_connector,google_beyondcorp_app_gateway– Replaced by Security Gateway resources.google_vertex_ai_schedule– Usegoogle_colab_scheduleinstead.
These removals are breaking changes; any configuration referencing them must be updated before upgrading. The provider’s upgrade guide details the migration steps for each resource.
Improved Discovery and Sensitive Data Handling
Since the 7.x series, the provider introduced read‑only list resources for a range of services (Compute Engine, IAM, BigQuery, Pub/Sub, Secret Manager, Migration Center, Network Services). Combined with the terraform query workflow, these allow teams to locate existing Google Cloud objects outside of state and generate import stubs automatically.
Write‑only attribute support has been expanded to cover additional secret fields such as certificate private keys, AlloyDB passwords, and IAP credentials. These values are sent to the API but never persisted in Terraform state, reducing the exposure of sensitive material.
Related CloudNinjas coverage: hands-on guides.
What This Means For Practitioners
Adopt the new EXTERNAL_MANAGED default only after confirming that your load‑balancer topology aligns with the managed behavior, or lock the classic scheme via explicit configuration. Audit your codebase for any of the retired resources and replace them with the recommended alternatives before planning an upgrade. Leverage the expanded list resources and write‑only attributes to bring legacy infrastructure under Terraform control while keeping secrets out of state. Finally, run a plan after the upgrade to catch any new validation errors early and adjust configurations accordingly.