The Drift Problem
You define infrastructure in Terraform. You apply it. Everything matches. Then someone logs into the Azure Portal and clicks "Add rule" on an NSG. Or creates a storage account through the CLI. Or modifies a Key Vault access policy manually.
Now your Terraform state says one thing, and Azure reality says another. That's drift — and it's one of the most common sources of security misconfigurations in IaC-managed environments.
Why Drift Matters
Drift isn't just an operations problem. It's a security problem:
- An NSG rule added via Portal might open RDP from the internet — Terraform won't know
- A storage account created outside IaC won't have your standard security configuration
- A Key Vault access policy modified manually might grant broader access than intended
- A deleted resource might be re-created by Terraform on next apply — if anyone notices
The core issue: your security posture is defined by what's actually deployed, not what's in your Terraform files.
Types of Drift
Configuration Drift
A Terraform-managed resource exists, but its properties have changed. The NSG has an extra rule. The storage account has public blob access enabled. The VM has a larger SKU than specified.
Unmanaged Resources
Resources exist in Azure that aren't in any Terraform state file. Someone created them through the Portal, CLI, or another tool. They're invisible to your IaC pipeline.
Missing Resources
Resources exist in Terraform state but have been deleted from Azure. The next terraform apply will try to recreate them — which may or may not be desired.
Detecting Drift
terraform plan detects configuration drift for resources in state, but it:
- Requires running the plan against every workspace
- Doesn't find unmanaged resources
- Only runs when someone triggers it (not continuous)
- Needs credentials for every provider
A complementary approach is comparing Azure Resource Graph (what's actually deployed) against Terraform state (what should be deployed) on a schedule.
What to Do About Drift
Not all drift is bad. Sometimes a hotfix through the Portal is necessary and should be imported into Terraform state. The key is knowing about it:
- Detect — Scan for configuration drift and unmanaged resources
- Classify — Is it intentional (hotfix) or accidental (Portal click)?
- Remediate — Either import into Terraform state or revert to desired config
- Prevent — Set up alerts on drift detection, restrict Portal access where possible
Governance + IaC
Infrastructure as Code and governance platforms are complementary:
- Terraform defines what should exist and how it should be configured
- Governance verifies what actually exists and whether it meets security standards
- Drift detection bridges the gap between intent and reality
When a governance scan finds a misconfiguration, knowing whether it's Terraform-managed or unmanaged changes the remediation path. If it's in Terraform, fix the code. If it's not, import it or delete it.
Detect infrastructure drift alongside security posture. Try Unsave free at unsave.io.