DEV Community: Brian Mengo

AWS Terraform Type Constarints

Brian Mengo — Sun, 10 May 2026 15:21:19 +0000

Today, I learned about Terraform type constraints and why they are essential for writing safe, predictable, and maintainable infrastructure code.

Terraform variables are not just about passing values. With type constraints, variables become contracts that define what kind of data is allowed.

Topics Covered

Primitive types: string, number, bool
Collection types: list, set, map
Structural types: tuple, object
Type validation and constraints
Defining complex variable structures

Why Type Constraints Matter
Without type constraints, Terraform treats variables as loosely typed. This can lead to:

Runtime errors during terraform apply
Unexpected values passed to resources
Hard-to-debug infrastructure issues
Using type constraints gives you:
Early validation at terraform plan
Self-documenting variables
Safer and predictable infrastructure code

Primitive Type
Number
Supports both integers and floating-point values.
example

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

Specifying the type as number restricts the variable to numeric values, matching Terraform’s expectations for count

String
A string is used for text-based values such as names, regions, or identifiers.
Example

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

String values must be enclosed in double quotes and can contain spaces.

Boolean
A boolean represents true or false. It is commonly used for feature toggles.
example

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

Complex Types in Terraform
List
A list is an ordered collection of values of the same type

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

Set
A set is similar to a list, but:

Values must be unique
Order is not guaranteed

Commonly used for Security-groups;

variable "allowed_ports" {
  type = set(number)
  default = [22, 80, 443]
}

Map
A key-value structure frequently used for tagging AWS resources.

variable "tag" {
  type = map(string)
  default = {
    Environment = "Dev"
    Name = "Dev-EC2-instance"
  }

Structural Types(Advanced)
Object

Object is a collection of named attributes with different data types, defined with keys.
Example object variable config with three attributes:

variable "config" {
  type = object({
    region         = string
    monitoring     = bool
    instance_count = number
  })
  default = {
    region         = "us-east-1"
    monitoring     = true
    instance_count = 1
  }
}

Tuple

Tuple enables grouping multiple values with different data types in a fixed sequence.
Example tuple variable with three elements (number, string, number):

variable "ingress_values" {
  type = tuple([number, string, number])
  default = [443, "TCP", 443]
}

Best practice I learnt when using type contraints;

Use primitives for simple values.
Use complex types to group multiple related values, especially when types vary.
Understand indexing rules: lists and tuples are indexed; sets are not.
Use objects for structured data with named fields of different types.
Use maps for homogeneous key-value pairs.

Terraform File Structures

Brian Mengo — Sun, 10 May 2026 10:19:51 +0000

Introduction
Today we focus on file structure and organising Terraform projects. Initially all resources were placed in a single main.tf file to simplify the learning process. What we are doing now is to improve the project structure by splitting resources and configurations into multiple files for better readability, collaboration and maintainablity.
The root directory of a Terraform project is called the root module.

Terraform File Loading

There is no strict mandatory naming convention for Terraform files.recommendations come from HashiCorp best practices but are flexible.
How Terraform loads files;

Terraform loads all .tf files in the current directory
Files are loaded in lexicographical order (alphabetical)
All .tf files are merged into a single configuration

Recommended File Structure and Best Practices

project-root/
├── backend.tf           # Backend configuration
├── provider.tf          # Provider configurations
├── variables.tf         # Input variable definitions
├── locals.tf           # Local value definitions
├── main.tf             # Main resource definitions
├── vpc.tf              # VPC-related resources
├── security.tf         # Security groups, NACLs
├── compute.tf          # EC2, Auto Scaling, etc.
├── storage.tf          # S3, EBS, EFS resources
├── database.tf         # RDS, DynamoDB resources
├── outputs.tf          # Output definitions
├── terraform.tfvars   # Variable values
└── README.md           # Documentation

Common recommended files in the root module include:

main.tf: Contains primary resource definitions such as S3, VPC, EC2, etc. Alternatively, resources may be further subdivided into files named after the resource type (e.g., s3.tf, vpc.tf, ec2.tf), but this can become complex with many resources.
variables.tf: Dedicated file for input variable declarations (moved out from main.tf).
outputs.tf: File for output declarations.
providers.tf: Contains provider configuration.
backend.tf: Contains backend configuration for state management.
terraform.tfvars: File for input variable values (sensitive values should not be committed).
terraform.tfvars.example: Template file for variable values to be shared publicly without exposing secrets.
.gitignore: To exclude sensitive or unnecessary files from being committed to version control.
README: Documentation file. Key best practice: Do not commit .tfvars files containing secrets or sensitive values to GitHub; instead, commit a .example template.

.gitignore Configuration and Files to Exclude
The .gitignore file should exclude:

.terraform/ directory (Terraform metadata, plugins, and cache)
*.tfstate and *.tfstate.backup files (Terraform state files)
.terraform.lock.hcl (provider dependency lock file)
*.log files (e.g., crash logs)
terraform.tfvars and any *.tfvars.json files (to avoid publishing sensitive data)
These exclusions protect sensitive information and prevent unnecessary files from cluttering the repository.

Advanced Project Structures and Environment Management

Multiple environments: Separate folders or configurations for dev, staging, prod, each with distinct main.tf files.

environments/
├── dev/
│   ├── backend.tf
│   ├── terraform.tfvars
│   └── main.tf
├── staging/
│   ├── backend.tf
│   ├── terraform.tfvars
│   └── main.tf
└── production/
    ├── backend.tf
    ├── terraform.tfvars
    └── main.tf

Modularisation: Using modules for logically grouped resources, e.g., networking, compute, security modules.

modules/
├── vpc/
├── security/
└── compute/

Another approach is to use the same Terraform configuration files for all environments but supply different terraform.tfvars files for each environment to inject environment-specific values.

Terraform should be readable first, functional second.

Day 6 helped me understand something deeper:
Good Terraform isn’t just about writing code—it’s about organizing it.

A clean structure makes your infrastructure:

Easier to maintain
Easier to scale
Easier for team to collaborate
Easier to troubleshoot

Below is the video that helped me understand this concept;

Terraform Variables - Input Vs Output Vs Local Variables

Brian Mengo — Mon, 04 May 2026 00:26:32 +0000

Purpose of Variables in Terraform

Variables prevent repetitive hardcoding of values in Terraform configuration files.
They reduce errors due to inconsistent value entries across multiple resources.
Simplify updating environment-specific configurations (e.g., changing from dev to stage).

Types of Variables Based on Purpose

Input Variables: Accept values from users or other sources.
Output Variables: Display or pass resource attributes after creation.
Locals: Define reusable, local values within a Terraform module for simplification and consistency.

Variable Types Based on Value

Primitive Types: string, number, bool(boolean).
Complex Types: list, set, map, object, tuple.
Special Types:
null (no specific type defined).
any (auto-detects type based on assigned value).

Variable Declaration Syntax

Basic format:

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

Accessing variables in Terraform uses the syntax:

For simple reference: var.environment
For string interpolation: "${var.environment}-bucket"

Locals Usage

Locals are defined using the locals block to store computed or concatenated values.
Example:

locals {
  bucket_name = "${var.environment}-bucket"
}

Output Variables
Output variables allow capturing and displaying resource attributes after Terraform applies changes.
Example declaration:

output "vpc_id" {
  value = aws_vpc.sample.id
}

Variable Precedence in Terraform
Terraform supports multiple methods to assign values to variables. These methods have a clear precedence hierarchy from lowest to highest:

1 (Lowest) Default value in variable block - Value assigned within the variable declaration as default.
2 Environment variables prefixed with TF_VAR_ - Shell environment variables such as export TF_VAR_environment=stage.
3 Variable definition files (.tfvars or .tfvars.json) - Separate files like terraform.tfvars with key-value pairs.
4 (Highest) Command-line flags (-var, -var-file) - Values passed directly during terraform plan or terraform apply.

Using environment variables or command-line flags allows dynamic overrides without changing Terraform files.
.tfvars files are preferred for organising variables when multiple environments or parameter sets are used.
Sensitive data (e.g., credentials) should be managed carefully, preferably using secret management tools instead of environment variables or command-line flags to avoid exposure in shell history.

Best Practices and Recommendations

Use variables and locals to improve code reusability, consistency, and maintainability.
Prefer .tfvars files for variable management in multi-environment setups.
Use output variables to expose important resource attributes for downstream use.
Validate resource names and types against the latest Terraform AWS provider documentation.
Manage sensitive variables securely outside of Terraform files.
Clean up resources after testing with terraform destroy -auto-approve to avoid unnecessary costs.

Terraform State File Management with Remote Backend

Brian Mengo — Fri, 01 May 2026 03:05:48 +0000

On day 4 of my learning journey I learnt how Terraform remembers what it creates, and how to manage that memory safely using a remote backend.

When running terraform apply, a file named terraform.tfstate is generated in the working directory.
This file is critical because it stores metadata that Terraform uses to track infrastructure resources.

Why Remote State Matters
When Terraform runs, it keeps track of infrastructure in a state file.

If that file stays on a local machine:

It’s not shareable
It’s not safe
It can easily get corrupted or lost

StateFile Best Practices
Store StateFile to a Remote Backend: The problem with Statefile is it also contains all the important information like configuration, access keys and other sensitive information. So we shouldn't log that to a github or any other personal folders. It is better to keep that in a Remote Backend like S3 in AWS, Blob in Azure and GCP Cloud Staorage.

Do Not Update/Delete StateFile: StateFile will always be generated by Terraform. You should not make any manual changes to that file or shouldn't delete them.

State Locking: Just imagine there is a StateFile and 2 devops engineers tries to modify or create infra using that file with different changes. This will corrupt StateFile. So It should be locked in such a way until first user completes terraform apply, then it should be unlocked and second user should apply his changes after that.

Isolation of StateFile: StateFile should be isolated for multiple environments in a different folder. Not all StateFile should be combined with a same name or in a same folder.

Regular Backup: It is essential to take regular backup's of a StateFile as we cannot access them in case of Global outages. So Enable Versioning on AWS S3 Buckets and also setup policies to store older StateFiles to a different account or tar them to other location.

Backend Configuration Details

The S3 bucket used for state storage must already exist before initializing Terraform.
The bucket is not created by Terraform itself because it must be available to store the state file before Terraform runs.
Creating the bucket manually can be done via AWS CLI, AWS Console, or CI/CD pipelines.
Avoid including the bucket creation in Terraform resources to prevent circular dependencies.

Configured Remote Backend
I updated my Terraform configuration to use S3 as backend:

backend "s3" {
  bucket       = "my-terraform-state-bucket"
  key          = "day-04/dev/terraform.tfstate"
  region       = "us-east-1"
  use_lockfile = true
  encrypt      = true
}

Observing Remote State File Behaviour

When running terraform plan or terraform apply, no state file is created locally except a minimal metadata file.
The actual state file is stored inside the S3 bucket under the specified key (e.g.,dev/terraform.tfstate).
The remote state file is a JSON file containing all resource details, including some encoded and sensitive information.
This setup improves security by avoiding sensitive state information on local machines and centralising management.

Verified state in S3

Managing Terraform State

Terraform provides commands to manage state without manual JSON editing:

terraform state list Lists resources in the state file
terraform state show Shows detailed info about a specific resource
terraform state rm Removes a resource from the state file (safe method)
terraform state pull Fetches the current state file from backend

These commands help manage the state file programmatically and safely.

Below is the Youtube Video for reference: Tech Tutorials with Piyush — “Terraform StateFile Management with S3”

Creating AWS S3 Bucket using Terraform

Brian Mengo — Sun, 26 Apr 2026 11:36:04 +0000

Introduction
The first resource I create and provision using terraform is the AWS S3 bucket. By writing terraform configuration files (.tf files) to initialise providers and use terraform commands to interact with AWS APIs and provision resources.

AWS CLI for credentials setup before creating any resource in AWS using aws configure.
The below image shows the procedure of provisioning a simple S3 Bucket.

Terraform Configuration
The set up for this resource involves only two block: the provider configuration block and the S3 bucket resource block

The Provider Block
Since we are using the AWS provider we setup by specifying the region in which the resource will be created

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

S3 Bucket Resource Block

resource "aws_s3_bucket" "demo_bucket" {
  bucket = "devbrio53-store"

  tags = {
    Name        = "My bucket"
    Environment = "Dev"
  }
}

The Terraform resource block starts with the keyword resource, followed by the resource type aws_s3_bucket and a user-defined resource name (e.g., first_bucket).

The bucket name must be globally unique across AWS regions.

Tags are added as a nested block with key-value pairs, e.g., Name and Environment
Tags are strings enclosed in double quotes and enclosed within curly braces, representing a map/dictionary data type in Terraform.

Using Terraform AWS provider documentation to find the correct resource block for an S3 bucket (aws_s3_bucket).
The documentation provides example usage, argument references (mandatory and optional parameters), and guides how to customise the resource block.

Running Terraform Commands to Provision the Bucket

Terraform initialisation is run using the command:

terraform init

This downloads the necessary provider plugins and initialises the backend.

Next, a plan is created using:

terraform plan

This performs a dry run to preview the changes Terraform will apply without actually creating or modifying resources.

The command to apply the changes and create the bucket is:

terraform apply

Terraform prompts for confirmation before applying changes; typing yes proceeds with the creation.

Running terraform plan again shows

Zero resources to add
One resource to change
Zero resources to destroy

Terraform performs a state comparison between the current AWS environment and the configuration file to detect changes.

To delete the created bucket and clean up resources, the command is:

terraform destroy

This removes everything created by the Terraform configuration. It’s a handy way to keep your AWS account clean while learning.

Today’s learning wasn’t just about creating an S3 bucket.

It was about understanding how Terraform connects with AWS, and why authentication is the foundation of everything in cloud.

A simple bucket but a meaningful step forward.

Terraform AWS Provider

Brian Mengo — Thu, 23 Apr 2026 07:27:21 +0000

How Terraform Talks to the Cloud
We begin with an introductory concept of Terraform providers, which is basically a plugin bridging Terraform and cloud providers.
Providers translate Terraform's HCL (HashiCorp Configuration Language) code into API calls understood by cloud platforms like AWS, Azure, or GCP.
When provisioning a resource (e.g., an AWS S3 bucket), Terraform interacts with the cloud provider’s API via the corresponding provider plugin.

Role and Function of Terraform Providers

The provider plugin is responsible for translating Terraform’s configuration into API requests for the target service.
Terraform providers thus enable infrastructure as code by connecting declarative Terraform files with underlying API operations.

Types of Terraform Providers

There are three main categories of Terraform providers:

Official providers: Maintained by the cloud providers themselves (e.g., AWS, Azure, GCP).
Partner providers: Maintained by third-party organisations, not the cloud providers directly.
Community providers: Maintained by the open-source community. Providers can target cloud APIs or other services such as Docker, Kubernetes, Prometheus, and Grafana.

Exploring Terraform AWS Provider Documentation

Users are encouraged to visit the official Terraform AWS provider page on the Terraform Registry (registry.terraform.io).
This page lists all AWS services supported by the provider, enabling provisioning across a broad range of AWS infrastructure components.

Importance of Version Locking and Compatibility

Using the latest Terraform or provider versions by default can cause compatibility issues if your Terraform code is not tested against those versions.
Version locking ensures stability by using the tested combination of Terraform core and provider versions.
Upgrading versions should be done cautiously: test in non-production environments before applying to production.

Understanding Version Constraints and Operators
Terraform supports several operators for version constraints:
Operator Meaning;

= Exact version match only
!= Excludes the specified version
<, <= Allows versions less than (or equal to) the specified version
>, >= Allows versions greater than (or equal to) the specified version
~> (Tilde Greater Than) Allows patch-level updates within the specified minor version (e.g., ~> 6.7.0 allows any version >= 6.7.0 but < 6.8.0)

The tilde operator ~> is commonly used to allow patch upgrades without crossing minor or major version boundaries, preserving compatibility.
Examples:
~> 6.7.0 allows versions 6.7.1, 6.7.2, etc., but not 6.8.0.
~> 1.0 allows versions 1.1, 1.2, etc., but not 2.0.

Creating a Basic Terraform Provider Configuration

# Configure the AWS Provider
provider "aws" {
  region = "us-east-1"
}

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

# Create a VPC
resource "aws_vpc" "example" {
  cidr_block = "10.0.0.0/16"
}

This Terraform code tells Terraform to use the AWS provider and makes sure it uses a stable version of it. It then sets the AWS region to us-east-1, which means all resources will be created in that location. Finally, the code creates a VPC, which is like a private network inside AWS where you can later add servers, subnets, and other resources.

Terraform Init

Running terraform init or tf init downloads the necessary provider plugins and initialises Terraform in the working directory.
The provider plugin is downloaded automatically based on the system OS (Mac, Windows, Linux).
This step prepares Terraform to interact with the configured provider APIs.

Running terraform plan and Understanding its Output

terraform plan compares the current Terraform configuration with the real infrastructure state.
The plan shows which resources will be created, changed, or destroyed.

Authentication with AWS CLI
Terraform requires valid AWS credentials to interact with AWS services.
The simplest authentication method is running aws configure (AWS CLI tool) to input:

AWS Access Key ID
AWS Secret Access Key
Default region These credentials can be generated from the AWS Management Console under IAM users, with appropriate permissions (e.g., S3 full access). Credentials stored by AWS CLI are then used by Terraform automatically.

Best Practices I Learned
✔ Always specify provider versions
Never rely on defaults.

✔ Use version ranges (not just exact versions)
Keeps things safe but flexible.

✔ Test upgrades in a lower environment
Never update versions directly in production.

✔ Use terraform providers lock
It creates a .terraform.lock.hcl file to ensure consistent builds.

This makes your infrastructure “version-proof”.

Introduction to IAC, how Terraform Works- Day01

Brian Mengo — Tue, 21 Apr 2026 14:59:00 +0000

Day01 of my 30day AWS terraform challenge, and I begin with highlighting what IaC is and how teams are using it to manage infrastructure in the cloud.
Infrastructure as Code (IaC) is the practice of managing and provisioning computing infrastructure through machine-readable configuration files rather than through manual processes or interactive configuration tools.
Think of it like this: instead of clicking through a cloud console to spin up servers, databases, and networks, you write code that describes exactly what you want — and a tool builds it for you.

Tools for Infrastrucure as Code:

Terraform (Multi-cloud and widely used)
Pulumi
AWS CloudFormation, AWS CDK, AWS SAM
Azure ARM / Bicep
GCP Deployment Manager, GCP Config Controller

What is Terraform
Terraform is an open-source IaC tool created by HashiCorp. It allows you to define, preview, and deploy infrastructure across multiple cloud providers — AWS, Azure, Google Cloud, and hundreds more — using a simple, human-readable language called HCL (HashiCorp Configuration Language).

Manual provisioning of Infrastructure Challenges;

Time-consuming: A simple three-tier app infrastructure can take around 2 hours to set up manually.
Complexity grows exponentially when managing multiple environments
Human error risks: Manual steps increase chances of misconfiguration, security oversights, or inconsistent environments
Inconsistency: Different people provisioning environments can lead to "it works on my machine" issues.
High operational costs and delays affecting dependent teams

*Benefits of Terraform
*

Automates the process.
Reduces time needed to perform the same action again and again.
Reduces labour resource which was needed to manual perform the process.
Reduces the chances of human error.
We can track changes using git.

How Terraform Works
Terraform Initialise - Run terraform init to initialize the working directory and download necessary providers.
Validate Configuraion - Run terraform validate to check for syntax or configuration errors.
Terraform Plan - Run terraform plan to preview infrastructure changes before applying.
Terraform apply - Run terraform apply to provision or modify the infrastructure by calling cloud API.
Terraform Destroy - Run terraform destroy to delete resources when no longer needed.

Getting Started

Install Terraform → developer.hashicorp.com/terraform/install
Set up a cloud provider account (AWS Free Tier is great for learning)
Write your first .tf file and run terraform init, terraform plan, terraform apply
Explore the Terraform Registry → registry.terraform.io for modules and providers