Providers and resource dependencies

Terraform and a provider have different jobs

Terraform handles configuration, dependency ordering, plans, and state. A provider implements resource types and data sources for a system. For example, an AWS provider speaks AWS APIs; a local provider works with local resources. A resource declares an object Terraform manages. A data source reads information needed by the configuration without declaring ownership of that object.

Provider requirements name the source and allowed versions. Provider configuration supplies settings such as a region. These are different blocks. This is a reading example, not a reason to add AWS to the local fixture:

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 6.0"
    }
  }
}
provider "aws" {
  region = "us-east-1"
}

Here aws is the local provider name and hashicorp/aws its source address. The version constraint allows compatible 6.x releases; the dependency lock file records the selected version and package checksums. Commit that lock file for a root configuration using downloaded providers. The built-in provider from the first lesson does not require that download. Authentication still needs the provider's credential flow; a region setting grants no permissions.

Build a dependency you can explain

In the existing terraform-basics/main.tf, keep terraform_data.name and add:

resource "terraform_data" "label" {
  input = "study-${terraform_data.name.output}"
}

"study-${...}" inserts a value into a string. More importantly, the reference tells Terraform that label depends on the output of name. Terraform uses such references to build a directed dependency graph: arrows express what must be available before something else can be evaluated or changed. Independent operations may run concurrently.

Run terraform fmt, terraform validate, then terraform plan. If you applied the first lesson, expect the existing name to remain and one label to be added. If you cleaned it up, expect both additions. Its future input may be unknown during part of planning; unknown is not the same as an empty string or an error.

Move the label block above the name block and plan again. The intended relationship should be unchanged. Terraform loads configuration in this directory together; textual order is not the execution sequence. This is why a shell-script reading of Terraform gives the wrong intuition.

When a reference is not enough

Imagine a service depends on an access policy having been attached, but its arguments mention no value from that attachment. depends_on can express this hidden behavioral dependency. Use it where you can explain the missing relationship. Broad dependencies can make Terraform wait for more work and mark more values unknown than necessary.

Ordering does not prove application readiness. An API saying a VM exists does not establish that its application accepts requests. That needs an appropriate health or acceptance check after provisioning. Similarly, a data source's successful lookup does not mean Terraform will own or delete the looked-up object.

Practice and answers

Predict the result of renaming the local label name to base without updating the reference. Validation should reject the undeclared reference. Restore it; do not apply an accidental address change. Why might a provider install fail before any resource changes? Initialization needs the provider package and a version satisfying the constraints, independently of cloud authentication.

Next, replace hard-coded values with a small typed interface. Keep this fixture; it will grow to two resources and one useful output.

References: provider requirements↗, provider configuration↗, data sources↗, and depends_on↗.

Additional primary references: Built-in terraform_data↗.