Terraform state drift, state refresh, import, taint — vocabulary for managing infrastructure state. Intermediate
0 / 15 completed
1 / 15
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 / 15
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 / 15
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 / 15
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 / 15
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
6 / 15
Reviewer: 'I noticed a change to the aws_instance resource in this PR. The security group configuration has been modified directly in the AWS console. This isn't reflected in our Terraform state. How do we address this?'
What is the most appropriate response to this code review comment?
The core issue here is drift – the infrastructure deviates from the desired state defined in your Terraform code. Immediately running `terraform apply` is the correct approach to attempt to bring the environment back into compliance with the configuration. Simply accepting the change or reverting without investigation could mask a larger problem and lead to further inconsistencies. CloudTrail logs can help determine *why* the console changes happened, allowing you to update your Terraform code to prevent future drift.
7 / 15
Team Lead (Sarah): 'Hey team, we're seeing some issues with our application deployments. The database schema keeps changing unexpectedly. It looks like the IaC for the database is out of sync. Anyone have any ideas on how to quickly bring this back in line?'
Which action would be most effective as a first step?
The primary goal is to reconcile the infrastructure with the desired state. Running `terraform plan` followed by `terraform apply` will analyze the differences between the current state and your Terraform configuration and then attempt to make the necessary changes. Manually modifying the state file is risky and can introduce further inconsistencies. CloudTrail investigation is valuable, but it's secondary to initiating a controlled reconciliation process.
8 / 15
Developer (Ben): 'This PR updates the aws_instance resource in our Terraform configuration. We've added a new tag to all instances for improved identification. The state file has been updated accordingly.'
Which of the following statements best describes Ben's approach to managing state drift?
Ben's description indicates a reactive rather than proactive approach. He's updating the state file after a change has occurred – this is *responding* to drift, not preventing it. A robust IaC strategy involves anticipating changes and ensuring infrastructure updates are consistent with the desired state. Simply documenting changes isn't sufficient to handle discrepancies effectively.
9 / 15
DevOps Engineer (Maria): 'During yesterday's stand-up, I mentioned we were experiencing some unexpected changes to the EC2 instance's security group. We hadn't explicitly updated the Terraform configuration and it appears someone made manual modifications through the AWS console. We're investigating how this happened.'
What is Maria's primary concern regarding this situation?
Maria's statement clearly indicates her focus is on understanding *why* the drift occurred (the root cause) and establishing controls to prevent it from happening again. While cost and application functionality are relevant concerns, they are secondary to addressing the underlying issue of state inconsistency. A proactive approach to preventing future drift is paramount.
10 / 15
'The team is migrating a legacy application from CloudFormation to Terraform. The existing CloudFormation stack has numerous resources that are currently running in production. What's the most important initial step before attempting to manage these resources with Terraform?'
Creating a full backup is crucial for disaster recovery and provides a safe baseline if anything goes wrong during the migration process. Cloning the existing CloudFormation stack allows you to incrementally migrate resources while minimizing disruption to the production environment. Simply running `terraform plan` on the original template without a clone would be highly complex and risky, as it doesn't account for the dependencies and relationships between the resources defined in CloudFormation.
11 / 15
Reviewer: 'I noticed a change to the aws_instance resource in this PR. The security group configuration has been modified directly in the AWS console. This isn't reflected in our Terraform state. How do we address this?'
What is the most appropriate response to this code review comment?
The core issue here is drift – the infrastructure deviates from the desired state defined in your Terraform code. Immediately running `terraform apply` is the correct approach to attempt to bring the environment back into compliance with the configuration. Simply accepting the change or reverting without investigation could mask a larger problem and lead to further inconsistencies. CloudTrail logs can help determine *why* the console changes happened, allowing you to update your Terraform code to prevent future drift.
12 / 15
Team Lead (Sarah): 'Hey team, we're seeing some issues with our application deployments. The database schema keeps changing unexpectedly. It looks like the IaC for the database is out of sync. Anyone have any ideas on how to quickly bring this back in line?'
Which action would be most effective as a first step?
The primary goal is to reconcile the infrastructure with the desired state. Running `terraform plan` followed by `terraform apply` will analyze the differences between the current state and your Terraform configuration and then attempt to make the necessary changes. Manually modifying the state file is risky and can introduce further inconsistencies. CloudTrail investigation is valuable, but it's secondary to initiating a controlled reconciliation process.
13 / 15
Developer (Ben): 'This PR updates the aws_instance resource in our Terraform configuration. We've added a new tag to all instances for improved identification. The state file has been updated accordingly.'
Which of the following statements best describes Ben's approach to managing state drift?
Ben's description indicates a reactive rather than proactive approach. He's updating the state file after a change has occurred – this is *responding* to drift, not preventing it. A robust IaC strategy involves anticipating changes and ensuring infrastructure updates are consistent with the desired state. Simply documenting changes isn't sufficient to handle discrepancies effectively.
14 / 15
DevOps Engineer (Maria): 'During yesterday's stand-up, I mentioned we were experiencing some unexpected changes to the EC2 instance's security group. We hadn't explicitly updated the Terraform configuration and it appears someone made manual modifications through the AWS console. We're investigating how this happened.'
What is Maria's primary concern regarding this situation?
Maria's statement clearly indicates her focus is on understanding *why* the drift occurred (the root cause) and establishing controls to prevent it from happening again. While cost and application functionality are relevant concerns, they are secondary to addressing the underlying issue of state inconsistency. A proactive approach to preventing future drift is paramount.
15 / 15
'The team is migrating a legacy application from CloudFormation to Terraform. The existing CloudFormation stack has numerous resources that are currently running in production. What's the most important initial step before attempting to manage these resources with Terraform?'
Creating a full backup is crucial for disaster recovery and provides a safe baseline if anything goes wrong during the migration process. Cloning the existing CloudFormation stack allows you to incrementally migrate resources while minimizing disruption to the production environment. Simply running `terraform plan` on the original template without a clone would be highly complex and risky, as it doesn't account for the dependencies and relationships between the resources defined in CloudFormation.
What will I practise in "IaC Drift & State Language Exercises"?
Practice English for Infrastructure as Code state management: Terraform state drift, refresh, taint, state mv, state locking, and migration vocabulary for DevOps and SRE engineers.
How many exercises are in this module?
This module has 15 multiple-choice exercises, each with instant feedback and a full explanation of the correct answer.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
Do I need to create an account to do these exercises?
No account is required. Just click an option to answer — your score for this session is tracked automatically in the progress bar above.
What happens if I choose the wrong answer?
You'll immediately see which answer was correct, plus a full explanation covering the vocabulary and reasoning behind it — mistakes are where most of the learning happens.
Can I retry the exercises if I want a higher score?
Yes — use the "Try again" button on the results screen to reset and go through all the questions again.
Is my progress saved if I close the page?
No. Progress is tracked only for your current visit; reloading or leaving the page resets the counter. This keeps the exercise simple and account-free.
Where can I find more Infrastructure as Code exercises?
Browse the full Infrastructure as Code hub for related drills, or check the "Next up" link below to continue with a connected topic.
How is this different from reading an article on the same topic?
Articles explain vocabulary and concepts in prose; this exercise tests and reinforces that vocabulary through active recall with immediate feedback — the two work best together.
Who writes these exercises?
Every exercise is written by the CoderSlingo team, drawing on real workplace English used in IT roles, then reviewed for accuracy and clarity.