+92 345 2180748     info@hysec.com.pk
Hysec - AWS Documentation
DevOps Job Ready Program

Learn • Practice • Get Hired

Terraform Fundamentals

1. Introduction to Terraform

Terraform is an open-source Infrastructure as Code (IaC) tool developed by HashiCorp that enables engineers to define, provision, and manage infrastructure using configuration files.

Terraform allows DevOps engineers to automate the creation of:

Instead of manually creating resources, Terraform uses code to build and maintain infrastructure consistently.

HYSEC Image

2. What is Infrastructure as Code (IaC)?

Infrastructure as Code is the process of managing infrastructure through code rather than manual configuration.

Traditional Approach: Login to Cloud Console → Create Resources Manually → Configure Servers → Repeat for Each Environment

Terraform IaC Approach: Write Terraform Code → Terraform Plan → Terraform Apply → Infrastructure Created

Benefits: Automation, Consistency, Faster deployments, Version control, Reduced human errors.

3. Terraform Architecture

    Terraform CLI
          |
    Terraform Core
          |
    -----------------------------
    |             |             |
    AWS Provider  Azure Provider  GCP Provider
    |             |             |
    EC2           VM            Compute
    VPC           Network       Storage
    S3            Database      Kubernetes
    

Terraform Core: Responsible for reading configuration files, creating execution plans, managing state, and communicating with providers.

Providers: Plugins that connect Terraform with external platforms (e.g., AWS, Azure, Kubernetes, Docker).

4. Terraform Language (HCL)

Terraform uses HashiCorp Configuration Language (HCL). Files have the extension: .tf

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

5. Terraform Core Concepts

HYSEC Image

6. Terraform Workflow

7. Terraform Project Structure

FilePurpose
provider.tfCloud provider configuration
main.tfMain infrastructure code
variables.tfVariable definitions
outputs.tfOutput values
terraform.tfvarsVariable values
terraform.tfstateInfrastructure state

8. Terraform Providers Example

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

Kubernetes: provider "kubernetes" { config_path = "~/.kube/config" }

9. Terraform Resource Dependencies

Terraform automatically understands dependencies (e.g., VPC → Subnet → EC2 Instance → Load Balancer) and creates resources in the correct order.

10. Terraform State Management

11. Terraform Best Practices

12. Terraform in DevOps

Workflow: Developer → GitHub → Jenkins / GitHub Actions → Terraform Plan → Terraform Apply → AWS Infrastructure → Application Deployment

13. Terraform Fundamentals Commands

CommandDescription
terraform initInitialize Terraform
terraform planPreview changes
terraform applyDeploy resources
terraform destroyRemove resources
terraform validateValidate syntax
terraform fmtFormat files
terraform outputDisplay outputs
terraform state listList resources
terraform versionCheck version

Summary

Terraform Fundamentals include IaC concepts, architecture, HCL, providers, resources, variables, state management, and best practices. It is a key skill for DevOps and Cloud engineers for automated, repeatable, and scalable infrastructure.

AWS Provider Configuration in Terraform

1. What is AWS Provider in Terraform?

The AWS Provider is a Terraform plugin that allows Terraform to communicate with Amazon Web Services (AWS) APIs and manage AWS infrastructure resources.

Using the AWS Provider, Terraform can create and manage: EC2 Instances, VPC Networks, Subnets, Security Groups, S3 Buckets, IAM Users and Roles, RDS Databases, Load Balancers, Route 53 DNS Records.

2. Terraform Provider Configuration Structure

A provider block defines how Terraform connects to AWS.

provider "aws" { region = "us-east-1" }
ParameterDescription
providerDefines cloud platform
awsAWS provider name
regionAWS region where resources are created

3. Installing AWS Provider

Terraform downloads providers during initialization. Command: terraform init

Terraform downloads AWS Provider from registry.terraform.io.

4. Provider Version Configuration

It is recommended to define the provider version to avoid unexpected changes.

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}
provider "aws" { region = "us-east-1" }
    

5. AWS Authentication Methods

Method 1: AWS CLI Credentials (Recommended)
Run aws configure. Credentials stored in ~/.aws/credentials (Linux) or C:\Users\username\.aws\credentials (Windows).

Method 2: Environment Variables
Set AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY in terminal.

Method 3: IAM Role (Best for Production)
Used on EC2, Jenkins, GitHub Actions, Kubernetes. Advantages: More secure, no access keys, automatic credential rotation.

6. Multiple AWS Providers

Terraform can manage multiple AWS regions using alias.

provider "aws" { region = "us-east-1" }
provider "aws" { alias = "mumbai", region = "ap-south-1" }

resource "aws_instance" "india_server" {
  provider = aws.mumbai
  ...
}
    

7. AWS Provider with Profile

For multiple AWS accounts, use the profile parameter in the provider block pointing to entries in your credentials file.

provider "aws" { region = "us-east-1", profile = "dev" }

8. AWS Provider with Default Tags

Terraform allows common tags for all resources.

provider "aws" {
  default_tags {
    tags = {
      Environment = "Production"
      Owner       = "DevOps-Team"
    }
  }
}
    

9. AWS Provider Example Project

Directory: terraform-aws-project/ contains provider.tf, main.tf, variables.tf, outputs.tf.

Example main.tf:

resource "aws_instance" "web" {
  ami           = "ami-0c02fb55956c7d316"
  instance_type = "t2.micro"
  tags          = { Name = "Terraform-Server" }
}
    

10. Testing AWS Provider Configuration

1. terraform init
2. terraform validate
3. terraform plan
4. terraform apply

11. Common AWS Provider Errors

12. AWS Provider Best Practices

Terraform State Management

1. What is Terraform State?

Terraform State is a mechanism that Terraform uses to track and manage the infrastructure resources it creates.

Terraform stores information about your infrastructure in a state file: terraform.tfstate

The state file acts as a mapping between Terraform configuration code and real-world infrastructure.

Example: Terraform Code (.tf) -> Terraform State File (terraform.tfstate) -> AWS Infrastructure (EC2, VPC, S3, RDS)

Without state, Terraform cannot determine:

2. Why Terraform State is Important?

1. Resource Tracking: Terraform knows which AWS resources belong to the project. (e.g., Instance ID, IP, Region).

2. Change Detection: Terraform compares Configuration File + State File + Actual Infrastructure to determine required changes.

3. Dependency Management: Terraform state stores relationships between resources (e.g., VPC -> Subnet -> EC2 -> Load Balancer), creating them in the correct order.

3. Terraform State File

Default state file: terraform.tfstate

{
 "version": 4,
 "resources": [
  {
    "type": "aws_instance",
    "name": "web"
  }
 ]
}
    

The state file contains: Resource IDs, Metadata, Dependencies, Attributes, Provider information.

4. Local State vs Remote State

Local State: Default Terraform behavior (Stored on Developer Laptop).
Advantages: Simple setup, Good for learning, Works for small projects.
Disadvantages: Difficult for teams, No locking, Risk of losing state file.

5. Remote State Management

In production, state is stored remotely. Common backends: AWS S3, Azure Storage, Google Cloud Storage, Terraform Cloud.

Benefits: Team collaboration, Centralized storage, State locking, Backup support, Better security.

6. AWS S3 Remote State Configuration

terraform {
  backend "s3" {
    bucket = "company-terraform-state"
    key    = "prod/network/terraform.tfstate"
    region = "us-east-1"
  }
}
    

Command: terraform init (Moves state from local to S3).

7. State Locking

Prevents multiple users from modifying infrastructure simultaneously. AWS uses S3 (Storage) + DynamoDB (Lock management).

terraform {
  backend "s3" {
    bucket = "terraform-state"
    key = "production.tfstate"
    region = "us-east-1"
    dynamodb_table = "terraform-lock"
  }
}
    

8. Terraform State Commands

9. Terraform State Refresh

Updates Terraform state with real infrastructure. Command: terraform refresh

10. State Backup

Terraform creates: terraform.tfstate.backup. Best practice: Store remotely, enable versioning, encrypt.

11. Securing Terraform State

State may contain: Passwords, API keys, DB info. Practices: Encrypt storage, Restrict IAM, Enable S3 versioning, Use private storage. Never commit to Git. Add to .gitignore: terraform.tfstate, terraform.tfstate.backup, .terraform/

12. Terraform State Workflow

Terraform Code -> terraform plan -> Compare (Configuration + State + Cloud Resources) -> terraform apply -> Update State

13. Terraform State Best Practices

PracticeBenefit
Use remote backendTeam collaboration
Enable state lockingPrevent conflicts
Encrypt stateSecurity
Use IAM permissionsAccess control
Backup stateRecovery
Avoid manual editingPrevent corruption
Separate environmentsBetter management

14. Terraform State in DevOps Pipeline

Developer -> GitHub -> Jenkins Pipeline -> Terraform Plan -> Terraform Apply -> AWS Resources -> Remote State (S3)

Summary

Terraform State Management is the process of storing, tracking, securing, and controlling infrastructure information. Key concepts: terraform.tfstate, Local vs Remote, Locking, S3 Backend, DynamoDB, State Commands, Security. For enterprise, use S3 + DynamoDB locking.

Terraform Variables & Outputs

Terraform Variables and Outputs are fundamental concepts used to make Terraform configurations reusable, flexible, and easy to manage.

1. Terraform Variables

Variables allow you to pass dynamic values into Terraform configurations instead of hardcoding values.

Problem without variables: Hard to change, Not reusable, Difficult for multiple environments.

2. Types of Terraform Variables

TypeExample
string"t2.micro"
number2
booltrue/false
list["web","db"]
map{env="prod"}
objectComplex structure

3. Declaring Variables

Variables are usually defined in variables.tf.

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

4. Using Variables

Use variables with: var.variable_name

resource "aws_instance" "web" {
  ami           = "ami-123456"
  instance_type = var.instance_type
}
    

5. Variable Types Examples

String: variable "region" { type = string, default = "us-east-1" }
Number: variable "instance_count" { type = number, default = 3 }
Boolean: variable "enable_monitoring" { type = bool, default = true }
List: variable "availability_zones" { type = list(string), default = ["us-east-1a", "us-east-1b"] }
Map: variable "tags" { type = map(string), default = { Environment = "Production", Owner = "DevOps" } }

6. Variable Values Using terraform.tfvars

instance_type = "t3.medium"
region        = "us-west-2"
environment   = "production"
    

7. Passing Variables Through Command Line

terraform apply -var="instance_type=t3.large"

8. Environment Variables

Linux: export TF_VAR_region="us-east-1". Terraform reads: var.region

9. Variable Validation

variable "environment" {
  type = string
  validation {
    condition     = contains(["dev","test","prod"], var.environment)
    error_message = "Environment must be dev, test or prod."
  }
}
    

10. Sensitive Variables

variable "db_password" { type = string, sensitive = true }. Terraform hides the value.

11. Terraform Outputs

Outputs display important information after Terraform creates resources (IPs, URLs, IDs, Endpoints). Defined in outputs.tf.

12. Basic Output Example

output "public_ip" {
  value = aws_instance.web.public_ip
}
    

13. Output Attributes

output "instance_information" {
  description = "EC2 Details"
  value = {
    id = aws_instance.web.id
    ip = aws_instance.web.public_ip
  }
}
    

14. Sensitive Outputs

output "database_password" { value = var.db_password, sensitive = true }

15. Output Usage Between Modules

VPC Module: output "vpc_id" { value = aws_vpc.main.id }
EC2 Module: vpc_id = module.vpc.vpc_id

16. Complete Example: AWS EC2 with Variables & Outputs

variables.tf: variable "instance_type" { default = "t2.micro" }
provider.tf: provider "aws" { region = var.region }
main.tf: resource "aws_instance" "web" { ami = "...", instance_type = var.instance_type }
outputs.tf: output "server_ip" { value = aws_instance.web.public_ip }

17. Variables & Outputs Workflow

terraform.tfvars -> variables.tf -> main.tf -> AWS Resources -> outputs.tf -> User/Application

18. Best Practices

Variables: Use instead of hardcoding, Keep secrets in secret managers, Use descriptions, Add validation, Separate environment values.
Outputs: Output only required info, Mark sensitive, Use for module communication, Avoid exposing secrets.

Summary

FeatureVariablesOutputs
PurposeInput valuesDisplay values
DirectionUser → TerraformTerraform → User
Filevariables.tfoutputs.tf
Used ForReusabilityInformation sharing

Terraform Modules

What is a Terraform Module?

A Terraform Module is a collection of Terraform configuration files (.tf) that are grouped together and used as a reusable infrastructure component.

Modules help DevOps engineers organize, reuse, and maintain Terraform code across multiple projects and environments.

Example Concept:

Without Modules: Project A & Project B (Both manually writing VPC, EC2, SG code).
With Modules: VPC Module serving both Development and Production.

Why Use Terraform Modules?

✅ Code reusability
✅ Standardized infrastructure
✅ Easier maintenance
✅ Faster deployments
✅ Reduced duplication
✅ Better team collaboration
✅ Environment consistency

Types of Terraform Modules

1. Root Module: The main Terraform configuration where you run commands (e.g., terraform-project/main.tf).
2. Child Module: A reusable module called by the root module (e.g., terraform-project/modules/vpc/).

Terraform Module Structure

Typical structure: modules/aws-vpc/ contains main.tf (Resources), variables.tf (Inputs), outputs.tf (Returns values), and README.md.

Calling a Module

Modules are called using the module block.

module "vpc" {
  source   = "./modules/vpc"
  vpc_cidr = "10.0.0.0/16"
}
    
ParameterPurpose
moduleDefines module
vpcModule name
sourceModule location
vpc_cidrInput variable

Terraform Module Workflow

Root Module -> Calls Module -> Module Input Variables -> Creates Resources -> Module Outputs -> Root Module Uses Values.

Example: AWS VPC Module

modules/vpc/main.tf: resource "aws_vpc" "main" { cidr_block = var.vpc_cidr, tags = { Name = var.name } }
modules/vpc/variables.tf: variable "vpc_cidr" { type = string }, variable "name" { type = string }
modules/vpc/outputs.tf: output "vpc_id" { value = aws_vpc.main.id }
Root main.tf: module "network" { source = "./modules/vpc", vpc_cidr = "10.0.0.0/16", name = "Production-VPC" }

Terraform Registry Modules

Terraform provides thousands of community modules. Example: source = "terraform-aws-modules/vpc/aws". Benefits: Tested code, Faster development, Industry standards.

Module Inputs and Outputs

Input Flow: Root Module -> Variables -> Child Module -> Resources.
Output Flow: Resources -> Child Module Output -> Root Module.

Module Versioning

Production modules should use version = "5.1.0". Advantages: Stability, Controlled updates, Safer deployments.

Local vs Remote Modules

Local: source = "./modules/network"
Remote: source = "git::https://github.com/company/aws-module.git" (GitHub, Registry, Terraform Cloud).

Multi-Environment Setup

Infrastructure -> Module Library -> Dev / Test / Production environments utilizing same module files.

Terraform Modules Best Practices

✅ Create small reusable modules
✅ Use meaningful names
✅ Document inputs and outputs
✅ Use version control
✅ Avoid hardcoding values
✅ Use variables for customization
✅ Keep modules independent
✅ Use official/community modules.

Modules in DevOps CI/CD

Developer -> Git Repository -> Jenkins/GitHub Actions -> Terraform Module -> AWS Infrastructure -> Remote State (S3).

Summary

Terraform Modules are reusable building blocks for infrastructure automation. Key concepts: Root vs Child, Structure, Inputs/Outputs, Local vs Remote, Registry, Versioning. Modules are essential for enterprise DevOps environments for scalability and maintainability.

Terraform Remote Backend (S3 + DynamoDB)

What is Terraform Backend?

A Terraform Backend defines where Terraform stores its state file (terraform.tfstate). By default, Terraform stores state locally. In a team or production environment, Terraform state should be stored remotely.

A Remote Backend provides: Centralized state storage, Team collaboration, State locking, Backup and recovery, Better security.

Why Use Remote Backend?

Local state creates problems like multiple state versions, no collaboration, risk of losing state, and no locking mechanism. Remote backend solution uses AWS S3 for State Storage and DynamoDB for State Locking.

AWS S3 Backend

Amazon S3 is used to store Terraform state files remotely. Advantages: Highly available, Versioning support, Encryption support, Access control using IAM.

DynamoDB State Locking

DynamoDB prevents multiple users from running Terraform changes simultaneously. Without locking, state corruption can occur.

Architecture: S3 + DynamoDB

Developer -> Terraform CLI -> [AWS S3 Bucket (State Storage)] & [DynamoDB Table (State Locking)].

Create S3 Bucket for Terraform State

aws s3api create-bucket --bucket hysec-terraform-state --region us-east-1

Enable S3 Versioning

aws s3api put-bucket-versioning --bucket hysec-terraform-state --versioning-configuration Status=Enabled

Enable S3 Encryption

aws s3api put-bucket-encryption --bucket hysec-terraform-state --server-side-encryption-configuration '{"Rules":[{"ApplyServerSideEncryptionByDefault":{"SSEAlgorithm":"AES256"}}]}'

Create DynamoDB Lock Table

Table Name: terraform-lock, Primary Key: LockID (String), Billing: PAY_PER_REQUEST.

10. Configure Terraform Backend

terraform {
  backend "s3" {
    bucket         = "hysec-terraform-state"
    key            = "prod/terraform.tfstate"
    region         = "us-east-1"
    dynamodb_table = "terraform-lock"
    encrypt        = true
  }
}
    

Initialize Remote Backend

Run: terraform init. This connects to S3, configures DynamoDB locking, and moves local state to S3.

Terraform State Migration

Terraform asks: "Do you want to copy existing state to S3?" Answer: yes.

Using Multiple Environments

Dev: key = "dev/terraform.tfstate", Prod: key = "prod/terraform.tfstate".

Backend Security Best Practices

S3: Encryption, Versioning, Block public access, IAM policies, Logging.
DynamoDB: Restrict access, Allow only Terraform users, Monitor activity.

IAM Permissions Required

S3: s3:GetObject, s3:PutObject, s3:ListBucket, s3:DeleteObject.
DynamoDB: dynamodb:GetItem, dynamodb:PutItem, dynamodb:DeleteItem.

Common Backend Errors

NoSuchBucket: Create S3 bucket first.
Lock Already Exists: Use terraform force-unlock LOCK_ID.
Access Denied: Check IAM permissions.

Terraform Remote Backend Workflow

Git -> terraform init -> S3 Backend -> Download State -> terraform plan -> DynamoDB Lock -> terraform apply -> Update State.

Remote Backend in CI/CD

Developer -> GitHub -> Jenkins -> Terraform Init -> S3 Backend -> Terraform Apply -> AWS Infrastructure.

. S3 + DynamoDB Backend Best Practices

PracticePurpose
Enable S3 VersioningState recovery
Enable EncryptionProtect sensitive data
Use DynamoDB LockingPrevent conflicts
Separate environmentsBetter management
Restrict IAM accessSecurity
Backup stateDisaster recovery
Use CI/CDAutomation

Summary

Terraform Remote Backend using S3 + DynamoDB is the standard AWS production approach. S3: Stores state, DynamoDB: Locking, Encryption/Versioning: Protection & Recovery. Widely used for safe, collaborative DevOps.

Terraform Workspaces

What are Terraform Workspaces?

Terraform Workspaces allow you to manage multiple separate environments (dev, test, staging, prod) using the same Terraform configuration without duplicating code.

Why Use Terraform Workspaces?

Benefits: Same code for multiple environments, Separate state management, Easy environment switching, Reduced code duplication.

Terraform Workspace Architecture

A single Terraform code block acts as the base for different workspaces (dev, test, prod), each maintaining its own isolated terraform.tfstate.

Default Workspace

Every initialized project starts with a default workspace. Command: terraform workspace show.

Workspace Commands

List: terraform workspace list
Create/Switch: terraform workspace new dev
Select: terraform workspace select prod
Show: terraform workspace show
Delete: terraform workspace delete dev

Using Workspaces with Variables

Workspaces are commonly used with conditional logic or local variables to set environment-specific values.

Using terraform.workspace

Example: tags = { Name = "${terraform.workspace}-server" }. This allows dynamic naming based on the active workspace.

Workspace-Based Infrastructure

resource "aws_instance" "server" {
  instance_type = terraform.workspace == "prod" ? "t3.large" : "t2.micro"
  tags = { Environment = terraform.workspace }
}
    

Creating Multiple Environments

You can create various environments using terraform workspace new and track them via terraform workspace list.

Workspace State Storage

Local: Stored in terraform.tfstate.d/.
Remote (S3): Terraform automatically creates an env: directory path in the bucket for each workspace state file.

Workspaces vs Separate Directories

FeatureWorkspacesSeparate Directories
Code duplicationLowHigh
Environment isolationGoodExcellent
Large projectsLimitedRecommended

Terraform Workspace Workflow

Select environment (e.g., select dev) -> terraform plan -> terraform apply.

Workspace Best Practices

✅ Use for similar environments
✅ Keep production isolated
✅ Use remote backend with locking
✅ Use naming conventions.

When NOT to Use Workspaces

Avoid when infrastructure is completely different, different teams manage environments, or AWS accounts require strict isolation. Enterprise deployments prefer a directory-based approach.

Terraform Workspace in CI/CD

In a CI/CD pipeline, the process selects the appropriate workspace based on the branch or environment trigger, runs plan, and then apply.

Summary

Terraform Workspaces provide efficient environment management using one configuration. They are ideal for small to medium setups, while large enterprises often lean toward modular, directory-based structures combined with remote backends.

Infrastructure Provisioning with Terraform

What is Infrastructure Provisioning?

Infrastructure Provisioning is the process of creating, configuring, and managing IT resources like servers, networks, and databases. Unlike traditional manual creation, Terraform uses Infrastructure as Code (IaC) to automate these processes via configuration files.

Types of Infrastructure Provisioning

A. Manual: Creating resources via Cloud Consoles. (Problems: Slow, human error, hard to repeat).
B. Automated: Using tools like Terraform, CloudFormation, Ansible. (Benefits: Fast, consistent, version-controlled).

Terraform Infrastructure Provisioning Workflow

Developer -> Terraform Config (.tf) -> terraform init -> terraform plan -> terraform apply -> Cloud Provider API -> Infrastructure.

Terraform Provisioning Components

Provider: Defines the cloud platform (e.g., AWS).
Resource: Defines infrastructure objects (e.g., EC2).
Variables: For dynamic configuration.
Outputs: Display resource information.

AWS Infrastructure Provisioning Example

Includes defining aws_vpc, aws_subnet, and aws_instance using HCL resource blocks.

Terraform Provisioning Lifecycle

Create: Deploying new resources.
Update: Modifying existing resources.
Destroy: Removing resources using terraform destroy.

Infrastructure Provisioning Example

Terraform manages the entire stack: VPC, Subnets, Security Groups, EC2, Load Balancer, RDS, and S3.

Terraform Provisioning with Modules

Large infrastructure is organized into modules/network, modules/compute, and modules/database for better reusability and maintenance.

Infrastructure Provisioning in CI/CD

Automated workflow: GitHub -> Jenkins -> terraform init -> plan -> apply -> AWS.

Terraform Provisioning Best Practices

Code Mgmt: Use Git, branches, code reviews.
Security: IAM roles, avoid hardcoding, encrypt state.
State: Use AWS S3 Backend + DynamoDB Locking.

Terraform Provisioning vs Configuration Management

FeatureTerraformAnsible
PurposeInfrastructure creationSoftware configuration
FocusCreates serversConfigures OS/apps
LanguageHCLYAML

Real-World Infrastructure Provisioning Projects

1. Web App: VPC, Subnets, EC2, LB, RDS.
2. Kubernetes: Cluster, Worker Nodes, Networking.
3. Multi-Cloud: Managing AWS, Azure, and Kubernetes resources simultaneously.

Summary

Terraform provisioning is a core DevOps skill. Key concepts include IaC, Providers, Resources, Variables, Modules, State Management, and CI/CD Automation to build production-ready cloud environments.

Automated AWS Infrastructure Provisioning using Terraform (IaC)

Introduction

Project Objective: The primary goal is to shift from manual cloud management to automated, repeatable Infrastructure as Code (IaC) workflows. By utilizing Terraform, we ensure that the entire AWS stack—from networking to database layers—can be deployed in minutes, reducing human error and ensuring environment parity between Development, Staging, and Production.

Project Architecture

The architecture follows a multi-tier approach to ensure high availability and security:

  • Public Layer: Application Load Balancer (ALB) distributed across multiple Availability Zones with EC2 instances.
  • Database Layer: RDS MySQL instances placed in private subnets, inaccessible from the public internet.
  • Storage Layer: S3 buckets for centralized logging and static backups.
[User] -> [Internet Gateway] -> [ALB] -> [EC2 Instances] -> [RDS Database]

Technologies Used

  • Terraform: Core orchestration tool.
  • AWS: Provider for compute (EC2), networking (VPC), and database (RDS) services.
  • GitHub: Version control system.
  • Jenkins: CI/CD engine for triggering 'terraform apply' on code merge.
  • S3 & DynamoDB: Backend storage for state files and distributed locking mechanism.

Directory Structure


terraform-aws-project/
├── provider.tf        # AWS Provider configuration
├── backend.tf         # S3/DynamoDB remote state
├── main.tf            # Root resource declaration
├── variables.tf       # Global variables
├── outputs.tf         # Infrastructure export data
├── modules/           # Reusable components
│   ├── vpc/           # VPC, Subnet, Route Table definitions
│   ├── ec2/           # Auto-scaling or Instance logic
│   ├── security/      # Security Groups & IAM roles
│   └── database/      # RDS configuration
└── README.md          # Project documentation
        

Configure AWS Provider


provider "aws" {
  region = var.region
  shared_credentials_files = ["~/.aws/credentials"]
}
        

Configure Remote Backend

Remote backends are critical for teams to prevent state corruption.


terraform {
  backend "s3" {
    bucket         = "my-tf-state-bucket"
    key            = "prod/terraform.tfstate"
    region         = "us-east-1"
    dynamodb_table = "terraform-lock"
  }
}
        

Create VPC Module

Networking forms the foundation. We define CIDR blocks, public and private subnets, and link them to an Internet Gateway.

Create Security Groups

Strict access control: EC2 only accepts port 80/443 from the ALB, and RDS only accepts traffic from EC2 on port 3306.

Provision EC2 Instances


resource "aws_instance" "web_server" {
  ami           = "ami-0cff7528ff583bf9a"
  instance_type = "t3.micro"
  tags = { Name = "Terraform-Web-Server" }
}
        

Configure Load Balancer

Sets up an Application Load Balancer (ALB) with a target group to balance incoming traffic across multiple EC2 instances.

Create Database

RDS instance setup with Multi-AZ deployment for high availability, including encrypted storage configurations.

Create S3 Storage

Buckets are created with 'private' ACLs, enabling versioning to prevent accidental data deletion.

Variables

Using variables.tf allows us to change environment-specific settings (like instance size) without touching the actual code.

Outputs

Essential for CI/CD, such as exporting the Load Balancer DNS name so the pipeline can verify the deployment URL.

Deployment Steps

  1. Initialization: terraform init
  2. Planning: terraform plan (verify resource changes)
  3. Apply: terraform apply -auto-approve

CI/CD Automation

Automating deployment via Jenkins ensures that every time a developer pushes to the main branch, the infrastructure updates automatically.

Jenkins Pipeline


pipeline {
    stage('Terraform Apply') {
        sh 'terraform init && terraform apply -auto-approve'
    }
}
        

Security Best Practices

  • Never commit terraform.tfvars to Git.
  • Use AWS Secrets Manager for RDS passwords.
  • Always implement State Locking using DynamoDB.

Deliverables & Skills

Deliverables: Full production-ready AWS environment.

Skills Gained: Infrastructure as Code, AWS cloud security, CI/CD pipeline integration, and modular programming in HCL.

Terraform Interview Questions & Answers

Part 1: Terraform Fundamentals (Q1–Q10)

Q1. What is Terraform?

Terraform is an open-source Infrastructure as Code (IaC) tool developed by HashiCorp that allows users to provision and manage infrastructure using configuration files.

Q2. What is Infrastructure as Code (IaC)?

IaC is the practice of managing infrastructure using code instead of manual processes. It enables automated, repeatable, and consistent infrastructure deployments.

Q3. Why is Terraform used?

Terraform is used to automate the creation and management of cloud resources such as servers, networks, databases, storage, and Kubernetes clusters.

Q4. What language does Terraform use?

Terraform uses HashiCorp Configuration Language (HCL).

resource "aws_instance" "web" {
  instance_type = "t2.micro"
}
Q5. Who developed Terraform?

Terraform was developed by HashiCorp.

Q6. Is Terraform cloud-specific?

No. Terraform is platform-agnostic and supports multiple cloud providers, including AWS, Azure, Google Cloud, Kubernetes, VMware, and many others.

Q7. What are the benefits of Terraform?
  • Infrastructure automation
  • Version control support
  • Multi-cloud platform support
  • Faster deployments
  • Reduced human errors
  • Reusable infrastructure code
Q8. What is the Terraform configuration file extension?

Terraform configuration files use the .tf extension (e.g., main.tf, variables.tf, outputs.tf).

Q9. What is HCL?

HCL (HashiCorp Configuration Language) is the declarative language used by Terraform to define infrastructure in a human-readable format.

Q10. What is Terraform CLI?

Terraform CLI is a command-line tool used to execute core operations, such as:

  • terraform init
  • terraform plan
  • terraform apply

Part 2: Architecture & Commands (Q11–Q25)

Q11. Explain Terraform architecture.

Terraform architecture consists of four main parts: Terraform Core, Providers, Configuration Files, and State File.

Workflow: Terraform Code → Terraform Core → Provider API → Cloud Resources.

Q12. What is Terraform Core?

Terraform Core is the engine responsible for reading configuration files, creating execution plans, and managing the state file.

Q13. What are Terraform Providers?

Providers are plugins that allow Terraform to communicate with external platforms. Examples include: AWS Provider, Azure Provider, and Kubernetes Provider.

Q14. What is a Terraform Resource?

A resource represents infrastructure components managed by Terraform, such as an EC2 Instance, S3 Bucket, VPC, or Database.

Q15. What is a Terraform Data Source?

A data source allows Terraform to retrieve and use information about infrastructure that exists outside of the current Terraform configuration.

Q16. What does terraform init do?

It initializes a new or existing Terraform working directory, downloads required provider plugins, and sets up the backend.

Q17. What does terraform plan do?

It creates an execution plan, allowing you to preview the changes Terraform will make (create, update, or destroy) before applying them.

Q18. What does terraform apply do?

It applies the Terraform configuration to reach the desired state, effectively creating or updating the actual infrastructure resources.

Q19. What does terraform destroy do?

It removes all the infrastructure managed by your current Terraform configuration.

Q20. What does terraform validate do?

It checks the configuration files in a directory for syntax errors and consistency.

Q21. What does terraform fmt do?

It automatically rewrites configuration files to a canonical format and style (code formatting).

Q22. What does terraform output do?

It displays the values of variables defined in the outputs.tf file after a deployment.

Q23. What does terraform version do?

It displays the currently installed version of the Terraform CLI.

Q24. What does terraform show do?

It provides a human-readable output from a state file or an execution plan.

Q25. What does terraform refresh do?

It updates the Terraform state file with the current real-world infrastructure information, ensuring the state matches the actual resources.

Part 3: State Management (Q26–Q35)

Q26. What is Terraform State?

Terraform State is a mechanism that stores information about your managed infrastructure. By default, it is saved in a file named terraform.tfstate.

Q27. Why does Terraform need state?

Terraform uses state to track your deployed resources, map them to your configuration, and determine exactly what changes are required during the next execution.

Q28. Where is Terraform state stored?

By default, it is stored on the local machine. For production, it is recommended to use a Remote Backend such as AWS S3, Azure Storage, or Terraform Cloud.

Q29. What is terraform.tfstate?

It is a JSON-formatted file that contains the current state of all infrastructure components managed by a specific Terraform configuration.

Q30. What is Remote Backend?

A Remote Backend stores the state file remotely rather than locally, which is essential for team collaboration, consistency, and security.

Q31. What is S3 Backend?

S3 Backend is a configuration where the state file is automatically uploaded to and retrieved from an AWS S3 bucket.

Q32. Why use DynamoDB with Terraform?

DynamoDB is used in conjunction with S3 to provide state locking, which prevents multiple users from running Terraform operations at the exact same time, avoiding state corruption.

Q33. What is Terraform State Locking?

State Locking is a safety feature that prevents multiple users from modifying infrastructure simultaneously, ensuring that only one person can apply changes at a time.

Q34. How do you list Terraform resources?

Command: terraform state list

Q35. How do you remove a resource from state?

Command: terraform state rm RESOURCE_NAME

Note: This command removes the item from the state file, but it does not actually destroy the physical resource.

Part 4: Variables, Outputs, and Modules (Q36–Q52)

Q36. What are Terraform Variables?

Variables allow you to pass dynamic values into your Terraform configurations, making them flexible.

Q37. Why use variables?
  • Code reusability
  • Environment flexibility (Dev/Staging/Prod)
  • Avoid hardcoding sensitive values
Q38. Where are variables defined?

They are usually defined in a file named variables.tf.

Q39. How do you reference a variable?

You use the syntax: var.variable_name

Q40. What are Terraform variable types?

Common types include: String, Number, Boolean, List, Map, and Object.

Q41. What is terraform.tfvars?

This is a file used to provide specific values for your defined variables (e.g., region = "us-east-1").

Q42. What are sensitive variables?

These are variables containing secrets like passwords or API keys, marked with sensitive = true to prevent them from showing in logs.

Q43. How do you pass variables from CLI?

Command: terraform apply -var="region=us-east-1"

Q44. What are Terraform Outputs?

Outputs display important information (like IP addresses, DNS names, or Resource IDs) after infrastructure is deployed.

Q45. Where are outputs defined?

Outputs are defined in an outputs.tf file.

Q46. How do you define an output?
output "ip" {
  value = aws_instance.web.public_ip
}
Q47. What is a Terraform Module?

A module is a reusable collection of related Terraform configuration files that perform a specific task.

Q48. Why use modules?

They provide reusability, organization, standardization, and easier maintenance of code.

Q49. What is a Root Module?

It is the main Terraform configuration directory from which your commands (init, plan, apply) are executed.

Q50. What is a Child Module?

A child module is a smaller, reusable module that is called (referenced) by the Root Module or another module.

Q51. Where are Terraform modules stored?

Modules are typically stored in a local directory (e.g., /modules) or imported from the Terraform Registry.

Q52. What is Terraform Registry?

It is a public, official repository containing thousands of reusable Terraform modules created by the community and cloud providers.

Part 5: AWS, Workspaces, and Advanced Topics (Q53–Q70)

Q53. How does Terraform connect with AWS?

Terraform connects with AWS through the AWS Provider.

Q54. Example AWS provider configuration?
provider "aws" {
  region = "us-east-1"
}
Q55. How does Terraform authenticate with AWS?

Authentication methods include: AWS CLI credentials, Environment variables, and IAM Roles.

Q56. What AWS resources can Terraform manage?

Terraform can manage virtually all AWS resources, including EC2, VPC, S3, RDS, IAM, Lambda, and Load Balancers.

Q57. What are Terraform Workspaces?

Workspaces allow you to manage multiple environments (like Dev, Staging, Prod) using the exact same Terraform configuration code.

Q58. Why use workspaces?

They provide environment separation, separate state files for each environment, and maximize code reuse.

Q59. Create workspace command?

Command: terraform workspace new dev

Q60. List workspaces?

Command: terraform workspace list

Q61. Switch workspace?

Command: terraform workspace select prod

Q62. What is Terraform Dependency?

Dependencies define the order and relationship between resources (e.g., a VPC must be created before a Subnet).

Q63. What is implicit dependency?

Terraform automatically detects dependencies when you reference one resource's attribute inside another (e.g., passing a VPC ID to a subnet).

Q64. What is explicit dependency?

A dependency manually defined by the user in the code using the depends_on argument.

Q65. What is Terraform lifecycle block?

It controls resource behavior during updates (e.g., prevent_destroy = true).

Q66. What is count in Terraform?

It creates multiple copies of a resource based on a numeric value (e.g., count = 3).

Q67. What is for_each?

It creates multiple resources by iterating over a map or a set of strings, providing more flexibility than count.

Q68. Difference between count and for_each?

count uses numeric indices for simple copies. for_each uses unique keys, making it better for unique resources.

Q69. What is Terraform Import?

It brings existing infrastructure that was created manually into Terraform management. Command: terraform import [RESOURCE] [ID]

Q70. What is Terraform Graph?

It generates a visual representation of your resource dependencies. Command: terraform graph

Part 5: Security & CI/CD (Q71–Q80)

Q71. How do you secure Terraform state?
  • Encryption (at rest)
  • Strict IAM permissions
  • Remote backend storage
  • Access control lists (ACLs)
Q72. Should Terraform state be stored in Git?

No. State files often contain sensitive information, plain-text secrets, and resource IDs that pose a security risk if committed to Git.

Q73. How do you manage secrets in Terraform?

Use secure secret management solutions such as:

  • AWS Secrets Manager
  • HashiCorp Vault
  • Sensitive Environment variables
Q74. What is Terraform Vault integration?

It is a feature that allows Terraform to dynamically retrieve secrets and credentials directly from HashiCorp Vault during the execution phase.

Q75. How Terraform integrates with Jenkins?

Terraform integrates into a CI/CD pipeline typically as follows:
GitHub → Jenkins → Terraform Plan → Terraform Apply → Infrastructure

Q76. Can Terraform run in GitHub Actions?

Yes, Terraform can be fully automated within GitHub Actions using workflows to trigger plan and apply commands on push or pull requests.

Q77. What is Terraform Automation?

It refers to the practice of using CI/CD pipelines to automatically deploy, update, and destroy infrastructure without manual CLI intervention.

Q78. What is Terraform Drift?

Drift occurs when the actual infrastructure resources in the cloud change due to manual intervention or processes outside of Terraform's control.

Q79. How to detect drift?

Command: terraform plan
Terraform will highlight the differences between the current state and the actual cloud resources.

Q80. How to fix drift?
  • Update your Terraform code to match the manual changes.
  • Run terraform apply to synchronize.
  • Alternatively, use terraform import to bring drifted resources back into state management.

Part 6: Best Practices & Real-World Use Cases (Q81–Q90)

Q81. Store Terraform code in Git?

Yes. Storing code in Git provides essential version control, collaboration, and history tracking for your infrastructure.

Q82. Use modules?

Yes. Modules significantly improve code reusability, organization, and scalability of complex infrastructure.

Q83. Use remote state?

Yes. Remote state is mandatory for teams to avoid state file conflicts and ensure consistency across deployments.

Q84. Use provider version locking?

Yes. Using required_providers with version constraints prevents unexpected breaking changes when new provider versions are released.

Q85. Separate environments?

Yes. Always separate environments (Dev, Staging, Prod) using distinct workspaces or separate directory structures to minimize blast radius.

Q86. Can Terraform create Kubernetes clusters?

Yes. Terraform can provision managed K8s clusters (EKS, GKE, AKS) and manage K8s objects via the Kubernetes Provider.

Q87. Can Terraform manage Docker containers?

Yes. Terraform can manage Docker containers, images, and networks using the dedicated Docker Provider.

Q88. Can Terraform manage multiple clouds?

Yes. Terraform is platform-agnostic, allowing you to manage resources across AWS, Azure, GCP, and others simultaneously.

Q89. Can Terraform install software?

Terraform is primarily for provisioning infrastructure. For software installation and configuration inside VMs, tools like Ansible are the standard choice.

Q90. Terraform vs Ansible?
Feature Terraform Ansible
Primary Use Infrastructure Provisioning Configuration Management
Function Creates servers/resources Configures servers/software

Part 7: Final Concepts & Learning Path (Q91–Q100)

Q91. Terraform vs CloudFormation?

Terraform: Multi-cloud support and uses HCL (HashiCorp Configuration Language).
CloudFormation: AWS-only service and uses YAML/JSON templates.

Q92. What is Terraform Cloud?

A managed service platform by HashiCorp designed for team collaboration, state management, and CI/CD automation.

Q93. What is Terraform Enterprise?

The self-hosted or SaaS enterprise version of Terraform, featuring advanced security, governance, and audit capabilities.

Q94. What is Terraform Provider Registry?

The official public repository where you can find and download all supported Terraform provider plugins.

Q95. What is a Terraform Plugin?

A plugin is an external component that extends Terraform's functionality, allowing it to interact with specific cloud providers or services.

Q96. What is a Terraform Plan File?

A saved execution plan created with terraform plan -out=filename, ensuring that exactly what you planned is what gets applied.

Q97. What is Terraform Apply with Plan File?

Executing terraform apply filename uses your saved plan, ensuring no changes occur between your plan and apply steps.

Q98. What is Infrastructure Provisioning?

The automated process of creating and configuring cloud resources like servers, networks, storage, and databases.

Q99. What is Terraform's role in DevOps?

It automates infrastructure deployment, enabling Infrastructure as Code (IaC) and supporting consistent CI/CD workflows.

Q100. Why is Terraform important for DevOps Engineers?

It enables automated, repeatable, scalable, and secure cloud management, making it a foundational skill for modern DevOps.


Terraform Learning Path

  • Terraform Installation
  • HCL Language Mastery
  • Providers & Resources
  • Variables & Outputs
  • State Management & Remote Backends
  • Modules & Workspaces
  • AWS Infrastructure Projects
  • Terraform + Jenkins CI/CD
  • Production Best Practices