Terraform providers are the link between your HCL configuration files and the APIs of cloud platforms, SaaS services, and other infrastructure systems. They're the backbone of infrastructure as code. How well you configure, manage, and version them decides whether your deployments stay reproducible as your team and infrastructure grow. This guide covers Terraform provider management end to end, from basic configuration to the advanced patterns and practices you'll want in enterprise environments. Whether you're on Terraform or the open-source [OpenTofu](/learning-center/what-is-opentofu) fork, the configuration model is identical. Both use the same provider plugin protocol. ## What Are Terraform Providers? A Terraform provider is a plugin that lets Terraform talk to a specific cloud provider (AWS, Azure, Google Cloud), a SaaS platform, an API, or any external service with a REST or gRPC interface. The provider configuration tells Terraform how to authenticate and connect to those services. ![Diagram showing the Terraform provider flow from API to SDK to provider plugin to HCL configuration](/images/blog/azurerm-terraform-provider-overview-898fb5d0.png) Without a configured provider, Terraform has no way to manage your resources. Each provider plugin adds a set of resource types and data sources that your infrastructure code can then manage. ### Core Provider Responsibilities Providers handle: - **Authentication**: Managing credentials, tokens, and API keys - **API Communication**: Making calls to cloud provider APIs - **Resource Management**: Creating, updating, and destroying infrastructure objects - **Data Source Queries**: Retrieving information about existing infrastructure - **Service-Specific Features**: Handling region/location selection, custom endpoints, and other platform-specific settings ## Provider Blocks and Configuration Configuring a provider takes two steps: declare the required providers, then configure them. ### Step 1: Declare Required Providers Provider requirements are defined in the `required_providers` block within the top-level `terraform` block. This tells Terraform where to find each provider and which versions are acceptable. ```hcl terraform { required_providers { aws = { source = "hashicorp/aws" version = "~> 5.0" } azurerm = { source = "hashicorp/azurerm" version = ">= 3.0.0, < 4.0.0" } google = { source = "hashicorp/google" version = "~> 5.0" } } } ``` Each provider entry specifies: - **Local name** (e.g., `aws`): How you reference the provider in your configuration - **Source**: The full address of the provider (format: `[hostname/]namespace/type`) - **Version constraint**: Which versions are compatible with your configuration ### Step 2: Configure the Provider After declaring requirements, configure providers with `provider` blocks. This is where you specify authentication details and default settings. ```hcl # Default AWS provider provider "aws" { region = "us-east-1" # Authentication typically handled via environment variables or IAM roles } # Azure provider provider "azurerm" { features {} } # Google Cloud provider provider "google" { project = "my-gcp-project" region = "us-central1" } ``` ### default_tags and Provider-Level Defaults The AWS provider's `default_tags` block applies a tag set to every taggable resource the provider manages, so it's the natural home for cost-allocation and ownership tags: ```hcl provider "aws" { region = "us-east-1" default_tags { tags = local.standard_tags } } ``` Two failure modes show up repeatedly in Scalr's support queue, both involving the gap between what's written in the `default_tags` block and what actually lands in `tags_all`. The first is merge-vs-replace semantics. A platform team we worked with at Scalr defined `default_tags { tags = local.standard_tags }` in code, with cost-centre, environment, and app-tier tags, while their management platform layered its own default tag on top with duplicate-tag behavior set to "skip". They expected the two layers to merge. Instead, the platform-level tags replaced the code-level block entirely, and the cost-allocation tags vanished from `tags_all` on every resource. If anything in your toolchain injects default tags above the code level, confirm whether the layers merge or replace before you depend on either. The second is expressions inside `default_tags`. One Scalr customer set `Project = var.app_name` and `Environment = var.environment` in the block, and their plans showed the literal strings `"var.app_name"` and `"var.environment"` in `tags_all`, alongside the warning `Could not auto-resolve dynamic AWS default_tags via Terraform; using statically-parsed tags.` Tooling that statically parses provider blocks, like cost estimators and tag-policy checkers, can't resolve variable references the way Terraform itself does. Use plain values in `default_tags` where you can, and either way, check the resolved tags in plan output rather than trusting the source. ### Authentication Best Practices Never hardcode credentials in your configuration files. Instead: 1. **Use Environment Variables**: Set `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`, etc. before running Terraform 2. **Use IAM Roles**: In AWS environments, use instance profiles or EKS service accounts 3. **Use Service Accounts**: In GCP and Azure, use service account keys or managed identities 4. **Implement OIDC**: For CI/CD pipelines, use OpenID Connect for short-lived, credential-free authentication 5. **Secrets Management**: Integrate with HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault ## Provider Aliases for Multi-Region and Multi-Account Deployments When you need more than one configuration of the same provider, use provider aliases. You'll want them for: - Deploying resources across multiple AWS regions - Managing resources in different AWS accounts - Using different API endpoints or authentication methods - Creating resources in multiple cloud providers simultaneously ### Defining Provider Aliases ```hcl # Default provider for us-east-1 provider "aws" { region = "us-east-1" } # Aliased provider for us-west-2 provider "aws" { alias = "west" region = "us-west-2" } # Aliased provider for eu-west-1 provider "aws" { alias = "europe" region = "eu-west-1" } ``` ### Using Aliases in Resources Resources use the default provider unless explicitly specified: ```hcl # Uses default us-east-1 provider resource "aws_instance" "app_east" { ami = "ami-0c55b31ad20f0c502" instance_type = "t3.micro" tags = { Name = "app-east" } } # Uses west alias (us-west-2) resource "aws_instance" "app_west" { provider = aws.west ami = "ami-068f09e03c69f0b76" instance_type = "t3.micro" tags = { Name = "app-west" } } # Uses europe alias (eu-west-1) resource "aws_vpc" "europe_vpc" { provider = aws.europe cidr_block = "10.0.0.0/16" tags = { Name = "europe-vpc" } } ``` ### Passing Aliases to Modules When using modules that require specific provider configurations, pass them via the `providers` argument: ```hcl module "vpc_east" { source = "./modules/vpc" # Uses default provider } module "vpc_west" { source = "./modules/vpc" providers = { aws = aws.west } cidr_block = "10.1.0.0/16" } ``` The child module must declare the provider in its `required_providers` block. ## Provider Requirements and Version Constraints Provider requirements are what make your deployments reproducible. They pin the specific provider versions that get downloaded and used in every environment. ### Version Constraint Operators Terraform supports several operators for expressing version constraints: | Operator | Description | Example | Effect | | --- | --- | --- | --- | | `=` | Exact version | `= 5.0.0` | Only version 5.0.0 | | `!=` | Exclude version | `!= 5.0.1` | Any version except 5.0.1 | | `>` | Greater than | `> 5.0.0` | Version 5.0.1 and newer | | `>=` | Greater or equal | `>= 5.0.0` | Version 5.0.0 and newer | | `<` | Less than | `< 6.0.0` | Versions before 6.0.0 | | `<=` | Less or equal | `<= 5.10.0` | Version 5.10.0 and earlier | | `~>` | Pessimistic constraint | `~> 5.0.0` | Only rightmost version component increments | ### Pessimistic Constraint Operator The `~>` operator is handy because it balances stability against automatic updates: - `~> 5.0` allows any version in the 5.x series (5.0.0, 5.1.0, 5.9.9) - `~> 5.0.0` allows only patch updates (5.0.0, 5.0.1, 5.0.99) - `~> 5.1.0` allows patch updates starting from 5.1.0 ### Combining Constraints Create complex version ranges by combining constraints with commas: ```hcl terraform { required_providers { aws = { source = "hashicorp/aws" version = "~> 5.0, != 5.5.0" # Allow 5.x except 5.5.0 } azurerm = { source = "hashicorp/azurerm" version = ">= 3.50.0, < 4.0.0" # Range constraint } } } ``` ### Versioning Strategy by Use Case **Pinned versions (critical environments)**: Use exact versions ```hcl version = "5.67.1" # Exact version required ``` **Reusable modules (libraries)**: Use looser constraints for compatibility ```hcl version = ">= 5.0.0" # Specify minimum version only ``` **Root modules (applications)**: Use tight constraints for stability ```hcl version = "~> 5.67.0" # Allow patch updates only ``` ## Dependency Lock Files (.terraform.lock.hcl) The `.terraform.lock.hcl` file is Terraform's critical security and consistency mechanism. Introduced in Terraform 0.14, it records the exact provider versions and cryptographic checksums used in your configuration. ### Why Lock Files Matter Without lock files, `terraform init` grabs the newest provider version that matches your constraints every time it runs. That's how you get the "works on my machine" problem: different environments end up on different provider versions and start behaving differently. Lock files solve three problems: 1. **Reproducibility**: Ensures identical provider versions across all deployments 2. **Supply Chain Security**: Verifies provider package integrity through cryptographic checksums 3. **Cross-Platform Consistency**: Enables smooth collaboration across Linux, macOS, and Windows systems ### Lock File Structure A `.terraform.lock.hcl` file has this structure: ```hcl # This file is maintained automatically by "terraform init". # Manual edits may be lost in future updates. provider "registry.terraform.io/hashicorp/aws" { version = "5.38.0" constraints = "~> 5.0" hashes = [ "h1:A2B3C4D5E6F7G8H9I0J1K2L3M4N5O6P7Q8R9S0T1U2V3W4X5Y6Z7A8B9C0D1E2F3", "zh:0573de96ba316d808be9f8d6fc8e8e68e0e6b614ed4d8d11eed83062c9b60714", "zh:37560469042f5f43fdb961eb6c6b7f6e0bccec04c1c7cbf90f5d6d97893e6c3d", # Additional platform-specific hashes... ] } provider "registry.terraform.io/hashicorp/azurerm" { version = "3.85.0" constraints = ">= 3.0, < 4.0" hashes = [ # Hashes for this provider... ] } ``` Each provider block contains: - **version**: The exact provider version selected - **constraints**: The version constraints from your configuration - **hashes**: Cryptographic checksums for provider packages on different platforms ### When Lock Files Are Created and Updated - **Initial creation**: When running `terraform init` for the first time - **During updates**: When running `terraform init -upgrade` or `terraform init` with new providers - **Platform additions**: When Terraform installs a provider on a new OS/architecture combination Lock files are NOT updated during `terraform plan`, `terraform apply`, or `terraform destroy` operations. ### Platform-Specific Hash Management Lock files created on one platform (e.g., macOS) only contain checksums for that architecture. To support multi-platform teams, pre-populate checksums: ```bash terraform providers lock \ -platform=linux_amd64 \ -platform=darwin_amd64 \ -platform=darwin_arm64 \ -platform=windows_amd64 ``` This ensures your lock file works across all team members' development machines and CI/CD pipelines. ### Lock File Best Practices - **Always commit to version control**: Never add `.terraform.lock.hcl` to `.gitignore` - **Review lock file changes**: Treat lock file updates like code changes in pull requests - **Use intentional upgrades**: Only run `terraform init -upgrade` when you explicitly want to update providers - **Pre-populate for multiple platforms**: Especially critical for teams with mixed OS environments - **Separate lock files per configuration**: Each independent Terraform configuration has its own lock file ## Lock File Debugging and Troubleshooting Lock file issues come up a lot, especially on multi-platform teams. Knowing how to diagnose and fix them saves you a bad afternoon. ### Checksum Mismatch Errors The most common error: ``` ERROR: Failed to install provider Error while installing hashicorp/null v3.2.4: the current package for registry.terraform.io/hashicorp/null 3.2.4 doesn't match any of the checksums previously recorded in the dependency lock file. ``` **Causes:** - Lock file created on one platform (macOS) used on another (Linux CI/CD) - Provider version constraints updated without updating the lock file - Corrupted local plugin cache - Provider binary tampering (security risk) **Solutions:** **Delete and reinitialize** (last resort): ```bash rm .terraform.lock.hcl terraform init ``` **Upgrade providers intentionally**: ```bash terraform init -upgrade ``` Then commit the updated lock file. **Add checksums for all platforms** (most common fix): ```bash terraform providers lock \ -platform=linux_amd64 \ -platform=darwin_amd64 ``` ### Stale Lock Files **Problem**: Version constraints updated but lock file not refreshed **Solution**: ```bash terraform init -upgrade git add .terraform.lock.hcl git commit -m "Update provider versions" ``` ### Merge Conflicts in Lock Files **Problem**: Multiple developers update different providers simultaneously **Solution**: After resolving the merge conflict, run `terraform init` to validate all entries: ```bash # Manually resolve conflict in .terraform.lock.hcl terraform init git add .terraform.lock.hcl git commit -m "Resolve lock file merge conflict" ``` ## Provider Authentication Patterns Different providers and environments call for different ways to authenticate. ### Environment Variables The simplest method for development: ```bash # AWS export AWS_ACCESS_KEY_ID="your-key" export AWS_SECRET_ACCESS_KEY="your-secret" # Azure export ARM_CLIENT_ID="your-client-id" export ARM_CLIENT_SECRET="your-secret" export ARM_TENANT_ID="your-tenant-id" # GCP export GOOGLE_CREDENTIALS='{"type": "service_account", ...}' ``` ### Cloud-Native Authentication **AWS IAM Roles** (recommended for EC2, ECS, Lambda): ```hcl provider "aws" { region = "us-east-1" # Automatically uses EC2 instance role credentials } ``` **Azure Managed Identities**: ```hcl provider "azurerm" { features {} # Automatically uses managed identity credentials } ``` **GCP Service Accounts**: ```hcl provider "google" { project = "my-project" # Automatically uses default application credentials } ``` ### OIDC for CI/CD Pipelines The most secure approach for [automated deployments](/learning-center/building-robust-terraform-opentofu-pipelines-the-ultimate-ci-cd-guide). (Note: [Terraform Cloud's free tier was discontinued on March 31, 2026](/learning-center/hcp-terraform-free-tier-is-being-discontinued-what-you-need-to-know). Scalr and Spacelift offer the same OIDC flow.) ```hcl terraform { cloud { organization = "my-org" hostname = "app.terraform.io" } } provider "aws" { region = "us-east-1" # Terraform Cloud handles OIDC token exchange for short-lived credentials } ``` OIDC gets rid of static credentials, but it moves the failure surface into the IAM trust policy, and trust policies fail in ways that are hard to diagnose from the Terraform side. Two incidents from our own support queue show the patterns to watch for. In the first, an engineer at a customer tidied up what looked like a redundant condition in the trust policy of an IAM role, one role that, undocumented, backed both their state storage and their provider authentication. The two subsystems issue OIDC tokens with different `sub` claim formats: the storage integration's tokens carry a subject like `scalr:account:`, while provider-configuration tokens carry `account::environment:...:workspace:...`. With one of the two `StringLike` patterns removed, every run in the organization failed, surfacing as a pair of errors that look unrelated: `Cannot download the configuration version due to i/o error` from the storage side and `AccessDenied ... Not authorized to perform sts:AssumeRoleWithWebIdentity` from the provider side. The whole org was blocked until both subject patterns were restored. Two lessons: different token issuers within the same platform can use different `sub` formats, and sharing one IAM role across state storage and provider auth without documenting it turns a one-line policy edit into an org-wide outage. In the second, a team in a regulated industry copy-pasted a working commercial-AWS OIDC trust policy into their GovCloud account and got 403s on every assume-role call. GovCloud is a separate AWS partition: it needs its own OIDC identity provider resource registered in that partition, with its own thumbprints and ARNs. A trust policy is a per-partition, per-account artifact, not portable configuration you can lift between accounts. ### Secrets Management Integration For sensitive credentials, integrate with dedicated systems: ```hcl provider "aws" { region = "us-east-1" assume_role { role_arn = "arn:aws:iam::123456789012:role/terraform-role" } } ``` ## Popular Terraform Providers Overview ### AWS (Amazon Web Services) The most widely used provider for cloud infrastructure. ```hcl terraform { required_providers { aws = { source = "hashicorp/aws" version = "~> 5.0" } } } provider "aws" { region = "us-east-1" } resource "aws_vpc" "main" { cidr_block = "10.0.0.0/16" tags = { Name = "main-vpc" } } resource "aws_subnet" "main" { vpc_id = aws_vpc.main.id cidr_block = "10.0.1.0/24" availability_zone = "us-east-1a" } ``` See detailed guides: [Top 10 Most Popular Terraform Providers](/learning-center/top-10-most-popular-terraform-providers) and [AWS Provider v6.0: What's Breaking in April 2025](/learning-center/aws-provider-v6-0-whats-breaking-in-april-2025) ### Azure (Microsoft Azure) For managing resources in Microsoft's cloud platform. ```hcl terraform { required_providers { azurerm = { source = "hashicorp/azurerm" version = "~> 3.0" } } } provider "azurerm" { features {} } resource "azurerm_resource_group" "main" { name = "example-resources" location = "East US" } resource "azurerm_storage_account" "main" { name = "examplestg" resource_group_name = azurerm_resource_group.main.name location = azurerm_resource_group.main.location account_tier = "Standard" account_replication_type = "LRS" } ``` ### Google Cloud (GCP) For Google Cloud Platform infrastructure. ```hcl terraform { required_providers { google = { source = "hashicorp/google" version = "~> 5.0" } } } provider "google" { project = "my-gcp-project" region = "us-central1" } resource "google_storage_bucket" "main" { name = "my-unique-bucket-name" location = "US" force_destroy = false } resource "google_compute_instance" "main" { name = "web-server" machine_type = "e2-micro" zone = "us-central1-a" } ``` ### Kubernetes For managing Kubernetes clusters and resources. ```hcl terraform { required_providers { kubernetes = { source = "hashicorp/kubernetes" version = "~> 2.0" } } } provider "kubernetes" { config_path = "~/.kube/config" config_context = "my-cluster" } resource "kubernetes_namespace" "example" { metadata { name = "example-namespace" } } resource "kubernetes_deployment" "example" { metadata { name = "example-deployment" namespace = kubernetes_namespace.example.metadata[0].name } spec { replicas = 3 # ... deployment specification } } ``` ![Kubernetes service distributing traffic across pods created by a Terraform deployment](/images/blog/kubernetes-terraform-provider-f13beb26.png) See detailed guide: [Mastering Kubernetes with Terraform: A Provider Deep Dive](/learning-center/mastering-kubernetes-with-terraform-a-provider-deep-dive) ### Datadog For monitoring and observability infrastructure. ```hcl terraform { required_providers { datadog = { source = "DataDog/datadog" version = "~> 3.0" } } } provider "datadog" { api_key = var.datadog_api_key app_key = var.datadog_app_key api_url = "https://api.datadoghq.com/" } resource "datadog_monitor" "cpu_alert" { type = "metric alert" query = "avg(last_5m):avg:system.cpu.user{*} > 0.9" message = "CPU utilization is high" } ``` ![A Datadog dashboard populated with metrics from Terraform runs executed in Scalr](/images/blog/how-to-use-terraform-or-opentofu-to-manage-datadog-3257a198.png) See detailed guide: [How to Use Terraform or OpenTofu to Manage Datadog](/learning-center/how-to-use-terraform-or-opentofu-to-manage-datadog) ### Okta For identity and access management. ```hcl terraform { required_providers { okta = { source = "okta/okta" version = "~> 4.0" } } } provider "okta" { org_name = var.okta_org_name base_url = "okta.com" api_token = var.okta_api_token } resource "okta_user" "example" { first_name = "John" last_name = "Doe" login = "john.doe@example.com" email = "john.doe@example.com" } ``` See detailed guide: [How to Use the Terraform Okta Provider](/learning-center/how-to-use-the-terraform-okta-provider) ## Best Practices for Terraform Providers in 2026 ### 1\. Version Management and Lock Files - **Always use explicit version constraints**: Never leave providers unconstrained - **Commit lock files to version control**: These should never be ignored - **Pre-populate multi-platform checksums**: Essential for diverse teams - **Document provider updates**: Include context in commit messages and pull requests - **Automate provider updates**: Use scheduled pipelines to test and merge minor/patch version updates ### 2\. Credential and Authentication Security - **Never hardcode credentials**: This is non-negotiable - **Use OIDC for CI/CD**: Eliminate static credentials in automation - **Implement least privilege**: Grant only necessary IAM permissions - **Rotate credentials regularly**: Especially for long-lived API keys - **Separate credentials per environment**: Use different accounts for dev/staging/prod - **Audit credential usage**: Monitor provider authentication and API calls ### 3\. Multi-Provider and Multi-Account Strategies - **Use aliases strategically**: Only when managing distinct configurations of the same provider - **[Separate configurations by environment](/learning-center/managing-multiple-terraform-environments-a-practical-guide)**: Use directory structure (environments/dev, environments/prod) rather than workspaces - **Use IaC platforms for credential management**: Tools like Scalr centralize provider credentials and enforce policies - **Document provider architecture**: Maintain clear diagrams showing which providers manage which infrastructure ### 4\. Module Design with Providers - **Declare required providers in all modules**: Even if inheriting from parent - **Pass aliases explicitly to [modules](/learning-center/terraform-modules-explained)**: Use the providers map in module blocks - **Use provider defaults judiciously**: Only for the primary use case - **Version external modules carefully**: Test provider version compatibility before upgrades ### 5\. Environment Management - **Separate lock files per environment**: Don't share lock files across dev/staging/prod - **Use environment-specific .tfvars**: Parameterize provider configurations - **Implement automated testing**: Validate provider configurations in pipelines - **Plan for disaster recovery**: Ensure provider credentials are secured and backed up ### 6\. Operational Excellence - **Monitor provider API usage**: Track rate limiting and quota consumption - **Document custom provider configurations**: Especially for complex alias setups - **Standardize on approved providers**: Avoid provider proliferation through governance - **Regular provider audits**: Review which providers are in use and if all are actively managed - **Test provider migrations**: Plan upgrades carefully, especially major versions ### 7\. Enterprise Considerations - **Centralize provider credential management**: Use IaC platforms rather than distributed .env files - **Enforce provider version policies**: Use [policy-as-code (OPA)](/learning-center/enforcing-policy-as-code-in-terraform-a-comprehensive-guide) to prevent breaking changes - **Implement approval workflows**: For sensitive provider configurations or multi-account access - **Maintain provider registries**: Consider private registries for internal or vetted providers - **Cross-team coordination**: Document provider ownership and support contacts ## Common Provider Configuration Pitfalls ### Unconstrained Provider Versions **Problem**: Provider blocks without version constraints allow unexpected major version upgrades ```hcl # BAD: No version constraint terraform { required_providers { aws = { source = "hashicorp/aws" # Missing version! } } } ``` **Solution**: Always specify meaningful version constraints ```hcl # GOOD: Explicit version constraint terraform { required_providers { aws = { source = "hashicorp/aws" version = "~> 5.0" # Allow patch updates only } } } ``` ### Hardcoded Credentials **Problem**: Credentials visible in source code and version control ```hcl # BAD: Never do this provider "aws" { access_key = "AKIAIOSFODNN7EXAMPLE" secret_key = "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY" region = "us-east-1" } ``` **Solution**: Use environment variables or cloud-native authentication ```hcl # GOOD: Credentials from environment provider "aws" { region = "us-east-1" # Uses AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables } # BETTER: Use IAM roles or OIDC provider "aws" { region = "us-east-1" # Automatically uses IAM role credentials } ``` ### Missing Lock Files in Version Control **Problem**: Lock file ignored or not committed, leading to inconsistent provider versions **Solution**: ```bash # Remove from .gitignore if present git rm --cached .terraform.lock.hcl # Commit the lock file git add .terraform.lock.hcl git commit -m "Add Terraform provider lock file" ``` ### Inconsistent Provider Configurations Across Modules **Problem**: Root module configures providers but modules redefine them differently **Solution**: Configure providers only in root modules, have modules declare requirements without configuration ```hcl # In root module provider "aws" { region = "us-east-1" } # In child module terraform { required_providers { aws = { source = "hashicorp/aws" version = "~> 5.0" } } } # No provider block here - inherits from root ``` ### Assuming Provider Credentials Reach Subprocesses **Problem**: Credentials configured in a provider block authenticate the provider plugin and nothing else. Anything Terraform shells out to, like a `local-exec` provisioner, starts with the runner's own environment and walks the default credential chain from there. A storage team we worked with at Scalr hit this with a `terraform_data` resource running `aws storagegateway update-gateway-information` through `local-exec`. The apply itself succeeded, since the provider's assume-role credentials were fine, but the CLI call failed with `AccessDeniedException ... assumed-role/-instance-profile/i-... is not authorized`. The AWS CLI had fallen back to the runner's EC2 instance profile, a completely different identity from the one the provider was using. The same configuration had worked in their lab environment and failed in dev, because the two environments differed in whether assumed-role credentials were exported into the shell. **Solution**: If a provisioner or external script needs the provider's identity, export the assumed-role credentials into the subprocess environment explicitly (for example, via an `assume-role` wrapper that sets `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`, and `AWS_SESSION_TOKEN`). Do not assume the provider's auth context leaks downward. It doesn't. ### Confusing Provider Configurations with Input Variables **Problem**: On IaC platforms, a "provider configuration" object attached to a workspace supplies credentials to the provider. It does not populate Terraform input variables. The two are separate delivery mechanisms that happen to carry similar data. A platform team migrating from Terraform Cloud created a GitHub App provider configuration (with `github_app_id`, `github_app_pem_file`, and `github_app_installation_ids`), linked it to their workspace, and every plan failed with `Error: No value for required variable` for all three. A pre-plan dump of the environment confirmed it: no `TF_VAR_*` injection at all, because their module declared those values as input variables, which provider configurations never set. Removing the `app_auth` block from the provider just moved the failure to `401 Requires authentication`. The fix was recreating their old TFC variable-set wiring as workspace and shell variables. **Solution**: Check how each value reaches Terraform. Settings consumed inside a `provider` block can come from a platform provider configuration or environment variables; values declared as `variable` blocks need `TF_VAR_*` environment variables, workspace variables, or `.tfvars` entries. When migrating between platforms, inventory every variable set on the old platform and recreate it through the equivalent mechanism. Linking a provider configuration is not a substitute. ## Putting It All Together Terraform providers are the layer that turns your HCL into real API calls, so most of the failures in this guide trace back to how providers are configured, versioned, and authenticated. Get those three right and the rest of your pipeline has far less to go wrong. Five practices cover most of it: 1. **Be intentional** about version constraints and updates 2. **Prioritize security** in credential handling 3. **Maintain consistency** through lock files and clear documentation 4. **Automate** where possible to reduce manual errors 5. **Plan for scale** with multi-account and multi-environment strategies Whether you manage a single provider or run deployments across several clouds and accounts, the practices in this guide give you something solid to build on. If you're running Terraform at scale, it's worth looking at an IaC management platform like Scalr. It centralizes provider credentials, enforces policies, and gives you visibility into how providers are configured and used across your whole infrastructure portfolio. Scalr's [pricing is usage-based](/pricing): you pay only for runs that execute, the free tier covers up to 50 runs a month, and there are no concurrent run slots to reserve in advance. * * * > This blog has been verified for Terraform and OpenTofu

Ryan Fee

Articles by Ryan Fee

Bring Your Own Key (BYOK): Customer-Managed Encryption for Terraform Platforms

Terraform State Storage: How to Bring Your Own S3, GCS, or Azure Bucket

Custom Hooks for Terraform and OpenTofu: Pre-Plan, Post-Apply, and the Hooks Registry

Host Your Own Terraform Providers in Scalr

Pull OpenTofu Modules Directly from OCI Registries in Scalr

OpenTofu + Atlantis vs a Managed Platform: When Self-Hosting Costs More

HashiCorp GPG Key Expired: Fixing Terraform Download Errors

How to Use a MCP Server with Terraform: 6 Prompts for Infrastructure Teams

Selecting a Terraform Cloud Alternative (2026 Guide)

Terraform Modules Explained

Stop Troubleshooting Terraform: How Scalr AI Helps Platform Teams

Terraform Drift Detection and Management: A Comprehensive Guide

Using Checkov with Terraform - Integrations, Features, Examples

What is a Terraform TACO?

What is Terraform?

Terraform Registry: Public vs Private Module Registries Explained

New Feature: Private Module Registry Namespaces

Terraform Outputs: How to with Examples

Terraform Providers: Complete Configuration and Management Guide

Terraform State Files Best Practices

Using the AWS S3 Backend Block in Terraform

Using the AzureRM Backend Block in Terraform

Using the GCS Backend Block in Terraform

Understanding the Terraform ignore_changes Lifecycle Block

Everything you need to know about using Terraform or OpenTofu with Slack

Scalr's MCP Server: The AI Assistant That Does the Heavy Lifting

Introducing Scalr Metrics

November 2025 Release Notes

New Scalr Feature: Control Tower

Scalr Product Updates - August 2025

Announcing a Simpler, More Transparent Pricing Model

What are Terraform Lock Files

Scalr Product Updates - July 2025

Dynamic Backend Blocks with OpenTofu

Scalr Product Updates - June 2025

How to Share Terraform State

A Guide to Terraform Audit Logs

Product Update: Scalr Federated Environments

Product Updates April 2025: Flexible Storage Options, Federation, and GitOps Workflows

Product Updates May 2025: Scalr OIDC, Improved GitOps Flows, and PR Comment Approval

About the Learning Center

Maintaining Terraform Module Health with Dependabot and Scalr

A beginner's guide to the terraform init command

Scalr vs Terraform Cloud Pricing (2026)

Terraform Random Provider

Using Terraform Workspace Prefixes in a Remote Backend

Scalr VSCode Extension for Terraform & OpenTofu

The Terraform & OpenTofu Terralith