DEV Community

Cover image for ✅ Task — 3: Use Variables, Locals, and Outputs for a Simple EC2 Instance Setup
Latchu@DevOps
Latchu@DevOps

Posted on

✅ Task — 3: Use Variables, Locals, and Outputs for a Simple EC2 Instance Setup

#terraform #aws #devops #infrastructureascode

🎯 Goal

Create a simple EC2 instance using:

  • Variables → for AMI, instance_type, tags
  • Locals → for naming
  • Outputs → instance_id, public_ip
  • Remote backend → S3
  • State locking → DynamoDB

Using your backend resources:

  • S3 bucket: tf-backend-lab-123
  • DynamoDB table: tf-state-lock

📁 Folder Structure

We keep it clean for this task:

terraform-ec2-basic/
├── backend.tf
├── main.tf
├── variables.tf
├── outputs.tf
├── terraform.tfvars
Enter fullscreen mode Exit fullscreen mode

1

🧩 backend.tf

terraform {
  backend "s3" {
    bucket       = "tf-backend-lab-123"
    key          = "ec2/basic/terraform.tfstate"
    region       = "us-east-1"
    encrypt      = true
    dynamodb_table = "tf-state-lock"
  }
}
Enter fullscreen mode Exit fullscreen mode

📌 variables.tf

We define input variables:

variable "instance_type" {
  description = "EC2 instance type"
  type        = string
  default     = "t3.micro"
}

variable "ami_id" {
  description = "AMI ID for EC2 instance"
  type        = string
}

variable "env" {
  description = "Environment name"
  type        = string
  default     = "dev"
}

variable "owner" {
  description = "Owner/Team name"
  type        = string
}
Enter fullscreen mode Exit fullscreen mode

🧠 locals

Locals are used to build consistent resource names.

Add this inside main.tf or create locals.tf

locals {
  name_prefix = "${var.env}-${var.owner}"
  common_tags = {
    Environment = var.env
    Owner       = var.owner
    ManagedBy   = "Terraform"
  }
}
Enter fullscreen mode Exit fullscreen mode

Interview Tip:

Locals help avoid repeating variables and maintain consistent naming conventions.

📌 main.tf

provider "aws" {
  region = "us-east-1"
}

resource "aws_instance" "server" {
  ami           = var.ami_id
  instance_type = var.instance_type

  tags = merge(
    local.common_tags,
    {
      Name = "${local.name_prefix}-ec2"
    }
  )
}
Enter fullscreen mode Exit fullscreen mode

📤 outputs.tf

output "instance_id" {
  value       = aws_instance.server.id
  description = "EC2 Instance ID"
}

output "public_ip" {
  value       = aws_instance.server.public_ip
  description = "Public IP address of the EC2 instance"
}

output "tags_used" {
  value = local.common_tags
}
Enter fullscreen mode Exit fullscreen mode

📌 terraform.tfvars

Provide your values:

ami_id = "ami-0c02fb55956c7d316"   # Amazon Linux 2 in us-east-1
owner  = "lachu"
env    = "dev"
instance_type = "t3.micro"
Enter fullscreen mode Exit fullscreen mode

▶️ Commands 

terraform init
terraform validate
terraform plan
terraform apply -auto-approve
Enter fullscreen mode Exit fullscreen mode

1

If you can check with dynamoDB table

2

🧠 Interview Notes (Very Important)

✔ Why use variables?

  • Reusability
  • Runtime flexibility
  • Parameterizing environment-specific values

✔ Why use locals?

  • Avoid repeating variable values
  • Standardize naming conventions
  • Reduce mistakes in big projects

✔ Why use outputs?

  • To expose useful information after apply
  • Helpful for automation (CI/CD, scripts)
  • Used by other Terraform modules

✔ Why S3 + DynamoDB?

  • S3 → stores remote state
  • DynamoDB → prevents two people from running apply at the same time

✔ Typical interview question:

How does Terraform handle state locking?

Answer:

When using S3 backend with DynamoDB, Terraform creates a lock entry in DynamoDB during operations such as plan or apply. This prevents concurrent modifications of the state, ensuring consistency.

🌟 Thanks for reading! If this post added value, a like ❤️, follow, or share would encourage me to keep creating more content.

— Latchu | Senior DevOps & Cloud Engineer

☁️ AWS | GCP | ☸️ Kubernetes | 🔐 Security | ⚡ Automation
📌 Sharing hands-on guides, best practices & real-world cloud solutions

Top comments (0)