DEV Community: ankitgadling

Day 9 - Protect resources from accidental deletion.

ankitgadling — Wed, 10 Dec 2025 17:08:19 +0000

Managing resources using Terraform, we sometimes need to protect our resources from accidental deletion.

This is our day 9 of learning Terraform with AWS. Whenever we are managing resources using Terraform, we can destroy all the resources with a single command (terraform destroy). However, there are certain resources we do not want to delete such as databases or S3 buckets with important data.

To protect these resources, Terraform provides lifecycle meta-arguments.

Let’s see how it works

Example 1: Preventing downtime - `create_before_destroy`

Consider you want to deploy an API on EC2 instances that sit behind a load balancer.
If you destroy the resource, the API will face downtime until a new instance is created again. This can cause business loss, and users may lose trust if it happens frequently.

To prevent downtime, we can use the lifecycle meta-argument create_before_destroy, which tells Terraform to create a new resource before destroying the old one.

Example:

resource "aws_instance" "api_server" {
  ami           = "ami-12345678"
  instance_type = "t3.micro"

  lifecycle {
    create_before_destroy = true
  }
}

Example 2: Protecting critical resources - `prevent_destroy`

Now consider a requirement to store compliance-related documents. You create an S3 bucket for this purpose.
If this S3 bucket gets destroyed, all compliance documents will be lost.

To avoid this, Terraform provides the prevent_destroy argument.

Example:

resource "aws_s3_bucket" "compliance_docs" {
  bucket = "my-compliance-docs-bucket"

  lifecycle {
    prevent_destroy = true
  }
}

Example 3: Ignoring externally managed changes - `ignore_changes`

Suppose your API experiences a sudden spike and you rely on autoscaling policies.
If an Auto Scaling Group is created using Terraform with a default capacity, Terraform may later try to override changes made automatically by scaling policies. This can cause API performance issues.

To prevent this, we tell Terraform that the capacity is managed outside Terraform, and it should ignore changes to that attribute. For this, we use ignore_changes.

Example:

resource "aws_autoscaling_group" "api_asg" {
  name             = "api-asg"
  min_size         = 2
  max_size         = 10
  desired_capacity = 2

  lifecycle {
    ignore_changes = [desired_capacity]
  }
}

Example 4: Triggering replacement on dependency changes - `replace_triggered_by`

Terraform also provides replace_triggered_by in lifecycle meta-arguments, which is useful when you want to replace a resource when something else changes.

Example:

resource "aws_instance" "app_server" {
  ami           = "ami-12345678"
  instance_type = var.instance_type

  lifecycle {
    replace_triggered_by = [
      var.instance_type,
      aws_security_group.app_sg.id
    ]
  }
}

Example 5: Validating input and output - `precondition` and `postcondition`

There are cases where we must validate inputs (like regions or environment constraints) or outputs (such as resource attributes after deployment).
To handle these scenarios, Terraform provides precondition and postcondition.

Example:

resource "aws_s3_bucket" "logs" {
  bucket = var.bucket_name

  lifecycle {
    precondition {
      condition     = length(var.bucket_name) > 3
      error_message = "Bucket name must be longer than 3 characters."
    }

    postcondition {
      condition     = self.versioning[0].enabled == true
      error_message = "Versioning must be enabled for this bucket."
    }
  }
}

Day 8 - Terraform Meta-Arguments

ankitgadling — Tue, 09 Dec 2025 17:51:57 +0000

Whenever we create any resource using Terraform, whether it is an S3 bucket, an EC2 instance, or a security group, we have to pass certain arguments that are specific to the provider. For example, while creating an AWS S3 bucket, we must provide a bucket name, which is a provider-specific argument. Along with these arguments, Terraform also provides additional arguments that work across all resource types. These are known as meta-arguments. Meta-arguments allow us to add extra functionality on top of the normal provider arguments, such as creating multiple resources, controlling dependencies, or defining lifecycle rules.

Common Terraform Meta-Arguments

Some of the most commonly used meta-arguments are:

count - With the help of count we can create multiple instances of the same resource.
for_each - Allows you to create multiple resources based on a map or set, giving more flexibility than count.
depends_on - It is used to define explicit dependency between resources.
provider - Overrides which provider configuration to use for a particular resource.
lifecycle - It helps in controlling resource behavior, like preventing deletion or ignoring certain changes.

How Meta-Arguments Help in Real Projects

Let us consider a situation where we need to launch EC2 instances for testing, staging, and production environments. Instead of writing the same resource block multiple times, meta-arguments allow us to dynamically control how many EC2 instances to create.

Example Using count

variable "ec2_count" {
  default = 3
}

resource "aws_instance" "my_ec2" {
  count         = var.ec2_count
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"

  tags = {
    Name = "EC2-${count.index}"
  }
}

What happens here?

If ec2_count = 3, Terraform creates 3 EC2 instances.
If tomorrow you want 5 instances, just change the variable. There is no need to modify the resource block.

This is very helpful in environments where:

The number of servers may change frequently
Teams want to scale infrastructure quickly
We need to replicate identical resources, for example security groups, IAM users, or EC2 instances

Example Using for_each

Suppose we want to create EC2 instances with different names or configurations.

variable "servers" {
  default = {
    app  = "t2.micro"
    db   = "t2.small"
    cache = "t2.micro"
  }
}

resource "aws_instance" "server" {
  for_each      = var.servers
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = each.value

  tags = {
    Name = each.key
  }
}

This creates three EC2 instances with different roles and instance types without repeating any code.

Example Using depends_on

Sometimes Terraform automatically understands the order in which resources should be created based on references. However, there are situations where we need to manually define the dependency to ensure one resource is created before another.

Scenario

Suppose we want to create an EC2 instance, but only after a security group is fully created.

resource "aws_security_group" "ec2_sg" {
  name        = "ec2-security-group"
  description = "Allow SSH"

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

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

  depends_on = [
    aws_security_group.ec2_sg
  ]

  tags = {
    Name = "EC2-with-depends-on"
  }
}

Why is depends_on useful?

Ensures Terraform creates resources in the correct order
Helps avoid runtime failures, for example EC2 launching before its security group exists
Useful when resources do not have a direct reference but still require ordering
Makes execution predictable and safer

Why Meta-Arguments Are Important

In real projects, meta-arguments help:

Reduce code duplication
Improve scalability, making it easy to increase or decrease the number of resources
Keep infrastructure DRY (Do Not Repeat Yourself)
Provide flexible configurations
Control resource behavior more effectively

Meta-arguments are one of the most powerful features in Terraform and they help make infrastructure more modular, maintainable, and scalable.

Day 7 – Type Constraints in Terraform

ankitgadling — Sun, 07 Dec 2025 17:45:31 +0000

On day 5 we have seen the variables in action. Today we will be doing a deep dive into type constraints in Terraform. A Terraform variable has certain types: primitive, complex, and special. We will start with primitive first.

1. Primitive Types

The word itself explains this type. Primitive means the basic ones, which include string, number, and bool.

String

It can have any text value.
Example:

variable "name" {
  type = string
  default = "Terraform"
}

Number

Numeric values integers as well as floats.
Example:

variable "age" {
  type = number
  default = 25
}

Bool

Boolean value (true/false).
Example:

variable "is_enabled" {
  type = bool
  default = true
}

2. Complex Types

Complex types are types that allow you to group multiple values.

List

Its an ordered collection of values of the same type.

variable "instance_ids" {
  type = list(string)
}

Set

Its a collection of unique values, also of the same type, but order does not matter.

variable "unique_tags" {
  type = set(string)
}

Tuple

Its an ordered collection of values of different types.

variable "my_tuple" {
  type = tuple([string, number, bool])
}

Map

Its a set of string keys with values of the same type.

variable "region_mapping" {
  type = map(string)
}

Object

Its a collection of attributes with different types, similar to a struct.

variable "server_config" {
  type = object({
    name = string
    cpu  = number
    prod = bool
  })
}

3. Special Types

Any

Allows any data type Terraform will accept whatever is provided.
Useful for flexible modules. We should avoid using it.

variable "input" {
  type = any
}

Null

It represents the absence of a value and is often used to trigger default behavior.

Example:

variable "instance_type" {
  default = null
}

Terraform will use the default from the provider/resource when null is passed.

How These Types Help in Real Terraform Projects

Strings for Naming Resources

variable "environment" {
  type    = string
  default = "dev"
}

resource "aws_s3_bucket" "example" {
  bucket = "${var.environment}-app-data"
}

Change environment once → everything updates.

Numbers for Scaling Resources

variable "instance_count" {
  type    = number
  default = 3
}

resource "aws_instance" "server" {
  count = var.instance_count
  ami   = "ami-123"
  instance_type = "t2.micro"
}

Increase the number → Terraform creates more servers.

Booleans for Feature Toggles

variable "monitoring_enabled" {
  type    = bool
  default = true
}

resource "aws_instance" "server" {
  monitoring = var.monitoring_enabled
}

Turn monitoring on/off with a single variable.

Lists for Repeating Resources

variable "availability_zones" {
  type    = list(string)
  default = ["us-east-1a", "us-east-1b"]
}

resource "aws_subnet" "subnet" {
  count = length(var.availability_zones)
  az    = var.availability_zones[count.index]
  cidr_block = "10.0.${count.index}.0/24"
}

Subnets automatically created across multiple AZs.

Maps for Centralized Tagging

variable "tags" {
  type = map(string)
  default = {
    Environment = "dev"
    Owner       = "teamA"
  }
}

resource "aws_vpc" "main" {
  tags = var.tags
}

Manage all tags from one place.

Objects for Clean, Structured Config

variable "config" {
  type = object({
    region         = string
    monitoring     = bool
    instance_count = number
  })

  default = {
    region         = "us-east-1"
    monitoring     = true
    instance_count = 2
  }
}

provider "aws" {
  region = var.config.region
}

for more information checkout
https://github.com/ankitgadling/terraformwithaws/tree/main/day_7

Day 6 - Terraform Project Structure Best Practices

ankitgadling — Thu, 04 Dec 2025 17:46:10 +0000

As I continue my Terraform with AWS learning journey, today’s focus was on one of the most underrated yet extremely important topics: how to properly structure a Terraform project. When you're getting started, it’s tempting to put all your .tf files in a single folder and just make things “work.” And yes Terraform will still run. But as your infrastructure grows, poor structure quickly leads to chaos.

On Day 6, I learned why project structure matters, the problems you face when you don’t manage it well, and the best practices recommended by Terraform to build clean, scalable, and maintainable infrastructure from day one.

Why Project Structure Matters in Terraform

Terraform is declarative and modular by design. Its power becomes clear when you start organizing infrastructure into reusable components, separating environments, and keeping configuration clean. Without a proper structure, your project becomes difficult to understand, debug, and scale.

Cons of Not Having a Proper Terraform Project Structure

1. Hard to Maintain and Scale

If everything sits in one directory, adding new components becomes painful. Small projects might survive a messy layout, but as soon as you expand add more VPCs, subnets, or services you’ll struggle to keep track of what belongs where.

2. Increased Risk of Mistakes

A single misplaced variable or resource can affect your entire infrastructure. Without structure, you may accidentally update or destroy resources you didn’t intend to. Clear separation of modules and environments helps minimize such risks.

3. Poor Collaboration

When working in a team, a disorganized Terraform setup creates confusion. Developers may overwrite each other's changes, misinterpret variable usage, or struggle to locate specific components.

4. Difficult Troubleshooting

When Terraform state gets large and your files aren’t organized, troubleshooting becomes time-consuming. Clear file boundaries allow you to isolate issues faster.

5. Reusability Drops

One of Terraform’s strengths is the ability to build reusable modules. Without structure, creating modules later becomes harder and requires refactoring.

Best Practices Recommended by Terraform

HashiCorp provides guidelines and patterns to help you build a scalable Terraform setup from the beginning. Here are the key practices I learned today.

1. Separate Environments

Use folders to separate dev, staging, and production. Each environment can have its own variables and backend configuration.

Example:

env/
   dev/
   staging/
   prod/

This prevents accidental changes to production and provides clear isolation.

2. Maintain a Clear File Layout

A standard Terraform directory commonly includes:

main.tf – core resources
variables.tf – all input variables
outputs.tf – outputs from your configuration
providers.tf – provider configuration
terraform.tfvars – environment-specific variable values

This makes onboarding easier because anyone can quickly understand where everything goes.

3. Follow Naming Conventions

Consistent names make navigation easier. For example, naming resources like app_vpc or demo_s3_bucket helps avoid confusion between different stacks.

4. Keep Secrets Out of Your Code

Use environment variables, AWS Secrets Manager, or Terraform Cloud variables. Never hard-code secrets inside .tfvars or .tf files.

Conclusion

Day 6 taught me that Terraform isn’t just about writing resources it’s about writing clean and organized infrastructure code. A well structured project saves time, reduces mistakes, improves collaboration, and allows you to scale with confidence. Setting up the right structure early is one of the best long term investments you can make in your infrastructure-as-code journey.

Day 5 - Terraform Variables

ankitgadling — Wed, 03 Dec 2025 17:13:14 +0000

Before exploring Terraform variables, let’s first understand what variables are.

A variable is simply something whose value can change. Variables are used to avoid hardcoding, improve reusability, enhance readability, and support modular design. Every programming language uses variables and Terraform is no different.

Terraform also supports variables, and they can be categorized in two ways:

Based on purpose
Based on value

1. Input Variables

Used to pass values into Terraform from users or external sources.

Example:

variable "region" {
  type        = string
  default     = "us-east-1"
  description = "AWS region"
}

2. Output Variables

Used to display or export values after terraform apply.

Example:

output "bucket_name" {
  value = aws_s3_bucket.demo.bucket
}

3. Local Values (locals)

Used to simplify complex or repeated expressions.

Example:

locals {
  env_name = "dev"
}

String Concatenation in Terraform

"${var.env}-bucket"

"${var.env}-bucket-${var.region}"

Terraform Variable Precedence

Terraform loads variables in the following order (LOW to HIGH precedence):

Precedence	Source	Notes
1	Default values in variables.tf	lowest priority
2	Environment variables	export TF_VAR_region="us-east-1"
3	terraform.tfvars	auto-loaded
4	terraform.tfvars.json	auto-loaded
5	*.auto.tfvars / .auto.tfvars.json*	auto-loaded in alphabetical order
6	-var and -var-file CLI flags	highest priority

Example Environment Variable

export TF_VAR_env="dev"

✔ Example CLI Variable

terraform apply -var="env=dev"

✔ Example CLI Var File

terraform apply -var-file="dev.tfvars"

Example: Creating an S3 Bucket Using env = dev

variables.tf

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

variable "region" {
  type    = string
  default = "us-east-1"
}

main.tf

provider "aws" {
  region = var.region
}

resource "aws_s3_bucket" "demo" {
  bucket = "${var.env}-bucket-demo"
}

output "bucket_name" {
  value = aws_s3_bucket.demo.bucket
}

terraform.tfvars (optional)

env = "dev"

Run Commands

terraform init
terraform plan
terraform apply

Resulting Bucket Name

dev-bucket-demo

Day 4 - Terraform State File Management with Remote Backends (S3 Native Locking)

ankitgadling — Thu, 27 Nov 2025 16:42:59 +0000

Terraform relies on a state file to understand the infrastructure it manages. Instead of constantly querying cloud providers which is slow, expensive, and inefficient Terraform stores the current state of your resources locally or remotely. This file acts as Terraform’s “source of truth,” enabling it to detect changes, manage dependencies, and apply updates safely.

What Is a Terraform State File?

Terraform’s state file records the attributes and relationships of your deployed resources. It allows Terraform to:

Compare desired configuration vs. actual infrastructure
Generate accurate execution plans
Track dependencies between resources
Enable collaboration across teams

Because Terraform relies heavily on this file, keeping it secure and consistent is critical.

State File Best Practices

To avoid corruption, security risks, or inconsistent deployments:

Never edit the state file manually
Use remote storage instead of local files
Enable state locking
Back up regularly
Use separate state files per environment
Restrict state file access
Encrypt in transit and at rest

These practices ensure your infrastructure remains predictable and stable.

Why Store State Files Remotely?

Remote backends like AWS S3 provide several advantages:

Collaboration: Team members share one state source
Locking: Prevents simultaneous modifications
Security: IAM, encryption, and access controls
Versioning: Easy rollback and recovery
High availability: Durable and reliable storage

Local state works for learning, but teams need the reliability of remote backends.

AWS Remote Backend Overview

A typical Terraform remote backend in AWS includes:

S3 Bucket - to store state files
S3 Native State Locking - available in Terraform 1.10+
IAM Policies - to control read/write access

Previously, DynamoDB tables were required for locking. Now, Terraform can use S3 alone.

S3 Native State Locking (Terraform 1.10+)

Terraform 1.10 introduced S3-native state locking, using AWS S3’s Conditional Writes (If-None-Match). This allows Terraform to manage lock files directly in S3.

How It Works

Terraform tries to create a lock file in S3.
If the lock file already exists, S3 rejects the request.
If not, Terraform acquires the lock.
When the operation finishes, the lock file is deleted.

This ensures only one Terraform operation can modify the state at a time.

Why Locking Prevents State Corruption

Without locking, two engineers could run terraform apply simultaneously, causing:

Corrupted state
Duplicate resources
Missing infrastructure
Unpredictable environments

With S3 native locking:

Only one operation proceeds
Others are blocked with a “state is locked” message
State remains consistent and protected

Day 3 - Create an AWS S3 Bucket Using Terraform

ankitgadling — Wed, 26 Nov 2025 17:35:45 +0000

What is an S3 bucket?

An Amazon S3 bucket is a scalable object storage container used to store files (objects) such as backups, logs, images, and static website assets. Each bucket has a globally unique name and can be configured with lifecycle policies, access controls, encryption, and versioning.

When to use

Durable object storage for static content, backups, and artifacts.
Hosting static websites.
Centralized storage for application logs or data.
Remote Terraform state backends (when combined with locking).

Prerequisites

AWS account and appropriate IAM credentials.
AWS CLI configured (or environment variables AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY).
Terraform installed.

Tips & best practices

Bucket names must be globally unique - include a random suffix or org/project prefix.
Enable encryption (SSE) and versioning for important data.
Block public access unless intentionally hosting public assets.

How to Create a VPC, S3 Bucket, and Implicit Dependency Using Terraform

Step 1: Install Terraform

Download and install Terraform from the official website:
https://developer.hashicorp.com/terraform/downloads

Step 2: Configure AWS Credentials

Install and configure AWS CLI:

aws configure

Provide your:

AWS Access Key
AWS Secret Key
AWS Region

* Output format

Step 3: Create `main.tf` File

Create a folder and inside it create a file named main.tf with the following content:

terraform {
  required_version = ">= 1.0"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

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

resource "aws_vpc" "main" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_support   = true
  enable_dns_hostnames = true

  tags = {
    Name = "example-vpc"
  }
}

resource "aws_s3_bucket" "example" {
  bucket = "example-bucket-${aws_vpc.main.id}"

  tags = {
    Name = "example-bucket"
    VPC  = aws_vpc.main.id
  }
}

Step 4: Initialize Terraform and Validate the Terraform Configuration

Run:

terraform init

This downloads the AWS provider and prepares the working directory.

Run:

terraform validate

This checks for syntax or configuration errors.

Step 5: Plan the Terraform Changes

Run:

terraform plan

This shows what resources Terraform will create.

Step 6: Apply the Changes

Run:

terraform apply

Type yes when prompted.

Step 7: Destroy the Resources

When you are done, run:

terraform destroy

Type yes to confirm.

Day 2 - Terraform AWS Provider

ankitgadling — Tue, 25 Nov 2025 16:23:42 +0000

What is a provider?

A provider is a plugin that enables Terraform to manage resources from a specific cloud or service. It translates Terraform configuration (HCL) into API calls the provider understands. Providers are the bridge between Terraform and target platforms such as cloud providers, SaaS products, and other services.

Providers can be:

Official (aws, gcp, azure, kubernetes)
Partner
Community

Importance of versions

Versioning matters. Terraform itself and providers evolve continuously new features, bug fixes, and breaking changes are common. Specifying and pinning provider and Terraform versions ensures consistent behavior across environments and prevents unexpected breakages. Use the terraform block's required_providers and required_version settings and rely on the provider lock file (terraform.lock.hcl) to maintain reproducible runs.

Overview of the Terraform AWS Provider

The Terraform AWS Provider allows Terraform to create, read, update, and delete AWS resources by converting HCL to AWS API requests. It covers a wide range of services (EC2, S3, VPC, IAM, RDS, Lambda, CloudWatch, and many more) and supports data sources, resource arguments, and lifecycle options.

Key points:

Authentication: supports shared credentials (~/.aws/credentials), environment variables, profiles, STS assume role, EC2/ECS task roles, and SSO.
Configuration: region, profile, access keys, assume_role, endpoints, and aliases for multiple providers/accounts/regions.
Best practices: pin provider versions, use state locking/backends, split environments or accounts with workspaces or multiple providers, and test changes in non-production first.

Example (minimal):

terraform {
    required_providers {
        aws = {
            source  = "hashicorp/aws"
            version = "~> 4.0"
        }
    }
    required_version = ">= 1.0.0"
}

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

Resources

Day 1 - Introduction to Infrastructure as Code (IaC)

ankitgadling — Mon, 24 Nov 2025 17:05:05 +0000

Why IaC is needed

When you do big or repetitive tasks by hand, it’s easy to mess something up or forget a step. IaC helps by letting you write your infrastructure as code, so everything is repeatable, automated, and way less error-prone. Plus, it saves money because you can create resources only when you need them and delete them right after.
Example: A developer can run a single command to build a temporary AWS environment for a demo, and remove it as soon as the demo ends so no charges keep adding up.

Common IaC Tools

Terraform (HashiCorp)
AWS CloudFormation
Pulumi

What is Terraform?

Terraform is an open-source Infrastructure as Code (IaC) tool that allows you to define, preview, and apply infrastructure changes across many different cloud and on-prem providers. It lets teams manage resources using configuration files instead of manual steps.

HashiCorp Configuration Language (HCL)

Terraform uses HCL, a human-friendly configuration language that:

Looks similar to JSON but has its own cleaner syntax
Is designed to be easy to read and write
Supports variables, modules, and expressions

How Terraform Works (High-Level Overview)

Write configuration files (.tf) to describe the infrastructure you want (e.g., VMs, networks, storage).
Run terraform init Initializes the working directory, downloads required providers and modules.
Run terraform plan Shows the changes Terraform will perform creating, modifying, or deleting resources.
Run terraform apply Executes the plan, provisioning or updating resources and saving the state.
Run terraform destroy Cleans up and removes the infrastructure when it’s no longer needed.

Terraform communicates with cloud platforms through providers, which handle API calls and ensure resources are created, updated, or deleted in the correct order based on dependencies.

Why I Switched to Conventional Commits (and Why You Should Too)

ankitgadling — Fri, 08 Aug 2025 08:50:50 +0000

Hello Buddy,

This is Ankit, a Python developer currently floating in the AWS cloud.

When I started writing code, I was always stuck when it came to committing. I had no idea what to write in a commit message, which often resulted in me not committing any code for a long time. Eventually, when it was time to push, I would end up with so many lines and files changed all dumped into one ugly commit.

I kept doing this for a long time.

Then I realized my mistake and started committing code based on a feature or fix, This small change helped me understand my code better and work in a more structured way.

However, I still wasn't following any pattern when writing commit messages. This made my project’s commit history look weird and inconsistent.

While exploring some open-source code, I noticed certain patterns in commit messages. That's when I discovered Conventional Commits as one of the best and most effective ways of writing commit messages.

Now, I use it every day.

My old commit style (bad examples):

update
fix bug
done some changes

My new commit style (Conventional Commits examples):

feat(auth): add support for Google login
fix(api): handle empty payload in POST requests
refactor(db): improve query performance for user search

Why Conventional Commits Helped Me

Clear history - I can look at git log and instantly understand what each commit does.
Better collaboration - Team members know exactly what changed and why.
Automation - Tools can automatically generate changelogs or trigger CI/CD steps based on commit types.
Discipline - It forces me to break work into smaller, meaningful chunks.

Final Thoughts

If you often find yourself with one massive commit and a vague message, try adopting Conventional Commits.

Start small: pick one convention (feat, fix, docs, etc.) and stick with it. Over time, you’ll see your commit history become cleaner, more meaningful, and far easier to work with for both you and your team.

DEV Community: ankitgadling

Day 9 - Protect resources from accidental deletion.

Let’s see how it works

Example 1: Preventing downtime - create_before_destroy

Example 2: Protecting critical resources - prevent_destroy

Example 3: Ignoring externally managed changes - ignore_changes

Example 4: Triggering replacement on dependency changes - replace_triggered_by

Example 5: Validating input and output - precondition and postcondition

Day 8 - Terraform Meta-Arguments

Common Terraform Meta-Arguments

How Meta-Arguments Help in Real Projects

Example Using count

Example Using for_each

Example Using depends_on

Scenario

Why is depends_on useful?

Why Meta-Arguments Are Important

Day 7 – Type Constraints in Terraform

1. Primitive Types

String

Number

Bool

2. Complex Types

List

Set

Tuple

Map

Object

3. Special Types

Any

Null

How These Types Help in Real Terraform Projects

Strings for Naming Resources

Numbers for Scaling Resources

Booleans for Feature Toggles

Lists for Repeating Resources

Maps for Centralized Tagging

Objects for Clean, Structured Config

Day 6 - Terraform Project Structure Best Practices

Why Project Structure Matters in Terraform

Cons of Not Having a Proper Terraform Project Structure

1. Hard to Maintain and Scale

2. Increased Risk of Mistakes

3. Poor Collaboration

4. Difficult Troubleshooting

5. Reusability Drops

Best Practices Recommended by Terraform

1. Separate Environments

2. Maintain a Clear File Layout

3. Follow Naming Conventions

4. Keep Secrets Out of Your Code

Conclusion

Day 5 - Terraform Variables

1. Input Variables

2. Output Variables

3. Local Values (locals)

String Concatenation in Terraform

Terraform Variable Precedence

Example Environment Variable

✔ Example CLI Variable

✔ Example CLI Var File

Example: Creating an S3 Bucket Using env = dev

variables.tf

main.tf

terraform.tfvars (optional)

Run Commands

Resulting Bucket Name

Day 4 - Terraform State File Management with Remote Backends (S3 Native Locking)

What Is a Terraform State File?

State File Best Practices

Why Store State Files Remotely?

AWS Remote Backend Overview

S3 Native State Locking (Terraform 1.10+)

How It Works

Why Locking Prevents State Corruption

Day 3 - Create an AWS S3 Bucket Using Terraform

What is an S3 bucket?

When to use

Prerequisites

Tips & best practices

Example 1: Preventing downtime - `create_before_destroy`

Example 2: Protecting critical resources - `prevent_destroy`

Example 3: Ignoring externally managed changes - `ignore_changes`

Example 4: Triggering replacement on dependency changes - `replace_triggered_by`

Example 5: Validating input and output - `precondition` and `postcondition`

Step 3: Create `main.tf` File