The Terraform Google provider is the interface that allows Terraform to create, read, update and delete resources on Google Cloud Platform. It is a plugin that is sourced from the Terraform registry and is maintained by the Terraform team at Google and the Terraform team at HashiCorp. The provider exposes generally available features through the google namespace. Preview features or features at a beta launch stage are exposed through the google-beta provider. The provider version documentation describes how to use google-beta. The provider does not upgrade automatically once a workspace is initialized. After a new release the workspace can be upgraded with terraform init -upgrade. Version constraints can be set on the provider in configuration. The repository for the provider is generated by magic-modules. Work on the provider requires changes in magic-modules because changes made directly to the repository will likely be overwritten.
The provider is supported by community and documentation surfaces. Tutorials are published at learn.hashicorp.com. Discussion happens on discuss.hashicorp.com. Official documentation is published at https://www.terraform.io/docs/providers/google/index.html. A mailing list is hosted on Google Groups. These surfaces provide the context in which users learn how to configure the Google provider, how to authenticate, and how to manage provider versions.
Provider Identity and Maintenance
The Terraform Google provider is a plugin that allows Terraform to manage resources on Google Cloud Platform.
The provider is maintained by the Terraform team at Google and the Terraform team at HashiCorp.
This is the google provider, containing generally available features.
To use preview features or features at a beta launch stage, you may use the google-beta provider. Refer to the provider versions documentation for more information about how to use google-beta.
The maintenance split between Google and HashiCorp shapes the release cadence and feature stability. The provider is generated from magic-modules, which means the source of truth for resource definitions lives outside the repository. Changes made directly to the repository are likely to be overwritten on the next generation run. Anyone who wishes to work on the provider must make changes in magic-modules. This impacts contribution workflows because contributors must understand the generation pipeline rather than editing the provider repository directly.
Version Management and Upgrade Mechanics
The Google provider doesn't upgrade automatically once you've started using it.
After a new release you can run:
terraform init -upgrade
to upgrade to the latest stable version of the Google provider.
See the Terraform website for more information on provider upgrades, and how to set version constraints on your provider.
Automatic upgrade is disabled by design. Terraform pins provider versions in the workspace to ensure configuration stability. The terraform init -upgrade command is the explicit user action that refreshes the plugin binary from the registry. The impact is that teams control when breaking changes enter production. Version constraints can be expressed in the provider block to allow only a defined range of versions.
This repository is generated by magic-modules. If you wish to work on the provider, you'll need to make changes in magic-modules. Any changes made directly to this repository will likely be overwritten.
Provider 6.0.0 Release and Attribution Label
Announcing Terraform Google Provider 6.0.0: More Flexibility, Better Control.
Swati Chadha, Product Manager, Google.
Cameron Thornton, Software Engineer, Google.
The Terraform Google Provider v6.0.0 is now GA.
Since the last major Terraform provider release in September 2023, the combined Hashicorp/Google provider team has been listening closely to the community's feedback. Discussed below are the primary enhancements and bug fixes that this major release focuses on.
Support for earlier versions of HashiCorp Terraform will not change as a result of the major version release v6.0.0.
Highlights of version 6.0.0
The key notable changes are as follows:
- Opt-out default label “goog-terraform-provisioned”
- Deletion protection fields added to multiple resources
- Allowed reducing the suffix length in “name_prefix” for multiple resources
Opt-out default label goog-terraform-provisioned
As a follow-up to the addition of provider-level default labels in 5.16.0, the 6.0.0 major release includes an opt-out default label “goog-terraform-provisioned”.
This provider-level label “goog-terraform-provisioned” will be added to applicable resources to identify resources that were created by Terraform. This default label will only apply for newly created resources with a labels field.
This provider-level label will be added to applicable resources to identify resources that were created by Terraform. This default label will only apply for newly created resources with a labels field. This will enable users to have a view of resources managed by Terraform when viewing/editing these resources in other tools like Cloud Console, Cloud Billing etc.
The label “goog-terraform-provisioned” can be used for the following:
- To filter on the Billing Reports page:
- To view the Cost breakdown:
- The label can also be used with BigQuery export.
Please note that an opt-in version of the label was already released in 5.16.0, and 6.0.0 will change the label to opt-out. To opt-out of this default label, the users may toggle the add_terraform_attribution_label provider configuration field. This can be set explicitly using any release from 5.16.0 onwards and the value in configuration will apply after the 6.0.0 upgrade.
The impact for cost attribution is that resources created by Terraform become discoverable in billing and console views without manual labeling. Teams can filter billing reports and cost breakdowns by the label. The label also participates in BigQuery export pipelines. The opt-out model means existing workspaces will receive the label unless add_terraform_attribution_label is set to false. Setting the field explicitly from 5.16.0 onwards allows a controlled migration path.
When upgrading to version 6.0 of the Terraform Google Provider, please consult the upgrade guide on the Terraform Registry, which contains a full list of the changes and upgrade considerations. Please check out the Release notes for Terraform Google Provider 6.0.0 for more details on this major version release. Learn more about Terraform on Google Cloud in the Terraform on Google Cloud documentation.
Deletion Protection and Naming Controls
Deletion protection fields added to multiple resources.
In order to prevent the accidental deletion of important resources, many resources now have a form of deletion protection enabled by default.
These resources include google_domain, google_cloud_run_v2_job, google_cloud_run_v2_service, google_folder and google_project. Most of these are enabled by the deletion_protection field.
The addition of deletion protection changes the default destroy behavior. Resources that were previously removable with a single terraform destroy now require explicit disabling of protection. This protects organizational folders and projects from accidental removal.
Allowed reducing the suffix length in “name_prefix” for multiple resources.
Reducing suffix length reduces naming collisions and makes resource names more predictable while preserving uniqueness guarantees.
Authentication and Resource Categories
Complete guide to the Terraform Google Cloud Provider — project setup, Compute Engine, GKE, Cloud Storage, BigQuery, and GCP infrastructure automation. This comprehensive guide covers everything from initial setup to production-ready configurations.
Configure authentication using environment variables, configuration files, or instance profiles for security.
This provider offers hundreds of resource types. Here are the most commonly used ones that every Terraform practitioner should know.
Create and manage virtual machines, containers, and serverless functions. Each resource supports extensive configuration options for networking, storage, and security.
Build virtual networks, subnets, security groups, load balancers, and DNS configurations. Proper networking is the foundation of any cloud architecture.
Manage object storage, block storage, file systems, and databases. Configure encryption, lifecycle policies, and access controls.
Create roles, policies, and service accounts. Follow the principle of least privilege for all resource access.
Common issues include authentication failures, API rate limits, resource quotas, and eventual consistency delays.
Authentication can be performed via environment variables, configuration files, or instance profiles. The choice affects credential scope and rotation. Environment variables provide ad-hoc access. Configuration files provide persistent credentials. Instance profiles provide workload identity without long-lived secrets.
The provider supports hundreds of resource types. The commonly cited categories are compute, networking, storage, and IAM. Compute covers virtual machines, containers, and serverless functions with networking, storage and security configuration. Networking covers virtual networks, subnets, security groups, load balancers and DNS. Storage covers object storage, block storage, file systems and databases with encryption, lifecycle policies and access controls. IAM covers roles, policies and service accounts with least privilege guidance.
Common operational issues are authentication failures, API rate limits, resource quotas and eventual consistency delays. These issues manifest as plan failures, apply hangs and drift detection mismatches. Authentication failures block all API calls. Rate limits throttle API usage during large applies. Quotas block resource creation. Eventual consistency causes state to lag behind actual cloud state.
Provider Sourcing and Registry Workflow
Terraform providers are plugins that enable Terraform to interact with cloud platforms, SaaS providers, and other APIs.
Terraform sources providers from the Terraform registry by default, which hosts providers maintained by HashiCorp, our partners, and community members.
Each provider supports a set of resource types and data sources that you can manage with Terraform.
To use Terraform to manage resources for your chosen cloud platform, you must first install the corresponding provider and configure authentication.
With the provider installed, you can use Terraform to create and manage the resources it supports.
The Terraform registry is the default source for providers. The registry hosts providers maintained by HashiCorp, partners and community members. Each provider declares resource types and data sources. Installing a provider is a prerequisite to managing resources.
In this tutorial, you will learn how to source and version providers from the Terraform registry, configure and authenticate providers, and upgrade provider versions safely.
You will also learn how to configure multiple instances of the same provider using aliases and control which providers your Terraform modules use to provision infrastructure.
This tutorial assumes that you are familiar with the Terraform workflow. If you are new to Terraform, complete the Get Started collection first.
You can complete this tutorial using AWS, Azure, or Google Cloud Platform.
Select the tab at the top of the page for your preferred cloud provider.
To complete this tutorial, you will need:
Clone the example repository for this tutorial, which contains example Terraform configuration for you to use.
$ git clone https://github.com/hashicorp-education/learn-terraform-providers
Change to the repository directory for your preferred cloud vendor.
$ cd learn-terraform-providers/aws
The Terraform registry hosts publicly available Terraform providers and modules.
Before adding a provider to your configuration, review the provider documentation on the registry to understand the provider's capabilities and requirements.
Visit the AWS provider page in the Terraform registry.
The provider documentation includes:
- Documentation for all resources and data sources supported by the provider.
- Guides for authentication, upgrading your provider, and other use cases.
- A Use Provider button with example configuration you can copy into your workspace.
Terraform providers are distributed as plugins that Terraform downloads and installs when you initialize your workspace.
The tutorial workflow uses a cloned example repository to demonstrate provider sourcing. The registry documentation provides resource catalogs, authentication guides and upgrade guides. Providers are downloaded as plugins during terraform init.
Configuration and Tutorial Pathway
Please see instructions on how to configure the Google Provider.
The configuration step is the first user interaction after provider installation. Authentication must be established before resources can be created. Provider configuration also includes options such as add_terraform_attribution_label for controlling the default label behavior introduced in 5.16.0 and made opt-out in 6.0.0.
Provider surface summary
| Surface | Purpose |
|---|---|
| learn.hashicorp.com | Tutorials |
| discuss.hashicorp.com | Forum |
| https://www.terraform.io/docs/providers/google/index.html | Documentation |
| Google Groups | Mailing list |
Version 6.0.0 change summary
| Change | Scope |
|---|---|
| Opt-out default label “goog-terraform-provisioned” | Provider-level label applied to new resources with labels field |
| Deletion protection fields added | googledomain, googlecloudrunv2job, googlecloudrunv2service, googlefolder, google_project |
| Allowed reducing suffix length in name_prefix | Multiple resources |
The provider continues to be generated by magic-modules, maintained jointly by Google and HashiCorp, and distributed through the Terraform registry. Provider upgrades are manual via terraform init -upgrade. The 6.0.0 release introduces attribution labeling by default and strengthens safety via deletion protection. Authentication remains flexible across environment variables, configuration files and instance profiles. Common operational challenges remain authentication failures, API rate limits, quotas and eventual consistency.