State and real infrastructure mapping in Terraform - Mini Project: Build & Apply

State and Real Infrastructure Mapping with Terraform

📖 Scenario: You are managing cloud resources using Terraform. Terraform keeps a state file that tracks the real infrastructure it manages. This project will help you understand how Terraform maps its state to the actual cloud resources.Imagine you have a simple cloud setup with a virtual machine and a storage bucket. You will create Terraform configuration files step-by-step to define these resources, configure Terraform state, and finally apply the configuration to map the state to real infrastructure.

🎯 Goal: Build a Terraform configuration that defines a virtual machine and a storage bucket, initialize Terraform state, and apply the configuration to map the state to the real cloud infrastructure.

📋 What You'll Learn

Create a Terraform configuration file defining an AWS EC2 instance with specific attributes

Add a Terraform backend configuration to store state locally

Write the Terraform resource block for an S3 bucket

Add the final provider configuration and apply the setup

💡 Why This Matters

🌍 Real World

Terraform is widely used to manage cloud infrastructure by defining resources as code and tracking their state to ensure the real infrastructure matches the desired configuration.

💼 Career

Understanding Terraform state and resource mapping is essential for cloud engineers and DevOps professionals to automate infrastructure deployment and maintain consistency.

1

Create Terraform configuration for an AWS EC2 instance

Create a Terraform configuration file named main.tf that defines an AWS EC2 instance resource called example with the following exact attributes: ami = "ami-0c55b159cbfafe1f0" and instance_type = "t2.micro".

Terraform

# Define an AWS EC2 instance resource named example
# Your code here

Hint

Use the resource block with type aws_instance and name example. Set the ami and instance_type exactly as given.

2

Add local backend configuration for Terraform state

Add a terraform block to main.tf that configures the backend to local with the exact path "terraform.tfstate" for storing the Terraform state file.

Terraform

resource "aws_instance" "example" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"
}

# Add terraform backend configuration here
# Your code here

Hint

Use a terraform block with a backend of type local. Set the path to "terraform.tfstate".

3

Add an AWS S3 bucket resource

Add a resource block to main.tf that defines an AWS S3 bucket named example_bucket with the exact bucket name "my-terraform-bucket-12345".

Terraform

terraform {
  backend "local" {
    path = "terraform.tfstate"
  }
}

resource "aws_instance" "example" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"
}

# Add AWS S3 bucket resource here
# Your code here

Hint

Use a resource block with type aws_s3_bucket and name example_bucket. Set the bucket attribute exactly as given.

4

Add AWS provider configuration

Add a provider block for AWS to main.tf with the exact region set to "us-east-1".

Terraform

terraform {
  backend "local" {
    path = "terraform.tfstate"
  }
}

provider "aws" {
  # Set region here
  # Your code here
}

resource "aws_instance" "example" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"
}

resource "aws_s3_bucket" "example_bucket" {
  bucket = "my-terraform-bucket-12345"
}

Hint

Use a provider block for aws and set the region attribute exactly as given.

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