IaC Drift & State Language Exercises

1 / 5

An SRE says: "We have state drift — the production load balancer was modified manually in the AWS Console."

What will happen on the next terraform apply?

State drift = divergence between the .tf configuration (desired state) and the real infrastructure's current state. The reconciliation flow:

terraform refresh — queries AWS API, updates the state file with current real-world attributes
terraform plan — compares refreshed state against configuration, shows diffs
terraform apply — reverts the manually applied changes to match the configuration

Term	Meaning
drift detection	Identifying when real infrastructure diverges from its declared configuration
configuration drift	Accumulated out-of-band changes that cause infrastructure to deviate from the intended state
reconciliation	The process of bringing real infrastructure back in line with declared configuration
infrastructure immutability	Principle that infrastructure should only be changed via code, never manually

2 / 5

A team member says: "We need to terraform taint the EC2 instance to force its replacement."

What does tainting a resource do in Terraform?

terraform taint was the original command; it is deprecated in Terraform 1.x and replaced by the -replace flag.

Old syntax	New syntax (TF 1.x)
`terraform taint aws_instance.web`	`terraform apply -replace="aws_instance.web"`

When to force replacement: instance is corrupted, a secret needs rotation via reprovisioning, or a configuration management tool requires a fresh host
Forced replacement = destroy + create in a single apply (or create-before-destroy if configured)
reprovisioning — recreating a resource to apply a clean configuration from scratch

3 / 5

You are refactoring your .tf files and rename a resource block from resource "aws_instance" "old_name" to resource "aws_instance" "new_name".

When should you use terraform state mv as part of this refactor?

Without terraform state mv, Terraform interprets a resource block rename as: delete aws_instance.old_name + create aws_instance.new_name — destroying your running instance. terraform state mv aws_instance.old_name aws_instance.new_name updates the state tracking to avoid this.

Operation	What it does	Use case
`terraform state mv`	Renames resource address in state	Refactoring .tf resource names or extracting into modules
`terraform state rm`	Removes resource from state tracking	Stop managing a resource without destroying it
`terraform state show`	Displays state attributes for a resource	Inspecting current recorded state for debugging

This type of manual state manipulation is sometimes called "state surgery". After state mv, run terraform plan to confirm a zero-diff result.

4 / 5

Remote state is configured with an S3 backend and a DynamoDB lock table. What does state locking prevent?

State locking is a distributed lock mechanism: when plan or apply starts, Terraform acquires the lock. A second concurrent apply cannot proceed until the first releases it.

Component	Role
S3 bucket	Stores the `.tfstate` file with versioning enabled
DynamoDB table	Holds the lock record with a `LockID` attribute (conditional write = atomic lock acquisition)
lock acquisition timeout	How long Terraform waits to acquire the lock before failing — configurable via `-lock-timeout`

State corruption — what happens without locking when two applies write conflicting state simultaneously
Stale lock — a lock that was not released after a process crash; cleared with terraform force-unlock <lock-id>

5 / 5

A team is converting a CloudFormation stack to Terraform. The existing AWS resources were all created by CloudFormation and are currently live in production.

What is the recommended approach for bringing these resources under Terraform management?

The recommended zero-downtime migration workflow for each resource:

Write the resource block in .tf
Run terraform import <resource_address> <cloud_resource_id>
Run terraform plan — chase a zero-diff result by adjusting the .tf block to match recorded state
Once all resources are imported, delete the CloudFormation stack (with DeletionPolicy: Retain on all resources to prevent destruction)

Term	Meaning
incremental migration	Moving resources one at a time rather than a big-bang cutover
zero-downtime migration	Migrating management tooling without destroying or recreating live resources
state import workflow	The full import → plan → reconcile cycle