DEV Community: Sreya Sharma

Diving into Terraform Provisioners

Sreya Sharma — Tue, 23 Dec 2025 16:12:24 +0000

Day 15 was exciting because I learned about Terraform provisioners — a feature that lets you run scripts or commands on your resources during creation or destruction. This added a new dimension to Terraform: it’s not just about creating infrastructure, it can also configure it automatically.

What Are Provisioners?

Provisioners allow Terraform to perform actions on a resource after it’s created or before it’s destroyed.
Think of them as automation hooks for your infrastructure.

There are two main types:

remote-exec – runs commands on remote machines (like EC2 instances)
local-exec – runs commands on your local machine

Why Provisioners Are Useful

Installing software or packages on a server after creation
Running initialization scripts
Copying files to resources
Automating post-deployment configuration

Provisioners help bridge the gap between Terraform and configuration management tools.

Using local-exec

This runs a command on your local machine instead of the resource.
Useful for notifications, scripts, or automation outside the cloud provider.

remote-exec

This installs Nginx immediately after the EC2 instance is created.
The connection block tells Terraform how to access the remote machine.

File Provisioners

Uploading a configuration or script to a server
Copying sensitive files like certificates securely

Key Takeaways

Provisioners are optional; Terraform recommends using them sparingly.
They are useful for bootstrapping and post-creation configuration.
remote-exec for remote machines, local-exec for local commands.
Overusing provisioners can lead to imperative code, which goes against Terraform’s declarative nature.

Day 14: My First Mini-Project – Hosting a Static Website on AWS with Terraform

Sreya Sharma — Thu, 18 Dec 2025 16:18:24 +0000

Day 14 was exciting because I applied everything I’ve learned so far in my first mini-project: hosting a static website using AWS S3 and CloudFront, all managed with Terraform. It was hands-on, practical, and a big confidence booster.

Project Overview

The goal was to:

Host a static website in an S3 bucket
Make it securely accessible via CloudFront
Manage everything through Terraform

Along the way, I learned how to handle public access, bucket policies, and CloudFront origin access control.

Key Steps I Followed

Create an S3 Bucket I started with a simple S3 bucket to host the website:
I kept the bucket private and enabled website hosting.
This ensures content is served only through CloudFront for security.
Configure Public Access & Bucket Policy

To allow CloudFront to access the bucket without making it public:

Using Origin Access Identity (OAI) ensures S3 content is private and only accessible via CloudFront
Set Up CloudFront Distribution

CloudFront handles content delivery and caching for the website:

CloudFront caches content globally and serves it over HTTPS.
The OAI ensures only CloudFront can access the S3 bucket.
Upload Website Files

I used Terraform’s aws_s3_bucket_object to upload HTML, CSS, and images:

Terraform can manage the content itself, not just infrastructure.

Key Learnings

S3 Bucket & Public Access: Keep buckets private and serve content via CloudFront.
CloudFront Origin Access Control: Protects your content while allowing secure delivery.
Bucket Policies: Essential for controlling who can access objects.
Terraform Automation: I realized how Terraform can manage both infrastructure and content together.
Real-World Flow: From bucket creation → policy → CloudFront → upload → serve.

Final Thoughts

Completing this mini-project made Terraform feel very real and practical. It was amazing to see a website live just from my configuration files.

This project also gave me confidence to tackle more complex setups like multi-region hosting, SSL certificates, or CI/CD integration with Terraform.

Day 13: Understanding Data Sources in Terraform (AWS)

Sreya Sharma — Wed, 17 Dec 2025 16:32:38 +0000

Day 13 was an important milestone in my Terraform learning journey. Until now, most of my work was about creating and managing resources. Today, I learned something equally powerful — data sources.

Data sources allow Terraform to read existing infrastructure instead of creating new resources. This concept made Terraform feel more practical and closer to real-world use cases.

What Are Data Sources in Terraform?

A data source is used when:

A resource already exists in AWS
You want to reference it in Terraform
You don’t want Terraform to create or modify it

In simple words, resources create, but data sources read.

Why Data Sources Are Important

In real projects, not everything is created by Terraform. Sometimes:

VPCs already exist
AMIs are prebuilt
IAM roles are managed by another team
S3 buckets already exist Data sources help Terraform fetch this information and use it safely.

Basic Syntax of a Data Source

data "<provider>_<resource_type>" "<name>" {
  # filters or identifiers
}

Common AWS Data Sources I Explored

VPC
Subnet
AMI

Resource vs Data Source (Simple Understanding)

Resources create and manage
Data sources read and reference
Resources change infrastructure
Data sources do not make changes

Understanding this difference cleared up a lot of confusion for me.

What I Took Away from Day 13

Data sources make Terraform more dynamic
Existing infrastructure can be reused safely
Hardcoding values should be avoided
Most real-world Terraform projects rely heavily on data sources

Day 12: Going Deeper into Terraform Functions and Validations

Sreya Sharma — Tue, 16 Dec 2025 16:22:18 +0000

Day 12 was about understanding how Terraform handles time, data types, files, numbers, and validations. These topics may look small individually, but together they play a huge role in writing safe, flexible, and production-ready Terraform code.

This day helped me realize that Terraform is not just about creating resources — it’s also about controlling data and preventing mistakes before they happen.

Working with Date and Time Functions

Terraform provides functions to work with time-based values, which are useful for tagging, tracking, and automation.

Example

locals {
  created_time = timestamp()
}

Input Validation: Preventing Wrong Values

Validation blocks ensure that incorrect input values are rejected before Terraform runs.
This avoids mistakes like passing invalid environment names and helps keep infrastructure consistent.

Numeric Functions in Terraform

Numeric functions help perform calculations inside Terraform.

Examples

max(3, 5, 7)
min(1, 2, 3)
abs(-10)

These are useful when dealing with scaling values, limits, or thresholds.

Reading Files Using the file Function

The file function allows Terraform to read content from a file and use it inside the configuration.

Example

locals {
  policy = file("policy.json")
}

This is very useful when attaching IAM policies, user data scripts, or configuration templates without hardcoding them.

What I Learned from Day 12

After practicing these concepts, a few things became clear:

Terraform can handle dynamic values easily
Validations catch errors early
File handling keeps code clean
Type conversions prevent runtime failures
Numeric functions support smarter scaling logic
These features add reliability to Terraform projects.

Key Takeaways from Day 12

Date and time functions help with tracking
Type conversion avoids data mismatch issues
File function prevents hardcoding
Validation blocks improve safety
Numeric functions support logical decisions

Day 11: Understanding Terraform Functions Through Real Use Cases

Sreya Sharma — Mon, 15 Dec 2025 14:20:30 +0000

Day 11 was all about Terraform functions — and honestly, this was the day when my code started to feel cleaner and more controlled. Instead of manually fixing values or writing extra logic, I learned how built-in functions can handle common problems in a simple and readable way.

Functions in Terraform help transform, format, and manage data without complicating the configuration.

Why Terraform Functions Matter

In real projects, inputs are not always perfect. Names come in different formats, values need to be combined, and maps need safe lookups. Functions solve these problems inside Terraform itself.

Today, I explored some commonly used and very practical functions:

lower
upper
merge
split
lookup
replace
Working with Text: lower and upper
These functions are mainly used to keep naming consistent, especially for resource names and tags.
This is useful when AWS resources require lowercase names or when you want standardized tags.

Combining Maps with merge

The merge function is helpful when you want to combine multiple maps, especially for tags.
This avoids repeating the same tags across resources and keeps tagging clean and centralized.

Breaking Strings Using split

split is used when you want to convert a string into a list.
This is helpful when inputs come as comma-separated values and need to be processed further.

Safe Map Access with lookup

The lookup function prevents errors when accessing map values.
If the key doesn’t exist, Terraform uses the default value instead of failing.
**
Modifying Strings Using replace**
The replace function is used to modify part of a string.
This is helpful when switching environments or reusing naming patterns without rewriting everything.

What I Learned from Today’s Practice

After working with these functions, I realized:

Functions reduce manual errors
Code becomes more readable and reusable
Naming consistency becomes easier
Terraform feels more like programming logic, not just configuration

These small tools make a big difference in real-world infrastructure code.

Key Takeaways from Day 11

Functions transform and control input values
lower and upper standardize text
merge simplifies tag management
split helps process string inputs
lookup avoids runtime errors
replace makes refactoring easier

Day 10: Making Terraform Smarter with Conditions, Dynamic Blocks, and Splat Expressions

Sreya Sharma — Sun, 14 Dec 2025 07:11:44 +0000

Day 10 was one of those days where Terraform started to feel less like static configuration and more like real logic. Until now, I was mostly writing fixed resources. Today, I learned how to make Terraform react to conditions, generate blocks dynamically, and handle multiple resources cleanly.

This session focused on three important concepts: conditional expressions, dynamic blocks, and splat expressions.

Conditional Expressions in Terraform

Conditional expressions help Terraform make decisions based on values. Instead of writing separate resources for different environments, we can control behavior using conditions.

The basic format looks like this:

condition ? true_value : false_value

Dynamic Blocks: Writing Less, Doing More

Dynamic blocks were one of the most interesting parts of today’s learning. They allow Terraform to generate repeated blocks automatically, instead of writing the same configuration multiple times.

This is especially useful when a resource has nested blocks like ingress rules or tags.

Example:

dynamic "ingress" {
  for_each = var.ingress_rules
  content {
    from_port   = ingress.value.from
    to_port     = ingress.value.to
    protocol    = ingress.value.protocol
    cidr_blocks = ingress.value.cidr
  }
}

What I liked about this is how clean the configuration becomes. Instead of repeating the same block again and again, Terraform handles it in a loop-like way.

Dynamic blocks make the code:
Easier to maintain
Less repetitive
More flexible

Splat Expressions: Working with Multiple Resources

Splat expressions are used when multiple resources are created and we want to access their attributes together.

Example

aws_instance.example[*].id

This returns a list of all instance IDs created under that resource.

Splat expressions are very helpful when:

Using count or for_each
Passing multiple values to outputs
Avoiding manual indexing

It made my code feel cleaner and easier to understand.

What I Understood After Practicing

Before today, I was writing Terraform in a very fixed way. After learning these concepts:

Conditional expressions helped reduce duplicate code
Dynamic blocks simplified repeated configurations
Splat expressions made handling multiple resources easier
Terraform felt more logical and flexible

Hands-on practice made these concepts much clearer than just reading about them.

Key Takeaways from Day 10

Terraform supports conditional logic
Dynamic blocks reduce repetition
Splat expressions simplify multi-resource outputs
These features make Terraform more scalable
Clean logic leads to clean infrastructure code

Day 09: Learning Terraform Lifecycle Rules

Sreya Sharma — Thu, 11 Dec 2025 13:27:36 +0000

Day 09 of my Terraform journey was all about resource lifecycle management.
Until today, I thought lifecycle rules were just optional settings people rarely use. But after practicing them hands-on, I realized how important they are when dealing with real infrastructure changes.

Terraform lifecycles let you control what Terraform should or should not do when something changes. This is extremely useful in production environments where accidental updates or deletions can cause problems.
Why Lifecycle Rules Matter

In many cases, we don’t want Terraform to automatically:

Why Lifecycle Rules Matter

In many cases, we don’t want Terraform to automatically:

delete a resource
replace a resource
modify something that is sensitive
recreate something every time a change happens Lifecycle rules help us put guardrails around our infrastructure.

1.create_before_destroy: Avoid Downtime

This setting tells Terraform to create the new resource first, and only then destroy the old one.

2.prevent_destroy: Safety Lock

This was the most interesting one for me:
It literally blocks Terraform from destroying the resource, even if it is removed from the code.

3.ignore_changes: Ignore Specific Updates

Sometimes a resource updates outside Terraform (like in AWS console).
Instead of Terraform trying to “fix it” on every apply, we can tell it to ignore certain changes.

What I Understood Practically

When I tried modifying values in my configuration:

Terraform wanted to recreate the resource
Lifecycle rules helped control what should and shouldn’t be changed
Adding prevent_destroy stopped accidental deletion
Using ignore_changes prevented unnecessary updates
create_before_destroy ensured continuous availability

Hands-on practice made the purpose of lifecycle rules very clear.

Key Takeaways from Day 09

Lifecycle rules give us control over Terraform behavior
They prevent accidental deletions
They avoid unnecessary recreations
They keep critical resources safe
They are heavily used in production Terraform code
Lifecycle rules improve stability and predictability

Day 08: Understanding Terraform Meta-Arguments

Sreya Sharma — Wed, 10 Dec 2025 12:59:39 +0000

Day 08 was about something I had seen many times in Terraform code but never fully understood — meta-arguments.

At first, they looked like advanced or optional features. But after practicing them hands-on, I realized that meta-arguments control how Terraform creates resources, not just what it creates.

What Are Meta-Arguments in Terraform?

Meta-arguments are special arguments that work across many Terraform resources.
They are not specific to AWS, EC2, or S3 — instead, they change the behavior and lifecycle of resources.

Some of the most commonly used meta-arguments are:

depends_on
count
for_each

These play a huge role in real-world Terraform projects.

Explicit Dependency with depends_on

Terraform usually understands dependencies automatically.
But sometimes, dependencies are not obvious — and that’s where depends_on is useful.
This helps avoid errors where one resource must exist before another can be created.

Creating Multiple Resources with count

The count meta-argument is used when you need multiple identical resources.
Resources are indexed, like:

aws_instance.example[0]
aws_instance.example[1]

count works best when resources are mostly identical and only the number changes.

Managing Resources with for_each

for_each is more flexible than count and is very useful when working with maps or sets.
With for_each, each resource gets a unique key, making updates safer and clearer.

Compared to count, for_each avoids index-based confusion when values change.

count vs for_each (What I Noticed)

count is simple but index-based
for_each is safer and easier to manage
for_each works well with maps and sets
Changing count can cause resource recreation
for_each keeps resource identity stable

In real projects, for_each feels more reliable.

Why Meta-Arguments Matter

Before learning meta-arguments, Terraform felt limited to single resources.
After understanding them, I could:

Control resource creation order
Dynamically scale resources
Write cleaner and reusable code

Meta-arguments make Terraform powerful and production-ready.

What I Learned on Day 08

Meta-arguments change resource behavior, not infrastructure logic
depends_on handles explicit dependencies
count is useful for identical resources
for_each is better for complex and dynamic setups
Choosing the right meta-argument avoids future issues.

Day 07: Getting Comfortable with Terraform Variables

Sreya Sharma — Tue, 09 Dec 2025 17:19:55 +0000

Day 07 was all about variables, but this time I didn’t just read about them — I actually worked with them deeply. After today, Terraform code started feeling much cleaner and easier to manage.

Earlier, my configurations had many hardcoded values. Today’s learning showed me why that’s not a good idea and how variables make Terraform projects more flexible and readable.

Why Variables Matter More Than I Thought

When you’re writing small Terraform examples, hardcoding values feels fine. But as soon as a project grows, it becomes confusing very quickly.

Using variables helped me:

void repeating the same values
Change configurations easily
Write cleaner, more meaningful code

Creating a separate variables.tf file made a big difference. Everything related to inputs was in one place, and the main configuration felt much simpler.

Simple Variable Types I Worked With

I started with the basic types and used them in real resources.

String: Used for names and regions.
Number: Used for counts and sizes.
Boolean: Helped in enabling or disabling features.
List: Used when order matters.
Set: Similar to a list, but without duplicate values.
Tuple: Used when multiple values of different types are grouped together.
Map / Dictionary: Very useful for tags and key-value data

Keeping Variables in a Separate File

Instead of spreading variables across files, I created a dedicated variables.tf file. This small change made the whole project easier to understand and maintain.

Pairing it with terraform.tfvars allowed me to change values without touching the main code, which felt very clean and professional.

What I Took Away from Day 07

Variables reduce hardcoding and repetition
Collection types make configurations flexible
Maps are perfect for tags and metadata
Separate variable files keep projects organized
Terraform code becomes easier to read and modify

Final Thoughts

Today’s learning made Terraform feel much more practical. Variables are not just a concept — they actually shape how clean and reusable your infrastructure code becomes.

Day 07 gave me more confidence to write Terraform projects in a structured and real-world way rather than just experimenting.

Day 06: Understanding a Clean Terraform Project Structure

Sreya Sharma — Mon, 08 Dec 2025 12:49:06 +0000

On Day 06 of my Terraform learning journey, I focused on something that is easy to ignore early on but becomes extremely important as projects grow: project structure.

Writing Terraform code is not just about making it work—it’s about making it easy to read, maintain, and scale. A clean project structure helps avoid confusion, reduces mistakes, and makes collaboration much smoother.

Why Project Structure Matters in Terraform

As Terraform projects grow, putting everything into a single file quickly becomes messy. Separating configuration into logical files improves:

Readability
Debugging
Collaboration
Long-term maintainability

Terraform automatically loads all .tf files in a directory, so splitting files does not affect execution.

A common and clean Terraform project structure looks like this:

terraform-project/
│
├── main.tf
├── provider.tf
├── backend.tf
├── variables.tf
├── outputs.tf
├── terraform.tfvars
├── .gitignore
`

Each file has a clear responsibility.

Purpose of Each File

main.tf: Contains the core resource definitions such as EC2, S3, VPC, etc.
provider.tf: Defines the provider configuration.
backend.tf: Used to configure remote state storage.
variables.tf: Declares all input variables.
terraform.tfvars: Stores actual variable values.
outputs.tf: Defines output values after apply.

Using .gitignore in Terraform Projects

Some Terraform files should never be pushed to GitHub because they contain sensitive or generated data.


.terraform/
*.tfstate
*.tfstate.backup
terraform.tfvars

Why This Matters?

State files may contain secrets
Provider binaries are auto-generated
Variable files may store sensitive values Ignoring these files protects your infrastructure and credentials.

Key Learnings from Day 06

Terraform automatically reads all .tf files in a directory
Splitting configuration improves clarity
Clean structure prevents mistakes in large projects
Git ignore rules protect sensitive data
Good structure reflects professional Terraform practices

Conclusion

A good Terraform project is not just about resources—it’s about organization. Structuring files properly makes Terraform code easier to understand, safer to manage, and ready for real-world use.

Day 06 reinforced that clean Infrastructure as Code starts with a clean structure.

Day 05: Understanding Variables in Terraform

Sreya Sharma — Sun, 07 Dec 2025 12:42:10 +0000

On Day 05 of my Terraform learning journey, I focused on one of the most important building blocks of reusable and flexible Infrastructure as Code: Terraform variables.

Variables help remove hardcoded values, improve readability, and make Terraform configurations easier to manage across environments.
**

Types of Variables in Terraform

Terraform primarily works with three kinds of variables:

Input variables
Local variables
Output variables

Each serves a specific purpose in Terraform configurations.
**

Input Variables

Input variables allow users to provide values dynamically instead of hardcoding them.

Example:

variable "bucket_name" {
  type    = string
  default = "my-demo-bucket"
}

Used in a resource:


resource "aws_s3_bucket" "example" {
  bucket = var.bucket_name
}

Input variables make configurations reusable and environment-independent.
**

Local Variables

Local variables are used to calculate or store values internally within a configuration.
They reduce repetition and improve readability.

Example:

locals {
  environment = "dev"
  bucket_tag  = "${local.environment}-s3-bucket"
}

Usage:

tags = {
  Name = local.bucket_tag
}

Locals cannot be overridden from the command line.
**

Output Variables

Output variables display values after Terraform applies the configuration.
They are useful for debugging and for passing information to other modules.

Example:

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

After terraform apply, the bucket name is printed in the terminal.
**

Terraform Variable Data Types

Terraform supports multiple data types, including:

string – text values
number – integers and decimals
bool – true or false

Example:

variable "region" {
  type    = string
  default = "ap-south-1"
}

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

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

Default Values and Null

**
Default Values

A default value allows Terraform to use a variable automatically if no value is provided.


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

Null Values

The null value means no value is set.
Terraform ignores arguments set to null, which helps in conditional configurations.

variable "bucket_acl" {
  type    = string
  default = null
}

If bucket_acl is null, Terraform simply does not apply it.

Key Takeaways from Day 05

Variables make Terraform flexible and reusable
Input variables accept user-provided values
Local variables simplify internal expressions
Output variables expose useful information.
Data types improve validation and safety
Default and null help with optional configurations.

Conclusion

Understanding variables is critical to writing clean and scalable Terraform code. By using input, local, and output variables correctly, Terraform configurations become more readable, reusable, and easier to maintain across different environments.

Day 05 strengthened the foundation needed to move toward more advanced Terraform concepts.

Day 04: Terraform State File — The Backbone of Infrastructure as Code

Sreya Sharma — Sat, 06 Dec 2025 08:23:15 +0000

On Day 04 of my Terraform learning journey, I covered one of the most critical and often underestimated components of Terraform: the state file.

Until this point, Terraform felt simple—write code, plan, apply. However, understanding how Terraform tracks infrastructure, detects changes, and protects sensitive data requires a deep understanding of the Terraform state and its management.

This day focused on what state files are, why they matter, how remote backends improve security, and how to manage state safely using Terraform commands.

What Is a Terraform State File?

Terraform stores information about managed infrastructure in a file called terraform.tfstate.

The state file acts as a source of truth for Terraform by tracking:

What resources exist
Their current attributes
How Terraform maps configuration to real-world infrastructure Terraform uses this state file to determine what already exists and what needs to change. **

Desired State vs Actual State

Terraform operates by comparing two states:

Desired State Defined in Terraform configuration files (.tf) -Actual State Pulled from real infrastructure providers like AWS

The state file stores the last known actual state.
During terraform plan, Terraform compares:

Desired State (code)
        vs
Terraform State
        vs
Actual Infrastructure

Why Terraform State Is Sensitive

The state file often contains sensitive data, including:

Resource IDs
IP addresses
Database endpoints
IAM role ARNs
Sometimes plaintext secrets and passwords

Storing terraform.tfstate locally or pushing it to GitHub can lead to:

Credential leakage
Infrastructure misuse
Security breaches

Because of this, state files should never be committed to version control.
**

Why Use a Remote Backend?

A remote backend stores the state file in a centralized, secure location instead of local storage.

Using a remote backend helps to:

Prevent accidental state exposure
Enable team collaboration
Avoid state conflicts
Ensure consistency across environments

For AWS-based workflows, S3 is commonly used as a remote backend.
**

Setting Up Remote Backend Using S3

**
Example Backend Configuration

terraform {
  backend "s3" {
    bucket         = "my-terraform-state-bucket"
    key            = "dev/terraform.tfstate"
    region         = "ap-south-1"
    encrypt        = true
  }
}

Best Practices for Terraform State Management

Never commit .tfstate files to Git
Always use a remote backend for teams and production
Enable encryption for state storage
Use state locking to prevent concurrent changes
Restrict access to the state bucket using IAM policies
Maintain separate state files for different environments

*.tfstate
*.tfstate.backup
.terraform/

Terraform State Management Commands

Terraform provides powerful commands to inspect and manipulate state safely.

List Resources in State

terraform state list

Displays all resources currently tracked by Terraform.

Show a Specific Resource

`terraform state show aws_s3_bucket.example`

Shows full details of a resource as stored in the state file.

Remove a Resource from State

terraform state rm aws_s3_bucket.example

Removes a resource from state without destroying it in AWS.

Useful when:

Resources were deleted manually
You want Terraform to stop managing a resource

Move a Resource in State

terraform state mv aws_instance.old aws_instance.new

Moves a resource from one address to another without recreation.
**

Why Terraform State Is the Heart of IaC

**
Terraform code defines what you want.
Terraform state defines what exists.

Without the state file:

Terraform cannot detect changes
Resources may be duplicated
Infrastructure consistency is lost

Understanding state management transforms Terraform from a simple automation tool into a production-grade infrastructure management system.
**

Key Takeaways from Day 04

Terraform state tracks real infrastructure
State files contain sensitive information
Remote backends improve security and collaboration
S3 + DynamoDB enable secure state storage and locking
Terraform state commands provide powerful control
Proper state management is non-negotiable for production

Conclusion

Day 04 highlighted that Terraform is not just about writing .tf files. Proper state handling is what makes Infrastructure as Code reliable, secure, and scalable. Mastering state management ensures that infrastructure changes are controlled, auditable, and safe.