Terraform Run Succeeds but Infrastructure Drift Appears in Subsequent Plans

Problem

A customer reported that Terraform runs in Terraform Cloud were completing successfully with no errors, but subsequent terraform plan runs consistently showed unexpected changes, even though no one had modified the infrastructure or code.

Symptoms observed:-

• terraform apply completes successfully

• Next terraform plan shows drift for multiple resources

• Drift appears mostly on tags, metadata, or optional attributes

• No manual changes detected in the cloud provider audit logs

This created confusion and loss of trust in Terraform’s idempotency, and customers hesitated to apply changes in production.

Cause

The root cause was a mismatch between provider default behavior and Terraform Cloud execution context, combined with implicit provider upgrades.

Key contributing factors:

1. Provider version was not pinned in the configuration

2. Terraform Cloud workers automatically used the latest compatible provider version

3. The newer provider introduced:

   • New default values for optional attributes

   • Changes in how empty vs null values were interpreted

4. Terraform state contained older representations of these attributes

Because:

• Terraform Cloud runs are stateless between executions

• Provider schemas evolved silently

• Terraform compared old state vs new provider expectations

Terraform correctly detected drift — but it was provider-induced drift, not infrastructure drift.

Solutions:

Step 1: Confirm provider version mismatch

• Compared provider version used during earlier applies via run logs

• Verified newer provider version was being selected automatically

Step 2: Pin provider versions explicitly

terraform {
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 3.80.0"
    }
  }
}

Step 3: Normalize optional attributes

• Explicitly defined attributes that were previously relying on defaults

• Replaced empty strings with null where appropriate

Example:

tags = var.tags != {} ? var.tags : null

Step 4: Refresh state safely

• Ran a terraform plan -refresh-only via Terraform Cloud

• Verified no unintended infrastructure changes

• Applied refresh to align state with actual infrastructure

Outcome

• Subsequent Terraform plans became clean and repeatable.

• No unexpected drift detected.

• Customer regained confidence in Terraform automation.

• Reduced production risk caused by silent provider behavior changes.

• Provider upgrades could now be tested safely and intentionally.