State and real infrastructure mapping in Terraform - Step-by-Step Execution

Process Flow - State and real infrastructure mapping

Terraform Config Files

↓

terraform apply

↓

Terraform State File

↓

Compare State vs Real Infrastructure

↓

No Action

↓

Update State File

Terraform reads config files, applies changes, updates state file, and compares state with real infrastructure to keep them in sync.

Execution Sample

Terraform

terraform apply
# Terraform reads config
# Checks state file
# Compares with real infra
# Creates/updates resources
# Updates state file

This simulates Terraform applying infrastructure changes and updating its state file to match real resources.

Process Table

Step	Action	State File Content	Real Infrastructure	Result
1	Read config files	State file with previous resources	Existing cloud resources	Prepare plan
2	Compare state with real infra	State shows resource A exists	Resource A exists	Match - no change
3	Compare state with real infra	State shows resource B exists	Resource B missing	Diff - resource B to create
4	Create missing resource B	State updated to include resource B	Resource B created in cloud	State and infra synced
5	Finish apply	State file fully updated	Real infra matches state	Apply complete

💡 All resources in config are created or updated; state file matches real infrastructure.

Status Tracker

Variable	Start	After Step 2	After Step 4	Final
State File	{"resources": ["A", "B"]}	{"resources": ["A", "B"]}	{"resources": ["A", "B"]}	{"resources": ["A", "B"]}
Real Infrastructure	{"resources": ["A"]}	{"resources": ["A"]}	{"resources": ["A", "B"]}	{"resources": ["A", "B"]}

Key Moments - 2 Insights

Why does Terraform create resource B even though it is not in the real infrastructure?

Because the state file expects resource B to exist (see step 3 in execution_table), Terraform detects the difference and creates it to match the state.

What happens if the real infrastructure has a resource not in the state file?

Terraform will detect this as a difference and may try to remove or import it depending on configuration, ensuring state and real infra match.

Visual Quiz - 3 Questions

Look at the execution table, at which step does Terraform detect a missing resource in real infrastructure?

A Step 3

B Step 2

C Step 4

D Step 5

💡 Hint

Check the 'Result' column in execution_table rows for where 'Diff - resource B to create' appears.

According to variable_tracker, what resources exist in real infrastructure after step 4?

A ["A"]

B ["A", "B"]

C ["B"]

D []

💡 Hint

Look at the 'Real Infrastructure' row under 'After Step 4' in variable_tracker.

If resource B was already present in real infrastructure at start, how would step 3 change?

A Terraform would delete resource B

B It would still show 'Diff - resource B to create'

C It would show 'Match - no change'

D Terraform would error out

💡 Hint

Refer to step 3 in execution_table where comparison happens between state and real infra.

Concept Snapshot

Terraform uses a state file to track real infrastructure.
When you run 'terraform apply', it compares the state file with actual resources.
If differences exist, Terraform creates, updates, or deletes resources to match the state.
After changes, Terraform updates the state file to reflect reality.
This keeps your infrastructure and state in sync.

Full Transcript

Terraform manages infrastructure by keeping a state file that records what resources exist. When you run terraform apply, it reads your configuration files and compares the state file with the actual cloud resources. If it finds differences, such as missing resources, it creates or updates them. After making changes, Terraform updates the state file to match the real infrastructure. This process ensures your infrastructure matches your configuration and state file.

Practice

1. What is the main purpose of the Terraform state file?

easy

A. To keep track of real infrastructure resources Terraform manages

B. To store user credentials for cloud providers

C. To define the desired infrastructure configuration

D. To log errors during Terraform runs

Solution

1. Step 1: Understand Terraform state role

   The state file records what resources Terraform has created or manages in the real world.

2. Step 2: Differentiate state from config and logs

   The configuration defines desired setup, but state tracks actual deployed resources. Credentials and logs are separate concerns.

3. Final Answer:

   To keep track of real infrastructure resources Terraform manages -> Option A

4. Quick Check:

   State tracks real resources [OK]

Hint: State file = Terraform's memory of real resources [OK]

Common Mistakes:

• Confusing state file with configuration files
• Thinking state stores credentials
• Assuming state logs errors

2. Which Terraform command shows the current state of resources managed by Terraform?

easy

A. terraform init

B. terraform plan

C. terraform apply

D. terraform state list

Solution

1. Step 1: Identify command to inspect state

   "terraform state list" displays all resources tracked in the current state file.

2. Step 2: Differentiate from other commands

   "terraform plan" previews changes, "apply" makes changes, "init" sets up backend and providers.

3. Final Answer:

   terraform state list -> Option D

4. Quick Check:

   State inspection command = terraform state list [OK]

Hint: Use 'terraform state list' to see tracked resources [OK]

Common Mistakes:

• Using 'terraform plan' to check state directly
• Confusing 'terraform apply' with state inspection
• Thinking 'terraform init' shows state

3. Given this Terraform state snippet showing one AWS instance resource:

{
  "resources": [
    {
      "type": "aws_instance",
      "name": "web",
      "instances": [
        {"attributes": {"id": "i-1234567890abcdef0", "ami": "ami-0abc1234", "instance_type": "t2.micro"}}
      ]
    }
  ]
}

What is the instance type Terraform currently tracks for this resource?

medium

A. t2.micro

B. ami-0abc1234

C. i-1234567890abcdef0

D. aws_instance

Solution

1. Step 1: Locate instance_type attribute in state

   The attribute "instance_type" has value "t2.micro" in the resource's attributes.

2. Step 2: Understand attribute meanings

   "ami" is the image ID, "id" is the instance ID, "type" is resource type, so only "instance_type" matches the question.

3. Final Answer:

   t2.micro -> Option A

4. Quick Check:

   Instance type in state = t2.micro [OK]

Hint: Look for 'instance_type' attribute in state JSON [OK]

Common Mistakes:

• Confusing AMI ID with instance type
• Picking resource type as instance type
• Choosing instance ID instead of type

4. You ran terraform apply but your real infrastructure changed outside Terraform. What should you do to fix the state mismatch?

medium

A. Run terraform destroy to remove all resources

B. Run terraform refresh to update the state file with real resource data

C. Manually edit the state file to match real resources

D. Delete the state file and run terraform init again

Solution

1. Step 1: Understand state drift problem

   When real resources change outside Terraform, state file becomes outdated and causes mismatch.

2. Step 2: Use terraform refresh to sync state

   "terraform refresh" updates the state file to reflect current real infrastructure without changing resources.

3. Final Answer:

   Run terraform refresh to update the state file with real resource data -> Option B

4. Quick Check:

   Sync state with real infra = terraform refresh [OK]

Hint: Use 'terraform refresh' to sync state with real resources [OK]

Common Mistakes:

• Deleting state file causes loss of tracking
• Editing state file manually risks corruption
• Destroying resources is unnecessary for state fix

5. You want to share your Terraform state securely among your team using a remote backend. Which approach best ensures state consistency and safety?

hard

A. Email the state file to team members after each change

B. Store the state file on a shared network drive without locking

C. Use a remote backend like AWS S3 with state locking via DynamoDB

D. Keep the state file local on each developer's machine

Solution

1. Step 1: Identify remote backend with locking

   A remote backend like AWS S3 combined with DynamoDB locking prevents simultaneous edits and keeps state consistent.

2. Step 2: Evaluate other options for safety

   Shared drives without locking risk conflicts, emailing state causes version confusion, local files prevent collaboration.

3. Final Answer:

   Use a remote backend like AWS S3 with state locking via DynamoDB -> Option C

4. Quick Check:

   Remote backend + locking = safe shared state [OK]

Hint: Use remote backend with locking for team state safety [OK]

Common Mistakes:

• Ignoring state locking leads to conflicts
• Sharing state by email causes outdated copies
• Local state prevents team collaboration