❓ What is IaC (Infrastructure as Code)?

Infrastructure as Code (IaC) is the practice of managing and provisioning IT infrastructure using code, instead of manual processes or interactive configuration tools.

With IaC, you define your infrastructure (servers, databases, networks, etc.) in machine-readable configuration files. This allows you to:

🔧 Automate setup and configuration
🔁 Repeat the same deployment consistently
🛠️ Version control infrastructure using Git
⚙️ Reduce errors caused by manual steps
🚀 Scale easily across environments (dev, staging, prod)

---

🔍 Example Tools that Use IaC:

• Terraform (multi-platform, cloud-agnostic) - (Provisioning Tool)

• AWS CloudFormation (for AWS only)

• Ansible, Chef, Puppet (focus on configuration management)

---

🌐 Introduction to Terraform

Terraform is a powerful, open-source Infrastructure as Code (IaC) tool developed by HashiCorp. It allows you to provision, manage, and destroy infrastructure across a wide range of environments—whether on public clouds like AWS, Azure, and GCP, or private/on-premises platforms such as vSphere.

Terraform uses a declarative language called HCL (HashiCorp Configuration Language), where you define the desired state of your infrastructure in simple configuration files (with .tf extension). Terraform then automatically figures out the steps needed to reach that state from the current one—handling all the provisioning logic for you.

It works in three key phases:

1. terraform init – Initializes the project and configures providers (API connectors for each platform).

2. terraform plan – Generates a detailed execution plan showing what changes will be made.

3. terraform apply – Applies the necessary changes to reach the desired infrastructure state.

Terraform is resource-based, meaning it manages everything (VMs, databases, networks, etc.) as individual resources, taking care of their entire lifecycle—from creation and configuration to decommissioning.

What is resource?

Resource is a object that Terraform manages. It could be a file on the local host or a virtual machine, services like s3 bucket, IAM users

---

HashiCorp Configuration Langauage (HCL)

Syntax:

<block> <params> {
    key1 = value1
    key2 = value2
}

Examples:

Provisioning an AWS EC2 instance

For creating an AWS S3 bucket

Workflows

1. Write the configuration file

2. Run terraform init command

3. terraform plan for review the execution plan

4. terraform apply to apply the changes

terraform show to show the resource we have created

Update and destroy resources in Terraform

terraform destroy to delete the infrastructure completly.

• When we don’t want to produce output by the terraform plan and terraform apply commands printed on the screen.

resource "local_sensitive_file" "games" {
  filename     = "/root/favorite-games"
  content  = "FIFA 21"
}

---

🧩 Terraform Providers and the terraform init Command

When you run the terraform init command inside a directory that contains your Terraform configuration files, Terraform performs several important tasks:

🔧 What terraform init Does:

🛠️ Plugin-Based Architecture

Terraform is built with a plugin-based architecture, meaning it can integrate with hundreds of infrastructure platforms by using external plugins (providers). This makes it highly modular and extensible.

---

🌐 Terraform Registry

All major Terraform providers are:

• Published and maintained by HashiCorp, partners, or the community

• Available at:
  🔗 https://registry.terraform.io

📊 Three Tiers of Terraform Providers

When we run terraform init it shows the version of the plugin that is being installed.

---

Configuration Directory

we can create configuration as many as we want in a single configuration ddirectory.

The common practive is to have one single configuration file with all the resource blocks required to provision the infrastructure. A single configuration file can have as many number of configuration clocks that we need.

Common naming convention used for such configuration file is to call it the main.tf.

Other configuration file can be created within the directory are variables.tf, outputs.tf, provider.tf.

---

Multiple providers

Terraform supports the use of multiple providers within the same configuration. to ilustrate this let’s use of another provider called random. This provider allows us to create random resources, such as random ID, a random integer, a random password, etc. Let us create a resources called random pet. This resource type will generate a random pet when applied.

resource "local_file" "pet" {
    filename = "/root/pets.txt"
    content = "We love pets!"
}

resource "random_pet" "my-pet" {
    prefix = "Mrs"
    separator = "."
    length = "1"
}

Here, for random resource we have used three arguments

🔍 What terraform init Will Do:

🛠️ Terminal Output Example (Expected):

Initializing the backend...

Initializing provider plugins...
- Reusing previous version of hashicorp/local from the dependency lock file
- Finding latest version of hashicorp/random...
- Installing hashicorp/random v3.5.1...
- Installed hashicorp/random v3.5.1 (signed by HashiCorp)

Terraform has been successfully initialized!

---

Input variables

resource "local_file" "pet" {
    filename = "/root/pets.txt"
    content = "We love pets!"
}

resource "random_pet" "my-pet" {
    prefix = "Mrs"
    separator = "."
    length = "1"
}

This way of configuration file are hard-coded and not reusable, which resist the rule of using IAC. To improve our technique, we can use another file for varible like variables.tf, from which our configuation file will collect the defined variables.

Variable Blocks

Variable block in Terraform accepts three parameters.

1. defaults (Optional)

2. type (optional)

3. description (optional)

type arguments are optional, but when used, it enforces the type of variable being used. If it is not specified in the varibale block, it is set to the type Any by default.

Other types of variable types rather string, number, bool

List → Can have duplicate variables

Map

Set → Similar to a List but can’t have duplicates values

Objects → Combinned of all (Complex data structure)

Tuples → Similar to List but here we can use elements of different variable types

Using variables in Terraform (Multiple ways)

1. When default parameter in variable block are empty.

It will allows user to enter each variable in interactive mode.

2. Command line flags (-var “variable_name” = “value”)

3. Using environment variables with TF_VAR_<name_of_the_declared_variable>="value"

4. Variable definition file (When need to use lots of variables) - Custom variable

Variable Definition Precedence

When we use multiple ways to take value it take value by maintaining some rule

Resource Attributes Reference

We will learn how to link to resources by making use of resource attributes.

Initial State

After making resource attributes (referencing) - reference expression

Resource Dependencies

Here we are explicitly mentioning the local_file resource is depends on random_pet resource. And, so random_pet resource will first created, and during deletion, it will deleted at the last. Here, we are not declaring what resource should created first, but Terraform will do that for us.

Here, we are using depends_on to create explicit dependency.

Output Variables

Here, in output block, mandatory argument for value is the reference expression.

terraform apply can be used to see the output in the terminal. Once the resource has been created we can run terraform output command to print the value of the output variables. This command will print all the output variabels defined in the current configuration directory. we can also use the output command to specificlly print the value of an existing output variable like below:

📄 Terraform State (terraform.tfstate)

🔹 What is Terraform State?

Terraform uses a state file (terraform.tfstate) to track the current state of the infrastructure it manages. The content of this file is in json format.

Terraform uses state file to map the resource configuration to the real world infrastructure.

---

🧠 Why is it important?

• Keeps a record of all deployed resources

• Helps Terraform determine what needs to be added, changed, or destroyed

• Enables incremental changes without affecting existing infrastructure

---

📌 Key Points:

📄 Purpose of Terraform State

Terraform needs to keep track of what it has created so it can manage your infrastructure correctly. That’s why it uses a state file called terraform.tfstate.

---

✅ Why is Terraform State Important?

1. Records What Exists
   The state file stores details about all resources Terraform manages — like IDs, IP addresses, and names. This helps Terraform remember what it deployed.

2. Detects Changes
   When you run terraform plan, Terraform compares the current state (in terraform.tfstate) with your configuration code to figure out what has changed.

3. Prevents Re-Creation
   Without state, Terraform wouldn’t know what resources already exist — and would try to recreate everything each time.

4. Supports Collaboration
   When using remote state (e.g., AWS S3), teams can safely share and work on infrastructure without conflicts.

5. Stores Metadata
   It keeps track of dependencies and links between resources to apply changes in the correct order.

📌 Terraform State Considerations

Managing Terraform state properly is crucial for safe and predictable infrastructure changes. Here are key considerations:

---

1. 🧠 State File Is Critical

• The terraform.tfstate file contains the full record of Terraform-managed infrastructure.

• If it's lost or corrupted, Terraform cannot track or manage your resources properly.

---

2. 🔐 Sensitive Information

• State files may contain sensitive data like passwords, API keys, or IP addresses.

• Always encrypt state files and restrict access (especially in teams).

---

3. ☁️ Use Remote State for Teams

• For team environments, use remote backends (e.g., AWS S3, Azure Blob, GCS) to:

  • Centralize the state file

  • Prevent accidental overwrites

  • Enable locking (e.g., DynamoDB for AWS)

---

4. ♻️ Do Not Manually Edit

• Avoid editing the state file directly unless absolutely necessary (and with backups).

• Instead, use commands like terraform state mv, rm, or import.

---

5. 🔒 Use State Locking

• Prevents multiple users or pipelines from modifying the same state file at once.

• Most remote backends (e.g., S3 + DynamoDB) support state locking.

---

6. 📁 Store in Version Control?

• ❌ Do NOT commit terraform.tfstate or .terraform/ directories to version control.

• ✅ You can track .tfstate.backup or version-controlled *.tf files — but never the actual state file itself in Git.

---

7. 📤 State Can Be Split

• For large projects, you can split infrastructure into multiple state files (using workspaces or modules) to improve manageability.

---

Terraform Commands

After making the configuration file:

terraform validate to check syntax in configuration file used is correct. And the error (if exist) with hint to fix it.

terraform fmt scans the configuration files in current working directory and formats the code into a canonical format.

terraform show prints out the current state of the infrastructure as seen by terraform.

terraform show -json prints the content in json format.

terraform providers list of all providers used in configuration directory.

terraform providers mirror /root/terraform/new_local_file to copy provider plugins needed for the current configuration to another directory.

terraform output to print all the output in the configuration directory.

terraform output <pet-name> output of a specific variable.

terraform apply -refresh-only used to sync terraform with the real-world infrastructure. For example, if there are any changes made to a resource created by terraform outside its control such as manual update, the terraform refresh command will pick it up and update the state file. The reconcilation is useful to determine what action to take during the next apply. This command will not modify any infrastructure resource but it will modify the state file.

terraform graph used to create a visual representation of the dependencies in a terraform configuration or an execution plan. The graph generated in a format called dot.

🆚 Mutable vs Immutable Infrastructure in IaC

---

📘 Example

🔧 Mutable:

You update an EC2 instance in place:

resource "aws_instance" "web" {
  ami           = "ami-123"
  instance_type = "t2.micro"
  user_data     = "apt update && apt install nginx"
}

Later, you just change the user_data script and run terraform apply. The instance stays the same, but its config changes — mutable behavior.

---

🧱 Immutable:

You change the AMI to a new, pre-configured one:

resource "aws_instance" "web" {
  ami           = "ami-456" # new AMI with pre-installed nginx
  instance_type = "t2.micro"
}

Terraform will destroy the old instance and create a new one — immutable behavior.

---

✅ What Does Terraform Use?

Terraform supports both, but it naturally leans toward immutable infrastructure.

🧠 Why? Because:

• Resources are declared declaratively

• Changing a property often leads to recreating the resource (e.g., changing AMI, volume size)

• This ensures a clean, predictable state

🔁 Terraform Lifecycle Rules

In Terraform, the lifecycle block inside a resource lets you customize how Terraform manages resource creation, update, and deletion. This helps handle complex infrastructure scenarios more safely and predictably.

---

🎯 Purpose:

To control the behavior of Terraform when a resource is:

• Re-created

• Changed

• Deleted

---

🔑 Three Primary Lifecycle Meta-Arguments

---

📘 Examples

1️⃣ create_before_destroy

resource "aws_instance" "example" {
  ami           = "ami-123"
  instance_type = "t2.micro"

  lifecycle {
    create_before_destroy = true
  }
}

✅ Ensures a new EC2 instance is created before destroying the old one — useful for zero-downtime deployments.

---

2️⃣ prevent_destroy

resource "aws_s3_bucket" "important" {
  bucket = "my-critical-logs"

  lifecycle {
    prevent_destroy = true
  }
}

✅ Prevents accidental deletion of important S3 buckets — Terraform will error out if a destroy is attempted.

---

3️⃣ ignore_changes

resource "aws_instance" "web" {
  ami           = "ami-abc"
  instance_type = "t2.micro"

  lifecycle {
    ignore_changes = [ami]
  }
}

✅ If someone changes the AMI manually in the cloud, Terraform won’t try to revert it during future applies.

📘 Terraform Data Sources

🔍 What is a Data Source?

A data source in Terraform allows you to fetch information from external sources or existing infrastructure without creating or modifying them.

✅ Think of data sources as read-only lookups.

---

🧠 Why Use Data Sources?

• To reference existing infrastructure (e.g., an existing AWS AMI, VPC, or S3 bucket).

• To fetch dynamic values that are managed outside of Terraform.

• To use outputs from one module in another without duplication.

---

📦 Example:

data "aws_ami" "ubuntu" {
  most_recent = true
  owners      = ["099720109477"] # Canonical

  filter {
    name   = "name"
    values = ["ubuntu/images/hvm-ssd/ubuntu-focal-20.04-amd64-server-*"]
  }
}

resource "aws_instance" "web" {
  ami           = data.aws_ami.ubuntu.id
  instance_type = "t2.micro"
}

🧾 Here, we use a data source to get the latest Ubuntu AMI, and then use that AMI to launch an EC2 instance.

---

🔁 Resource vs Data Source: Key Differences

🔢 What is count in Terraform?

The count meta-argument in Terraform allows you to create multiple instances of a resource using a single configuration block.

It’s like a loop that helps with scaling resources easily.

---

✅ 1. Using count with a fixed number

🔧 main.tf

resource "local_file" "notes" {
  count    = 3
  filename = "file_${count.index}.txt"
  content  = "This is file number ${count.index}"
}

This creates 3 files:

• file_0.txt

• file_1.txt

• file_2.txt

---

✅ 2. Using count with a variable

We’ll now control the number of resources using an input variable.

---

📁 File: variables.tf

variable "file_count" {
  description = "How many files to create"
  type        = number
  default     = 2
}

---

📁 File: main.tf

resource "local_file" "notes" {
  count    = var.file_count
  filename = "note_${count.index}.txt"
  content  = "This is note ${count.index}"
}

When you change the file_count value (e.g., via terraform.tfvars or CLI), it changes how many files get created.

---

✅ 3. Using count = length(var.list)

When you have a list of values, you can dynamically control the count using length().

---

📁 File: variables.tf

variable "file_names" {
  description = "List of filenames"
  type        = list(string)
  default     = ["math", "science", "history"]
}

---

📁 File: main.tf

resource "local_file" "subjects" {
  count    = length(var.file_names)
  filename = "${var.file_names[count.index]}.txt"
  content  = "This file is about ${var.file_names[count.index]}"
}

Terraform creates:

• math.txt

• science.txt

• history.txt

🔁 Terraform for_each Meta-Argument

🔍 What is for_each?

for_each is a Terraform meta-argument used to create multiple instances of a resource or module by looping over a set or map.

Unlike count, for_each gives you more control and clarity, especially with named items.

---

✅ Use Case 1: Using for_each with a set (directly from variables.tf)

---

📁 variables.tf

variable "file_names" {
  description = "Set of file names"
  type        = set(string)
  default     = ["alpha", "beta", "gamma"]
}

---

📁 main.tf

resource "local_file" "my_files" {
  for_each = var.file_names
  filename = "${each.key}.txt"
  content  = "This is file named ${each.key}"
}

✅ Result:

Terraform will create:

• alpha.txt

• beta.txt

• gamma.txt

---

✅ Use Case 2: Using for_each with a list, but convert it to a set

for_each cannot be used directly with a list — it must be a set or map. So we convert the list to a set using toset().

---

📁 variables.tf

variable "topics_list" {
  description = "List of topics"
  type        = list(string)
  default     = ["devops", "cloud", "terraform"]
}

---

📁 main.tf

resource "local_file" "topic_files" {
  for_each = toset(var.topics_list)
  filename = "${each.key}.md"
  content  = "This topic is about ${each.key}"
}

✅ Result:

Terraform will create:

• devops.md

• cloud.md

• terraform.md

---

🧠 Summary: for_each vs count

📌 Terraform Version Constraints

🔍 What Are Version Constraints?

Version constraints in Terraform allow you to control which version of a provider (like hashicorp/local) Terraform installs. This avoids breaking changes from new major versions and ensures your infrastructure stays stable.

---

✅ Without Version Constraint

📁 main.tf

resource "local_file" "pet" {
  filename = "/root/pet.txt"
  content  = "We love pets!"
}

📦 When you run:

$ terraform init

You’ll see:

The following providers do not have any version constraints in configuration, so the latest version was installed.
To prevent automatic upgrades to new major versions, we recommend adding version constraints.

✅ Best Practice: Always define a version constraint to ensure consistent behavior.

---

✅ Adding Version Constraints

📁 main.tf

terraform {
  required_providers {
    local = {
      source  = "hashicorp/local"
      version = "1.4.0"
    }
  }
}

resource "local_file" "pet" {
  filename = "/root/pet.txt"
  content  = "We love pets!"
}

📦 Output after terraform init:

Installing hashicorp/local v1.4.0...
Terraform has been successfully initialized!

---

🎯 Different Version Constraints

---

✅ Example: Using ~> (Pessimistic Constraint)

📁 main.tf

terraform {
  required_providers {
    local = {
      source  = "hashicorp/local"
      version = "~> 1.2.0"
    }
  }
}

resource "local_file" "pet" {
  filename = "/root/pet.txt"
  content  = "We love pets!"
}

📦 Output after terraform init:

Installing hashicorp/local v1.2.2...
Terraform has been successfully initialized!

ℹ️ Installed version is within the allowed patch range (>= 1.2.0 and < 1.3.0).

---

📘 Getting Started with AWS

🔥 Why AWS?

AWS (Amazon Web Services) is a leader in cloud infrastructure services, recognized by Gartner for over 10 years.

📌 Source: AWS Named a Cloud Leader - Gartner MQ

✅ AWS Core Services:

🌍 AWS Global Infrastructure (Popular Regions):

• US: Ohio, Oregon, N. California, GovCloud (West/East)

• Europe: London, Frankfurt, Ireland, Paris, Milan

• Asia Pacific: Mumbai, Tokyo, Hong Kong, Sydney

• Others: São Paulo, Beijing, Canada (Central)

---

🛠️ AWS with Terraform

Terraform allows Infrastructure as Code (IaC), letting you automate AWS resources like:

---

👤 AWS IAM (Identity and Access Management)

Concepts:

• Root User: Default AWS admin (avoid daily use)

• IAM Users: Individual accounts for people/applications

• IAM Groups: Group permissions (e.g., Developer Group)

• Policies: JSON-based permissions (e.g., AdministratorAccess, AmazonEC2FullAccess)

IAM Policy Example:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "*",
      "Resource": "*"
    }
  ]
}

🧩 Policy Name Examples:

• AdministratorAccess

• Billing

• AmazonS3FullAccess

• AmazonEC2FullAccess

---

🔐 Programmatic Access

How to Configure AWS CLI:

$ aws configure
AWS Access Key ID: <YOUR_ACCESS_KEY>
AWS Secret Access Key: <YOUR_SECRET_KEY>
Default region name: us-west-2
Default output format: json

Config files:

~/.aws/config
~/.aws/credentials

Useful CLI Commands:

aws iam create-user --user-name lucy
aws s3api create-bucket --bucket my-bucket --region us-east-1
aws ec2 describe-instances

👉 CLI Reference: https://docs.aws.amazon.com/cli/latest/reference

---

📦 Installing AWS CLI

Linux/Mac:

$ curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
$ unzip awscliv2.zip
$ sudo ./aws/install
$ aws --version

Windows:

Download from: https://awscli.amazonaws.com/AWSCLIV2.msi

---

🌐 Creating IAM Users on AWS with Terraform

---

🔰 Introduction

IAM (Identity and Access Management) in AWS allows you to manage access to AWS services and resources securely. With Terraform, you can automate IAM user creation, assign policies, and tag users consistently across environments.

---

🧱 Terraform Block Structure

resource "aws_iam_user" "admin-user" {
  name = "lucy"
  tags = {
    Description = "Technical Team Leader"
  }
}

---

✅ Full main.tf Example with Provider

provider "aws" {
  region     = "us-west-2"
}

resource "aws_iam_user" "admin-user" {
  name = "lucy"
  tags = {
    Description = "Technical Team Leader"
  }
}

---

🔑 Providing AWS Credentials (3 Methods)

1. Inline in provider block (Not recommended for production):

provider "aws" {
  region     = "us-west-2"
  access_key = "AKIAI44QH8DHBEXAMPLE"
  secret_key = "je7MtGbClwBF/2tk/h3yCo8nvbEXAMPLEKEY"
}

2. Using environment variables (Recommended):

$ export AWS_ACCESS_KEY_ID=AKIAI44QH8DHBEXAMPLE
$ export AWS_SECRET_ACCESS_KEY=je7MtGbClwBF/2tk/h3yCo8nvbEXAMPLEKEY
$ export AWS_REGION=us-west-2

3. Using ~/.aws/credentials and ~/.aws/config:

# ~/.aws/credentials
[default]
aws_access_key_id = AKIAI44QH8DHBEXAMPLE
aws_secret_access_key = je7MtGbClwBF/2tk/h3yCo8nvbEXAMPLEKEY

# ~/.aws/config
[default]
region = us-west-2
output = json

---

⚙️ Terraform Commands

1. Initialize the configuration

    terraform init
   

2. Review the execution plan

    terraform plan
   

3. Apply the configuration

    terraform apply
   

---

💡 Example Output After apply

aws_iam_user.admin-user: Creating...
aws_iam_user.admin-user: Creation complete after 1s [id=lucy]

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

---

🔐 Creating IAM Policies with Terraform

---

✅ Objective

In this guide, you’ll learn how to:

• Create an IAM user (lucy)

• Define a custom IAM policy (AdminUsers)

• Attach the policy to the user using aws_iam_user_policy_attachment

• Use Heredoc syntax (<<EOF) to define inline JSON policy

---

🧱 Complete main.tf Example

hclCopyEditprovider "aws" {
  region = "us-west-2"
}

# 1. Create an IAM User
resource "aws_iam_user" "admin-user" {
  name = "lucy"
  tags = {
    Description = "Technical Team Leader"
  }
}

# 2. Define an IAM Policy using Heredoc Syntax
resource "aws_iam_policy" "adminUser" {
  name = "AdminUsers"
  policy = <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "*",
      "Resource": "*"
    }
  ]
}
EOF
}

# 3. Attach the Policy to the User
resource "aws_iam_user_policy_attachment" "lucy-admin-access" {
  user       = aws_iam_user.admin-user.name
  policy_arn = aws_iam_policy.adminUser.arn
}

---

📜 Policy Explained

This policy grants Administrator Access by:

• Allowing all actions ("Action": "*")

• On all resources ("Resource": "*")

• Which is equivalent to the AdministratorAccess managed policy.

---

🔧 Terraform Commands

1. Initialize Terraform

terraform init

2. Preview the Plan

terraform plan

3. Apply the Configuration

terraform apply

---

✅ Sample Output (Simplified)

Apply complete! Resources: 3 added, 0 changed, 0 destroyed.

aws_iam_user.admin-user: Created [id=lucy]
aws_iam_policy.adminUser: Created [id=arn:aws:iam::123456789012:policy/AdminUsers]
aws_iam_user_policy_attachment.lucy-admin-access: Created [id=lucy-xyz123]

---

📁 Option: External Policy File

If you have a policy JSON file like admin-policy.json:

Contents:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "*",
      "Resource": "*"
    }
  ]
}

Updated Terraform:

resource "aws_iam_policy" "adminUser" {
  name   = "AdminUsers"
  policy = file("admin-policy.json")
}

---

🧠 Pro Tip: Use Version Constraints

Add a version block to prevent provider upgrades that might break your setup:

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 3.6.0"
    }
  }
}

---

🪣 Getting Started with AWS S3 (Simple Storage Service)

---

📌 What is Amazon S3?

Amazon S3 (Simple Storage Service) is a scalable object storage service used to store and retrieve any amount of data at any time from anywhere on the web.

---

📂 S3 Storage Structure

S3 organizes data in a flat structure using:

---

📝 Example Bucket: all-pets (us-west-1)

---

🔐 Permissions and Access Control

There are two major ways to control access:

1. ACL (Access Control List)

• Assigned to individual objects

• Example: dog.jpg → Only Lucy can read

2. Bucket Policy

JSON-based permission rules at the bucket level.

Example: read-objects.json – allow Lucy to GetObject from bucket:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject"
      ],
      "Resource": "arn:aws:s3:::all-pets/*",
      "Principal": {
        "AWS": [
          "arn:aws:iam::123456123457:user/Lucy"
        ]
      }
    }
  ]
}

---

🧠 Important Notes

---

🧾 Creating and Managing AWS S3 Buckets with Terraform

---

🪣 1. Create an S3 Bucket

To provision an S3 bucket using Terraform:

resource "aws_s3_bucket" "finance" {
  bucket = "finanace-21092020"  # Must be globally unique
  tags = {
    Description = "Finance and Payroll"
  }
}

✅ After running terraform apply, the output:

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.
Bucket ID: finanace-21092020

---

📄 2. Upload a File to the Bucket

To upload a document (e.g. finance-2020.doc) to the S3 bucket:

resource "aws_s3_bucket_object" "finance-2020" {
  bucket  = aws_s3_bucket.finance.id
  key     = "finance-2020.doc"
  content = file("/root/finance/finance-2020.doc")
}

💡 The key represents the object's name (like a file path), and content is loaded from your local filesystem.

---

👥 3. Attach IAM Group & Define Permissions

IAM Group (Data Source)

data "aws_iam_group" "finance-data" {
  group_name = "finance-analysts"
}

---

🔐 4. Set Bucket Policy to Allow Group Access

Create Bucket Policy with <<EOF Heredoc syntax:

resource "aws_s3_bucket_policy" "finance-policy" {
  bucket = aws_s3_bucket.finance.id
  policy = <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "*",
      "Resource": "arn:aws:s3:::${aws_s3_bucket.finance.id}/*",
      "Principal": {
        "AWS": [
          "${data.aws_iam_group.finance-data.arn}"
        ]
      }
    }
  ]
}
EOF
}

🧠 Tip: <<EOF is heredoc syntax to write multiline JSON inside HCL.

---

🧪 5. Apply Everything

Run:

terraform apply

You will see Terraform output showing resources like:

• aws_s3_bucket.finance

• aws_s3_bucket_object.finance-2020

• aws_s3_bucket_policy.finance-policy

✅ All created successfully!

---

🧾 Introduction to Amazon DynamoDB

---

🔹 What is DynamoDB?

Amazon DynamoDB is a:

• 🔸 Fully managed, serverless, NoSQL database service by AWS.

• 🔸 Designed for high performance with single-digit millisecond latency.

• 🔸 Provides horizontal scaling and multi-region replication out-of-the-box.

---

✅ Key Features

---

🗂 Sample Table: cars

Let's consider a DynamoDB table storing car inventory:

📌 Sample Items

{
  "Manufacturer": "Toyota",
  "Make": "Corolla",
  "Year": 2004,
  "VIN": "4Y1SL65848Z411439"
}

{
  "Manufacturer": "Honda",
  "Make": "Civic",
  "Year": 2017,
  "VIN": "DY1SL65848Z411432"
}

{
  "Manufacturer": "Dodge",
  "Make": "Journey",
  "Year": 2014,
  "VIN": "SD1SL65848Z411443"
}

{
  "Manufacturer": "Ford",
  "Make": "F150",
  "Year": 2020,
  "VIN": "DH1SL65848Z41100"
}

---

🔑 DynamoDB Table Design

⚠️ Note: DynamoDB requires a Primary Key, which can be:

• A Partition Key (e.g., Manufacturer), or

• A combination of Partition Key + Sort Key (e.g., Manufacturer + Model)

---

🌐 Use Cases

• Real-time inventory tracking (e.g., car dealers)

• Session state storage

• IoT device data logging

• Leaderboards and user profiles for games

• Event logging and analytics

---

🔐 Example Access Pattern

Want to find all cars by Honda:

aws dynamodb query \
  --table-name cars \
  --key-condition-expression "Manufacturer = :m" \
  --expression-attribute-values '{":m":{"S":"Honda"}}'

---

🛠️ DynamoDB with Terraform

---

✅ Step 1: Create a DynamoDB Table

To create a table named cars with a primary key (VIN) using Terraform:

resource "aws_dynamodb_table" "cars" {
  name         = "cars"
  hash_key     = "VIN"
  billing_mode = "PAY_PER_REQUEST"  # On-demand pricing

  attribute {
    name = "VIN"
    type = "S"  # "S" = String
  }
}

📌 PAY_PER_REQUEST means you're charged per read/write — no need to define capacity units.

---

✅ Step 2: Add an Item to the Table

Use aws_dynamodb_table_item to insert a car record:

resource "aws_dynamodb_table_item" "car_items" {
  table_name = aws_dynamodb_table.cars.name
  hash_key   = aws_dynamodb_table.cars.hash_key

  item = <<EOF
{
  "Manufacturer": {"S": "Toyota"},
  "Model": {"S": "Corolla"},
  "Year": {"N": "2004"},
  "VIN": {"S": "4Y1SL65848Z411439"}
}
EOF
}

📝 Use jsonencode() or Heredoc syntax (<<EOF ... EOF) to structure your JSON item.

---

🔁 Sample Multiple Items

You can repeat the aws_dynamodb_table_item resource block for each item, or modularize for dynamic item insertion (advanced):

{
  "Manufacturer": {"S": "Honda"},
  "Model": {"S": "Civic"},
  "Year": {"N": "2017"},
  "VIN": {"S": "DY1SL65848Z411432"}
}

---

🧪 Terraform Workflow

1. ✅ Initialize:

    terraform init
   

2. 🔍 Preview plan:

    terraform plan
   

3. 🚀 Apply resources:

    terraform apply
   

   Confirm with yes.

---

✅ Output Example

aws_dynamodb_table.cars: Creation complete [id=cars]
aws_dynamodb_table_item.car-items: Creation complete [id=VIN=4Y1SL65848Z411439]
Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

---

📌 Notes

• Use "S" for string, "N" for number, "BOOL" for boolean.

• Each item block must be valid JSON and match the defined schema.

• For production, use IAM roles and policies for permission control.

• You can define additional attributes like range_key, TTL, or tags.

---

📦 Terraform Remote State & Best Practices

---

📘 What is Terraform State?

• terraform.tfstate stores the current state of infrastructure.

• Maps real-world resources to your Terraform configuration.

• Tracks metadata (e.g., resource IDs, IPs, volumes).

• Enables performance optimization by caching state data.

---

⚠️ Why You Should NOT Store State Files in Version Control

❌ Never commit terraform.tfstate to Git or any VCS.

Reasons:

• It can contain sensitive information (access keys, IPs, passwords).

• Leads to merge conflicts when used by teams.

• Insecure and not designed for collaborative access.

• Risk of accidental changes and security breaches.

✅ Use remote backends (like AWS S3, Terraform Cloud) for secure, shared state management.

---

✅ Remote State: Real-World Usage

Remote Backends Examples:

• AWS S3 (with optional DynamoDB for state locking)

• Terraform Cloud

• Google Cloud Storage

• HashiCorp Consul

---

🔐 State Locking

When using remote backends, Terraform can lock the state file to prevent concurrent writes.

Example Error:

Error: Error locking state: Error acquiring the state lock: resource temporarily unavailable

🔒 Why Locking Matters:

• Prevents simultaneous state updates from multiple users.

• Ensures infrastructure consistency.

• Uses DynamoDB (in AWS) or similar to track active locks.

---

🧪 Example: Remote State with AWS S3

terraform {
  backend "s3" {
    bucket         = "my-terraform-state"
    key            = "env/dev/terraform.tfstate"
    region         = "us-west-2"
    encrypt        = true
    dynamodb_table = "terraform-locks"   # For state locking
  }
}

---

🛠 Benefits of Remote State

---

📁 Common Files

• main.tf → Infrastructure definitions

• terraform.tfstate → Auto-generated state file (⚠️ don’t track it!)

• terraform.tfvars → Variable values

• .terraform/ → Terraform cache folder

---

✅ Final Best Practices

• ✔️ Use remote state for collaboration and automation.

• ❌ Never push terraform.tfstate to Git.

• ✔️ Enable state locking to avoid conflicts.

• ✔️ Use backend encryption for added security.

---

📦 Remote State with S3 Backend (Best Practice)

---

✅ Why Use Remote Backend?

• Store terraform.tfstate securely in a central S3 bucket.

• Enable team collaboration without state file conflicts.

• Support automatic state locking with DynamoDB.

• Avoid checking .tfstate into version control.

---

🧾 File Structure

$ ls
main.tf          # Resource definitions
terraform.tf     # Backend config (S3 + DynamoDB)

---

📁 main.tf – Resource Definition

resource "local_file" "pet" {
  filename = "/root/pets.txt"
  content  = "We love pets!"
}

---

⚙️ terraform.tf – Remote Backend Configuration

⚠️ Do not put this block inside main.tf. Keep it separate in terraform.tf.

terraform {
  backend "s3" {
    bucket         = "kodekloud-terraform-state-bucket01"
    key            = "finance/terraform.tfstate"
    region         = "us-west-1"
    dynamodb_table = "state-locking"  # Enables state locking
  }
}

---

🔐 State Locking with DynamoDB

• Prevents simultaneous modifications.

• Table: state-locking

• Required when working with remote teams.

---

▶️ Commands Workflow

1. Initialize backend

    $ terraform init
   

   • Prompts to copy existing local state → Enter yes.

2. Remove local state

    $ rm -rf terraform.tfstate
   

3. Apply configuration

    $ terraform apply
   

   • You’ll see messages like:

       Acquiring state lock...
       Releasing state lock...
     

---

🛑 Warning: Never Track State Files in Version Control

❌ Do not commit terraform.tfstate, .terraform/, or .terraform.lock.hcl.

Use .gitignore:

terraform.tfstate
.terraform/
terraform.tfstate.backup

---

🧠 Summary

📦 Terraform State Management

Terraform maintains infrastructure state in a .tfstate file. This file tracks the mapping between your Terraform configurations and real-world resources.

---

🔧 Common State Subcommands

---

📜 Examples

📋 1. terraform state list

Lists all resources stored in the current state:

$ terraform state list
aws_dynamodb_table.cars
aws_s3_bucket.finance-2020922

🔍 2. terraform state show [resource]

Shows detailed info about a resource from the state:

$ terraform state show aws_s3_bucket.finance-2020922

📌 Output snippet:

bucket = "finance-2020922"
region = "us-west-1"
tags = {
  "Description" = "Bucket to store Finance and Payroll Information"
}

🔁 3. terraform state mv

Moves or renames a resource inside the state (without recreating):

$ terraform state mv aws_dynamodb_table.state-locking aws_dynamodb_table.state-locking-db

✅ Output:

Successfully moved 1 object(s).

📤 4. terraform state pull

Fetches the entire raw state in JSON format:

$ terraform state pull | jq '.resources[] | select(.name=="state-locking-db") | .instances[].attributes.hash_key'

✅ Output:

"LockID"

❌ 5. terraform state rm

Removes a resource from the state (but not from AWS):

$ terraform state rm aws_s3_bucket.finance-2020922

⚠️ This will orphan the real-world resource unless you terraform import it again.

---

🛑 Important: Do NOT Edit .tfstate Manually

Always use the Terraform CLI to safely view or modify state. Editing the state file directly can corrupt it and cause resource drift.

---

🚀 Introduction to AWS EC2 (Elastic Compute Cloud)

AWS EC2 provides resizable compute capacity in the cloud. It allows you to launch virtual machines (instances) with various configurations of CPU, memory, storage, and networking.

---

🖼️ Amazon Machine Images (AMIs)

An AMI is a pre-configured template for your EC2 instance including the OS and software.

---

💡 Instance Types

Different types for different use cases:

📊 General Purpose (T2 Series)

🔗 More EC2 Instance Types

---

💾 EBS Volume Types (Storage)

Elastic Block Store (EBS) is block-level storage attached to EC2 instances.

🔗 More on EBS Volumes

---

🔐 Access Methods

• Linux/Ubuntu/RHEL: SSH using Key Pair (PEM file)

• Windows: Connect via RDP using username/password

---

🔧 User Data (Linux Example)

Use user data for automation during instance launch:

#!/bin/bash
sudo apt update
sudo apt install nginx -y
systemctl enable nginx
systemctl start nginx

This script installs and starts Nginx on an Ubuntu web server.

---

⚙️ Example Use Cases

---

📝 Summary

• EC2 = Virtual Machine in the cloud

• AMI = Prebuilt OS image

• Instance Type = Choose based on workload

• EBS Volume = Persistent storage

• User Data = Automate instance configuration

---

🚀 Provisioning AWS EC2 Web Server with Terraform

📦 Purpose

To launch an Ubuntu 20.04 EC2 instance with:

• NGINX pre-installed

• SSH access enabled

• SSH key pair for authentication

• Security Group allowing inbound SSH

• Output the public IP for remote login.

---

📁 Terraform Project Structure

project/
├── main.tf
├── provider.tf
├── output.tf
└── /root/.ssh/web.pub (your SSH public key)

---

🔧 provider.tf

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

---

🔧 main.tf

resource "aws_key_pair" "web" {
  public_key = file("/root/.ssh/web.pub")
}

resource "aws_security_group" "ssh-access" {
  name        = "ssh-access"
  description = "Allow SSH access from the Internet"

  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

resource "aws_instance" "webserver" {
  ami           = "ami-0edab43b6fa892279" # Ubuntu 20.04 LTS
  instance_type = "t2.micro"
  key_name      = aws_key_pair.web.id

  vpc_security_group_ids = [aws_security_group.ssh-access.id]

  user_data = <<-EOF    #USER-DATA WILL RUN ONLY FOR THE FIRST TIME
              #!/bin/bash
              sudo apt update
              sudo apt install nginx -y
              systemctl enable nginx
              systemctl start nginx
              EOF

  tags = {
    Name        = "webserver"
    Description = "An NGINX WebServer on Ubuntu"
  }
}

---

📤 output.tf

output "publicip" {
  value = aws_instance.webserver.public_ip
}

---

✅ Terraform Commands

$ terraform init         # Initialize provider plugins
$ terraform plan         # Review execution plan
$ terraform apply        # Provision the infrastructure

---

🧠 SSH Access

After successful apply:

$ ssh -i /root/.ssh/web ubuntu@<public_ip>

🧩 Replace <public_ip> with the output you got from Terraform.

---

🟢 Validate NGINX

On the EC2 instance:

$ systemctl status nginx

You should see active (running) status.

---

🚀 Terraform Provisioners

Provisioners in Terraform allow you to execute scripts or commands either on the local machine (where Terraform is running) or on the remote resource (like an EC2 instance).

---

🔹 Types of Provisioners

---

🔧 Example: AWS EC2 with remote-exec

📁 main.tf

resource "aws_key_pair" "web" {
  public_key = file("/root/.ssh/web.pub")
}

resource "aws_security_group" "ssh-access" {
  name        = "ssh-access"
  description = "Allow SSH access from the Internet"

  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

resource "aws_instance" "webserver" {
  ami           = "ami-0edab43b6fa892279"
  instance_type = "t2.micro"
  key_name      = aws_key_pair.web.id
  vpc_security_group_ids = [aws_security_group.ssh-access.id]

  provisioner "remote-exec" {
    inline = [
      "sudo apt update",
      "sudo apt install nginx -y",
      "sudo systemctl enable nginx",
      "sudo systemctl start nginx"
    ]

    connection {
      type        = "ssh"
      user        = "ubuntu"
      private_key = file("/root/.ssh/web")
      host        = self.public_ip
    }
  }

  tags = {
    Name = "webserver"
  }
}

✅ What it does: Once the EC2 instance is created, Terraform connects to it using SSH and installs NGINX.

---

🔧 Example: AWS EC2 with local-exec

resource "aws_instance" "webserver" {
  ami           = "ami-0edab43b6fa892279"
  instance_type = "t2.micro"
  key_name      = aws_key_pair.web.id
  vpc_security_group_ids = [aws_security_group.ssh-access.id]

  provisioner "local-exec" {
    command = "echo ${self.public_ip} >> /tmp/ips.txt"
  }

  tags = {
    Name = "webserver"
  }
}

✅ What it does: After the EC2 instance is created, the instance's public IP is written to a local file (/tmp/ips.txt).

---

⚠️ Best Practices for Provisioners

• 🛑 Avoid relying on provisioners in production. Use cloud-init, user_data, or configuration management tools like Ansible or Chef.

• ✅ Use provisioners for quick testing, POCs, or initial configuration.

• 🛡️ Always ensure SSH key access and network rules (Security Groups) are configured before using remote-exec.

---

⚙️ Terraform Provisioner Behavior

Provisioners allow you to run scripts or commands during the resource lifecycle — at creation or during destruction.

---

🟢 1. Creation-Time Provisioner

These run immediately after the resource is created.

📄 main.tf

resource "aws_instance" "webserver" {
  ami           = "ami-0edab43b6fa892279"
  instance_type = "t2.micro"

  provisioner "local-exec" {
    command = "echo Instance ${self.public_ip} Created! > /tmp/instance_state.txt"
  }
}

✅ Output

$ cat /tmp/instance_state.txt
Instance 3.96.136.157 Created!

---

🔴 2. Destroy-Time Provisioner

These run just before the resource is destroyed by using when = destroy.

📄 main.tf

resource "aws_instance" "webserver" {
  ami           = "ami-0edab43b6fa892279"
  instance_type = "t2.micro"

  provisioner "local-exec" {
    command = "echo Instance ${self.public_ip} Created! > /tmp/instance_state.txt"
  }

  provisioner "local-exec" {
    when    = destroy
    command = "echo Instance ${self.public_ip} Destroyed! > /tmp/instance_state.txt"
  }
}

✅ Output after terraform destroy

$ cat /tmp/instance_state.txt
Instance 3.96.136.157 Destroyed!

---

⚠️ 3. Provisioner Failure Behavior

Use on_failure to control what Terraform should do when a provisioner fails:

📄 Example with fail

provisioner "local-exec" {
  command    = "echo ${self.public_ip} > /temp/pub_ip.txt" # invalid path
  on_failure = "fail"
}

⛔ This will stop the apply due to an invalid path (/temp instead of /tmp).

📄 Example with continue

provisioner "local-exec" {
  command    = "echo ${self.public_ip} > /temp/pub_ip.txt" # still invalid
  on_failure = "continue"
}

✅ Execution continues even if the provisioner command fails.

---

✅ Terraform Provisioners: Key Considerations

Provisioners allow custom scripts/commands to run after resource creation or before destruction. Use them wisely and sparingly.

---

🧭 Provisioner Types

---

🛠️ Example: remote-exec

resource "aws_instance" "webserver" {
  ami           = "ami-0edab43b6fa892279"
  instance_type = "t2.micro"
  tags = {
    Name        = "webserver"
    Description = "An NGINX WebServer on Ubuntu"
  }

  provisioner "remote-exec" {
    inline = ["echo $(hostname -i) >> /tmp/ips.txt"]
  }

  connection {
    type        = "ssh"
    user        = "ubuntu"
    private_key = file("/root/.ssh/web")
    host        = self.public_ip
  }
}

---

🔐 Remote-Exec Requirements

✅ Ensure the following for successful remote-exec:

• 🔓 Security Group allows SSH (port 22) or WinRM (port 5985/5986)

• 🗝️ SSH Key Pair is available and injected

• 🌐 EC2 instance has public IP (or private IP with VPN/Direct Connect)

• 📡 Hostname resolution or direct IP accessible

---

❗ Considerations

• 📦 Provisioners are not idempotent — if a provisioner fails or succeeds partially, re-running may produce unintended results.

• ❌ Provisioners do not show up in terraform plan — they are part of the apply phase only.

• 🔄 Avoid using provisioners for routine configurations. Prefer user_data, AMIs, or config management tools.

---

🆚 Provisioner vs Cloud-Native Bootstrapping

---

📋 Provider Specific Metadata Options

---

🎯 Alternative to Provisioners: Custom AMI

Instead of scripting NGINX installation each time, build a custom AMI using tools like Packer:

nginx-build.json
{
  "builders": [{ ... }],
  "provisioners": [
    {
      "type": "shell",
      "inline": [
        "sudo apt update",
        "sudo apt install -y nginx"
      ]
    }
  ]
}

➡️ Use this AMI in Terraform:

ami = "ami-XYZ"  # Your custom NGINX AMI

---

🏁 Final Notes

• 📌 Use provisioners only when absolutely necessary

• 🛡️ For robust and secure infrastructure, prefer immutable infrastructure principles

• 📂 Use user_data for most bootstrapping tasks in cloud VMs

---

🧨 Terraform taint Command

🔍 What is taint?

terraform taint marks a resource for forced recreation during the next terraform apply.

🔁 Useful when the resource is still working but misconfigured or corrupted, and you want Terraform to destroy and recreate it.

---

✅ Syntax

terraform taint <resource_name>

📌 Example:

terraform taint aws_instance.webserver

📤 Result:

• Terraform marks the resource as "tainted"

• The next terraform apply will:

  • destroy the current resource

  • then recreate it

---

🧹 To Reverse It

terraform untaint <resource_name>

📌 Example:

terraform untaint aws_instance.webserver

📤 Result:

• Terraform removes the taint flag

• No changes will be made in next apply (if config is unchanged)

---

📓 Terraform Plan Output (after taint)

# aws_instance.webserver is tainted, so must be replaced
-/+ resource "aws_instance" "webserver" {

This means Terraform will destroy the current instance and then create a new one.

---

🛠️ Terraform Provisioner Failure Example

provisioner "local-exec" {
  command = "echo ${aws_instance.webserver.public_ip} > /temp/pub_ip.txt"
}

❌ This causes an error on Windows:

Error: The system cannot find the path specified.

✅ Fix:
Use a valid directory path, such as:

command = "echo ${aws_instance.webserver.public_ip} > C:\\temp\\pub_ip.txt"

---

🐞 Terraform Debugging

🔍 Enable Debug Logs

export TF_LOG=TRACE

📌 Other log levels: TRACE > DEBUG > INFO > WARN > ERROR

TRACE provides the most detailed information.

---

📝 Log to File

export TF_LOG_PATH=/tmp/terraform.log

✅ View logs:

head -10 /tmp/terraform.log

🧼 Turn off logging:

unset TF_LOG
unset TF_LOG_PATH

---

✅ Terraform Import

Terraform allows importing existing resources (e.g., EC2, S3, Route53) so they can be managed via Terraform configuration and state.

---

🎯 Objective: Import an existing EC2 instance into Terraform

---

🪜 Step-by-Step Guide

---

✅ Step 1: Use data block to read existing resource (optional)

You used a data block like this:

data "aws_instance" "newserver" {
  instance_id = "i-026e13be10d5326f7"
}

output "newserver" {
  value = data.aws_instance.newserver.public_ip
}

Then:

$ terraform apply

📦 Output:

Apply complete!
Outputs:
newserver = 15.223.1.176

✔️ This is just to view an existing resource, but not manage it.

---

✅ Step 2: Attempt to import the resource (Fails without config)

You ran:

$ terraform import aws_instance.webserver-2 i-026e13be10d5326f7

🛑 Error:

Error: resource address "aws_instance.webserver-2" does not exist in the configuration.
Before importing this resource, please create its configuration in the root module.

---

✅ Step 3: Add the matching resource block to main.tf

You created:

resource "aws_instance" "webserver-2" {
  # (resource arguments)
}

Just a basic skeleton — doesn't need full values yet.

---

✅ Step 4: Run terraform import again

$ terraform import aws_instance.webserver-2 i-026e13be10d5326f7

📦 Output:

aws_instance.webserver-2: Importing from ID "i-026e13be10d5326f7"...  
Import successful!

---

✅ Step 5: Review in terraform.tfstate

After import, Terraform records the actual live configuration:

{
  "type": "aws_instance",
  "name": "webserver-2",
  "provider": "provider[\"registry.terraform.io/hashicorp/aws\"]",
  "instances": [
    {
      "attributes": {
        "ami": "ami-0edab43b6fa892279",
        "instance_type": "t2.micro",
        "key_name": "ws",
        "tags": {
          "Name": "old-ec2"
        },
        "vpc_security_group_ids": ["sg-8064fdee"]
      }
    }
  ]
}

---

✅ Step 6: Update main.tf with accurate values

You refined your resource block to match the imported state:

resource "aws_instance" "webserver-2" {
  ami                    = "ami-0edab43b6fa892279"
  instance_type          = "t2.micro"
  key_name               = "ws"
  vpc_security_group_ids = ["sg-8064fdee"]

  tags = {
    Name = "old-ec2"
  }
}

---

✅ Step 7: Run terraform plan

$ terraform plan

✔️ Output:

No changes. Infrastructure is up-to-date.

✅ This confirms that Terraform state and config are now in sync.

---

✅ Terraform Modules

---

📦 What is a Module?

A module is a container for multiple Terraform resources grouped together. It helps with:

• Reusability

• Maintainability

• Cleaner main.tf

• Easier collaboration and team management

---

🪜 Section 1: Using a Local Module

---

🧱 1. Create Reusable Module – /aws-instance

📁 Folder: /root/terraform-projects/aws-instance

main.tf

resource "aws_instance" "webserver" {
  ami           = var.ami
  instance_type = var.instance_type
  key_name      = var.key
}

variables.tf

variable "ami" {
  type        = string
  default     = "ami-0edab43b6fa892279"
  description = "AMI ID"
}

variable "instance_type" {
  type    = string
  default = "t2.micro"
}

variable "key" {
  type = string
}

---

🔧 2. Consume Module in Root Project – /development

📁 Folder: /root/terraform-projects/development

main.tf

module "dev-webserver" {
  source        = "../aws-instance"
  ami           = "ami-0edab43b6fa892279"
  instance_type = "t2.micro"
  key           = "dev-key"
}

---

▶️ 3. Initialize & Apply

$ terraform init
$ terraform apply

✔️ Output: EC2 created from the module.

---

🧩 Section 2: Complex Modules with Reuse (Payroll App)

---

🔁 Reusable Module – /modules/payroll-app

📁 Folder: /root/terraform-projects/modules/payroll-app

Module Files:

• app_server.tf

• dynamodb_table.tf

• s3_bucket.tf

• variables.tf

✅ Sample – app_server.tf

resource "aws_instance" "app_server" {
  ami           = var.ami
  instance_type = "t2.medium"
  tags = {
    Name = "${var.app_region}-app-server"
  }
  depends_on = [
    aws_dynamodb_table.payroll_db,
    aws_s3_bucket.payroll_data
  ]
}

✅ Sample – s3_bucket.tf

resource "aws_s3_bucket" "payroll_data" {
  bucket = "${var.app_region}-${var.bucket}"
}

✅ Sample – dynamodb_table.tf

resource "aws_dynamodb_table" "payroll_db" {
  name         = "user_data"
  billing_mode = "PAY_PER_REQUEST"
  hash_key     = "EmployeeID"

  attribute {
    name = "EmployeeID"
    type = "N"
  }
}

✅ Sample – variables.tf

variable "app_region" {
  type = string
}

variable "bucket" {
  type    = string
  default = "flexit-payroll-alpha-22001c"
}

variable "ami" {
  type = string
}

---

🇺🇸 US Payroll App

📁 /us-payroll-app

main.tf

module "us_payroll" {
  source      = "../modules/payroll-app"
  app_region  = "us-east-1"
  ami         = "ami-24e140119877avm"
}

provider.tf

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

🛠️ Run:

$ terraform init
$ terraform apply

---

🇬🇧 UK Payroll App

📁 /uk-payroll-app

main.tf

module "uk_payroll" {
  source      = "../modules/payroll-app"
  app_region  = "eu-west-2"
  ami         = "ami-35e140119877avm"
}

provider.tf

provider "aws" {
  region = "eu-west-2"
}

🛠️ Run:

$ terraform init
$ terraform apply

✅ Standardized config for multiple regions with shared logic.

---

🌐 Section 3: Using Modules from Terraform Registry

📍 Example: SSH Security Group Module

main.tf

module "security-group_ssh" {
  source               = "terraform-aws-modules/security-group/aws//modules/ssh"
  version              = "3.16.0"
  vpc_id               = "vpc-7d8d215"
  ingress_cidr_blocks  = [ "10.10.0.0/16" ]
  name                 = "ssh-access"
}

👉 Get the module:

$ terraform get

---

✅ Benefits of Modules

---

🧠 Terraform Functions & Conditional Logic – Explained with Examples

---

📘 1. Why Functions?

Terraform functions allow you to transform, manipulate, or validate values inside configurations and templates. They increase reusability, reduce duplication, and improve logic-based deployments.

---

🔢 2. Numeric Functions

variable "num" {
  type        = set(number)
  default     = [250, 10, 11, 5]
  description = "A set of numbers"
}

---

🔤 3. String Functions

---

🧺 4. Collection Functions

List Example

variable "ami" {
  type        = list(string)
  default     = ["ami-xyz", "AMI-ABC", "ami-efg"]
}

---

🗺️ 5. Map Functions

Map Example

variable "ami" {
  type = map(string)
  default = {
    "us-east-1"    = "ami-xyz",
    "ca-central-1" = "ami-efg",
    "ap-south-1"   = "ami-ABC"
  }
}

---

🔁 6. Type Conversion

---

🔀 7. Operators

Numeric, Equality, Comparison

> 1 + 2         // 3
> 8 == 8        // true
> 5 > 7         // false
> 4 < 5         // true

Logical

> 8 > 7 && 8 < 10       // true
> 8 > 10 || 8 < 10      // true
> ! true                // false

---

❓ 8. Conditional Expressions

Syntax:

condition ? true_val : false_val

🔐 Example – Password Generator

resource "random_password" "password-generator" {
  length = var.length < 8 ? 8 : var.length
}

variable "length" {
  type        = number
  description = "The length of the password"
}

Run Example:

$ terraform apply -var=length=5 -auto-approve

✔️ Output: Will create password with length = 8

---

🧪 9. terraform console – Test Functions

$ terraform console

> length([1,2,3])
3

> split(",", "a,b,c")
["a", "b", "c"]

> var.length < 8 ? 8 : var.length
8

---

🔧 Terraform Workspaces – Real World Usage

✅ What are Terraform Workspaces?

Terraform Workspaces allow you to use the same configuration to manage multiple environments (like dev, staging, prod) while keeping independent state files.

---

📂 Project Structure Overview

/root/terraform-projects/project/
├── main.tf
├── variables.tf
├── terraform.tfstate.d/
│   ├── ProjectA/
│   │   └── terraform.tfstate
│   └── ProjectB/
│       └── terraform.tfstate

---

🗂️ Why Use Workspaces?

• ✅ Separate environments (e.g., ProjectA, ProjectB)

• ✅ Prevent state file overwrites

• ✅ Simplifies environment isolation without duplicating code

---

🛠️ Steps to Use Terraform Workspaces

1. Initialize Terraform Project

$ terraform init

2. Create and Switch to a Workspace

$ terraform workspace new ProjectA
$ terraform workspace new ProjectB

3. Check Current Workspace

$ terraform workspace show

4. Switch Workspace

$ terraform workspace select ProjectA

5. List Workspaces

$ terraform workspace list

---

📦 Dynamic Configuration with Workspaces

📁 variables.tf

variable "ami" {
  type = map(string)
  default = {
    "ProjectA" = "ami-0edab43b6fa892279",
    "ProjectB" = "ami-0c2f25c1f66a1ff4d"
  }
}

variable "instance_type" {
  default = "t2.micro"
}

📁 main.tf

resource "aws_instance" "project" {
  ami           = lookup(var.ami, terraform.workspace)
  instance_type = var.instance_type

  tags = {
    Name = terraform.workspace
  }
}

---

🔍 Verify in Console

$ terraform console
> terraform.workspace
"ProjectA"
> lookup(var.ami, terraform.workspace)
"ami-0edab43b6fa892279"

---

✅ Final Results

Each workspace manages its own state:

terraform.tfstate.d/
├── ProjectA/ → EC2 with AMI-A
└── ProjectB/ → EC2 with AMI-B

---

📌 Use Case

Perfect for managing multiple isolated deployments (per project, team, environment) without duplicating Terraform code.