Impact Assessment
Severity: Moderate
This release spans 15 changes across the Terraform Google Provider (v7.20.0 → v7.21.0), introducing 3 new resources, 2 new data sources, and several field additions — with two behavior fixes that directly affect production drift and large-scale storage operations.
---
Editor's Note: We see this release as a meaningful expansion cycle rather than routine maintenance — three new resources and two new data sources in a single minor bump reflects Google Cloud's accelerating surface area in networking, security, and VMware Engine. The google_cloudfunctions2_function DirectVPC change is the one to watch closely: if your team manually configured DirectVPC on the underlying Cloud Run service outside of Terraform, expect a plan diff on your next run. We'd recommend running terraform plan in a non-production workspace before promoting this provider version.
---
Detailed Breakdown
New Data Source: `google_vmwareengine_announcements`
A new data source allows Terraform configurations to read VMware Engine announcements programmatically. Previously, teams had no native way to surface these announcements within IaC pipelines.
Why it matters: Automation workflows that gate deployments on maintenance windows or platform notices can now incorporate announcement data directly without out-of-band scripting.
Migration steps:
1. No migration required — this is additive. Reference the new data source in configurations where VMware Engine announcement awareness is needed.
---
New Data Source: `google_vmwareengine_upgrades`
Complements google_vmwareengine_announcements by exposing upgrade metadata for VMware Engine environments as a readable data source.
Why it matters: Teams managing VMware Engine upgrade schedules can now query upgrade state within Terraform plans, enabling conditional logic tied to upgrade windows.
Migration steps:
1. No migration required. Incorporate into existing VMware Engine configurations as needed.
---
New Resource: `google_compute_region_backend_bucket`
Adds regional backend bucket support as a first-class Terraform resource, distinct from the existing global google_compute_backend_bucket.
Why it matters: Regional load balancing topologies that rely on backend buckets previously required workarounds or manual configuration. This resource closes that gap for region-scoped architectures.
Migration steps:
1. If you previously managed regional backend buckets via google_compute_backend_bucket with regional overrides or via google_compute_backend_service, evaluate whether migrating to google_compute_region_backend_bucket better reflects your intent.
2. Import existing regional backend buckets using terraform import google_compute_region_backend_bucket. if applicable.
---
New Resource: `google_hypercomputecluster_cluster`
Introduces Terraform management for HyperComputeCluster resources, enabling IaC lifecycle control over high-performance compute clusters.
Why it matters: Teams provisioning HyperCompute workloads can now bring cluster configuration under version control and state management rather than relying on manual API calls or gcloud commands.
Migration steps:
1. For existing clusters, use terraform import google_hypercomputecluster_cluster. to bring them under Terraform management.
2. Review the resource schema carefully before importing to avoid unintended in-place changes.
---
New Resource: `google_network_services_agent_gateway`
Adds a new resource for managing Network Services Agent Gateways within Terraform.
Why it matters: Agent Gateway configurations can now be version-controlled and deployed consistently across environments, reducing configuration drift in network service meshes.
Migration steps:
1. No migration required for new deployments. For existing gateways, plan an import strategy before referencing this resource.
---
Field Addition: `logging` on `google_beyondcorp_security_gateway`
The logging field has been added to the google_beyondcorp_security_gateway resource, enabling log configuration to be managed alongside the gateway definition.
Why it matters: Security teams requiring audit trails for BeyondCorp gateway traffic can now enforce logging configuration through IaC rather than through the console or separate tooling.
Migration steps:
1. Add the logging block to existing google_beyondcorp_security_gateway configurations if logging is desired.
2. Run terraform plan to confirm no unintended drift is introduced on existing gateways that may already have logging configured outside Terraform.
---
Field Addition: `direct_vpc_network_interface` and `direct_vpc_egress` on `google_cloudfunctions2_function`
⚠️ Potential plan diff for existing users. These two fields expose DirectVPC configuration for Cloud Functions (2nd gen). If DirectVPC was previously enabled directly on the underlying Cloud Run service — outside of Terraform — the provider will now detect and surface that configuration as a diff.
Why it matters: This is the highest-friction change in this release for teams with hybrid management of Cloud Functions and Cloud Run. A plan diff does not indicate breakage, but it does require deliberate reconciliation.
Migration steps:
1. Run terraform plan before upgrading in production to identify any affected google_cloudfunctions2_function resources.
2. If a diff appears on direct_vpc_network_interface or direct_vpc_egress, explicitly set these fields in your Terraform configuration to match the current deployed state.
3. Avoid applying without reviewing the diff — an unreviewed apply could modify VPC egress settings on live functions.
---
Field Addition: `iap_enabled` on `google_cloud_run_v2_service`
The iap_enabled boolean field has been added to google_cloud_run_v2_service, allowing Identity-Aware Proxy to be toggled directly on Cloud Run v2 services.
Why it matters: Previously, enabling IAP on Cloud Run v2 required steps outside the resource definition. This field brings that control into the Terraform lifecycle.
Migration steps:
1. For services where IAP is already enabled via other means, set iap_enabled = true in the resource block to prevent drift.
2. Confirm IAP OAuth client configuration is in place before enabling this field on production services.
---
Field Addition: `wait_for_completion` on `google_dataproc_job`
Adds a wait_for_completion field to google_dataproc_job, giving Terraform the ability to block until a submitted Dataproc job reaches a terminal state.
Why it matters: Workflows that depend on job output or downstream resource creation after a Dataproc job completes can now express that dependency natively, rather than relying on null_resource polling hacks or external orchestration.
Migration steps:
1. Set wait_for_completion = true in configurations where downstream resources depend on job completion.
2. Be aware that this will increase terraform apply wall-clock time proportional to job duration.
---
Field Addition: `disable_analytics` on `google_discovery_engine_search_engine`
The disable_analytics field has been added to google_discovery_engine_search_engine, enabling teams to opt out of analytics collection at the resource level.
Why it matters: Organizations with data residency or privacy requirements can now enforce analytics opt-out through IaC policy rather than post-deployment configuration.
Migration steps:
1. Set disable_analytics = true in configurations where analytics collection is not permitted.
2. No action required if the default behavior (analytics enabled) is acceptable.
---
Field Addition: `targets.cloud_storage_target.filter.collection.include_tags` on `google_data_loss_prevention_discovery_config`
A new nested block include_tags has been added under targets.cloud_storage_target.filter.collection in google_data_loss_prevention_discovery_config.
Why it matters: DLP discovery scopes can now be filtered by resource tags at the collection level, enabling more granular control over which Cloud Storage objects are subject to discovery scans.
Migration steps:
1. Review existing google_data_loss_prevention_discovery_config resources to determine whether tag-based filtering should be applied.
2. Add the include_tags block only where intentional scoping is needed — omitting it preserves existing behavior.
---
Field Additions: `client_id`, `client_secret`, `client_secret_sha256` on `google_iap_settings`
Three fields have been added to google_iap_settings to support OAuth client configuration directly within the resource.
Why it matters: IAP OAuth client credentials can now be managed within the same resource block as other IAP settings, reducing the number of separate resources or manual steps required to configure IAP end-to-end.
Migration steps:
1. If OAuth client credentials are currently managed separately, evaluate consolidating them into google_iap_settings.
2. Treat client_secret as sensitive — ensure it is sourced from a secrets manager or environment variable rather than hardcoded in configuration files.
3. Note that client_secret_sha256 is likely a computed/read field; verify in the schema before attempting to set it explicitly.
---
Field Additions: `mirroring_deployment_groups` and `mirroring_endpoint_group_type` on `google_network_security_security_profile`
Two fields have been added to google_network_security_security_profile to support traffic mirroring configuration.
Why it matters: Security profiles can now express mirroring topology directly, enabling packet mirroring for inspection workloads to be defined alongside the security profile rather than through separate resources.
Migration steps:
1. For existing security profiles used with mirroring, add these fields to align Terraform state with deployed configuration.
2. Run terraform plan to verify no unintended changes are triggered on existing profiles.
---
Behavior Fix: Perma-diff on `http_target.uri_override.query_override` in `google_cloud_tasks_queue`
A persistent plan diff on http_target.uri_override.query_override in google_cloud_tasks_queue has been resolved.
Why it matters: Teams using HTTP target queues with URI overrides were seeing spurious diffs on every plan, which degraded confidence in plan output and complicated CI/CD pipelines.
Migration steps:
1. After upgrading, run terraform plan on affected queues to confirm the diff no longer appears.
2. No configuration changes are needed — this is a provider-side fix.
---
Behavior Fix: `force_destroy` pagination bug in `google_storage_bucket`
A bug where force_destroy = true failed to delete buckets containing a large number of objects has been fixed. The root cause was missing pagination when listing objects prior to deletion.
Why it matters: In production environments with high-object-count buckets, terraform destroy or resource replacement operations could fail silently or partially, leaving buckets in an inconsistent state.
Migration steps:
1. No configuration changes are required.
2. Teams that previously worked around this bug with manual object deletion scripts can validate that force_destroy = true now handles large buckets reliably after upgrading.
---
Before You Upgrade
1. Run terraform plan against all workspaces using google_cloudfunctions2_function with DirectVPC configured — review any diffs on direct_vpc_network_interface or direct_vpc_egress before applying.
2. Check whether any google_cloud_tasks_queue resources with http_target.uri_override.query_override are in your state: terraform state list | grep google_cloud_tasks_queue.
3. Verify that google_storage_bucket resources with force_destroy = true are intentionally scoped — the pagination fix makes destruction more reliable, so confirm the right buckets carry this flag.
4. Audit google_iap_settings configurations to ensure client_secret values are not stored in plaintext within .tf files or version control.
5. For any google_beyondcorp_security_gateway resources, run terraform plan to check whether the new logging field surfaces a diff from out-of-band logging configuration.
6. Review google_network_security_security_profile resources used with traffic mirroring and compare their current deployed state against Terraform state using terraform show.
7. If importing existing resources for any of the three new resource types (google_compute_region_backend_bucket, google_hypercomputecluster_cluster, google_network_services_agent_gateway), run imports in a non-production environment first.
8. Pin the provider version explicitly in required_providers before upgrading: version = "~> 7.21.0" — this prevents unintended upgrades during the validation window.
9. For google_dataproc_job resources, assess whether setting wait_for_completion = true is appropriate given your pipeline's timeout constraints, as it will extend apply duration.
10. Cross-reference any google_data_loss_prevention_discovery_config resources against your organization's data governance policies before adding include_tags filter blocks.
---
Sources & Timeline
| Source | URL |
|---|---|
| Release v7.20.0 — hashicorp/terraform-provider-google | https://github.com/hashicorp/terraform-provider-google/releases/tag/v7.20.0 |
| Release v7.21.0 — hashicorp/terraform-provider-google | https://github.com/hashicorp/terraform-provider-google/releases/tag/v7.21.0 |
Last verified: 2026-02-24 at 22:59 UTC