The Error Message
You’ve written your HCL, initialized your provider, and hit terraform plan. Instead of seeing a resource list, you’re staring at this blocking error:
Error: google: could not find default credentials
This usually happens because the Google Cloud provider can't find a valid identity to authorize your API requests. It's a common roadblock, but you can typically resolve it in under 60 seconds.
Why This Happens
Terraform doesn't automatically know who you are just because you're logged into the GCP Console in your browser. It relies on a specific handshake called Application Default Credentials (ADC). Even if you have run gcloud auth login, Terraform requires a separate step to access those credentials for local execution.
Terraform hunts for your identity in this specific order of operations:
- The
credentialsattribute defined directly in yourprovider "google"block. - The
GOOGLE_APPLICATION_CREDENTIALSenvironment variable pointing to a JSON key. - The local ADC file generated by the Google Cloud CLI.
- The Metadata server (only if you are running inside a GCE instance or GKE cluster).
If the provider checks all four locations and comes up empty, it throws the error and stops.
Step-by-Step Fix
Solution 1: Using gcloud Application Default Login (Recommended)
90% of the time, this is the only fix you need. It's the most secure method for local work because it uses your user identity without requiring you to manage or store risky service account keys.
Open your terminal and run:
gcloud auth application-default login
A browser tab will trigger automatically. Log in with your Google account and click "Allow." Once the flow completes, the CLI generates a small JSON file (roughly 2.3 KB) at one of these locations:
- Linux/macOS:
~/.config/gcloud/application_default_credentials.json - Windows:
%APPDATA%\gcloud\application_default_credentials.json
Try running terraform plan again. It should work immediately.
Solution 2: Setting the Environment Variable
If you are working in a CI/CD pipeline or need to impersonate a specific Service Account, use an environment variable. This tells Terraform exactly which JSON key file to use.
- Download your Service Account JSON key from the GCP IAM Console.
- Map the path in your current shell session:
For macOS/Linux:
export GOOGLE_APPLICATION_CREDENTIALS="/Users/username/keys/my-sa-key.json"
For Windows (PowerShell):
$env:GOOGLE_APPLICATION_CREDENTIALS="C:\Users\username\keys\my-sa-key.json"
Solution 3: Explicit Provider Configuration
You can hardcode the credential path directly in your code. Use this sparingly; it's risky for shared projects because it creates a dependency on a local file path that your teammates might not have.
provider "google" {
project = "production-project-123"
region = "us-central1"
credentials = file("local-auth-key.json")
}
Important: If you go this route, add *.json to your .gitignore immediately to prevent leaking secrets to your repository.
Verification: Did it Work?
To confirm Terraform sees your credentials, run a simple plan. You don't need to commit to any infrastructure changes yet.
terraform plan
If you see "No changes. Your infrastructure matches the configuration," you are successfully authenticated. If the error persists, restart your terminal to ensure the new environment variables have loaded.
You can also verify the ADC file exists by running:
# macOS/Linux
cat ~/.config/gcloud/application_default_credentials.json | grep "client_id"
Pro-Tips for GCP Authentication
Authentication issues often stem from "environment drift"—where your local settings don't match your cloud project requirements. Here is how to keep things clean:
- Ditch long-lived keys: Use
gcloud auth application-default logininstead of downloading JSON keys. It’s significantly harder to accidentally leak your personal login than a static file. - Watch your Project ID: Sometimes the credentials are valid, but the project is wrong. Explicitly set your target project via
export GOOGLE_CLOUD_PROJECT="your-project-id"to avoid confusion. - Generate Secure Strings: When your Terraform code requires random passwords for SQL users or metadata, use a tool like the Password Generator on ToolCraft. It creates high-entropy strings locally, keeping your secrets off the public internet.
- Check Permissions: If the error changes to "403 Forbidden," your credentials are found, but your account lacks the
Service Usage Consumerrole. This role is mandatory for making almost any API call in a GCP project.

