TechOps Examples
Hey — It's Govardhana MK 👋
Welcome to another technical edition.
Every Tuesday – You’ll receive a free edition with a byte-size use case, remote job opportunities, top news, tools, and articles.
Every Thursday and Saturday – You’ll receive a special edition with a deep dive use case, remote job opportunities and articles.
We surveyed hundreds of infrastructure professionals for the 2026 State of IaC Report. The findings are stark: 1 in 3 practitioners can't restore within their own RTO, despite ranking rebuild confidence as the #1 benefit of IaC.
It gets harder: AI is now embedded in IaC workflows, but only 34% of teams would trust AI agents to make autonomous production changes.
The gap between adoption and readiness is widening at exactly the wrong moment.
What's in the report?
This real-world IaC industry report breaks it all down:
Where teams are failing on DR and why
How AI is reshaping IaC governance
What separates mature teams from the rest
IN TODAY'S EDITION
🧠 Use Case
How to Structure a Terraform Project
👀 Remote Jobs
Espresso Systems is hiring a DevOps Engineer
Remote Location: Worldwide
DoubleZero is hiring a SRE / Production Engineer
Remote Location: Worldwide
Powered by: Jobsurface.com
📚 Resources
If you’re not a subscriber, here’s what you missed last week.
To receive all the full articles and support TechOps Examples, consider subscribing:
🧠 USE CASE
How to Structure a Terraform Project
Why care about Terraform project structure? Simple, it keeps things organized so you can scale up, work well with your team, and keep everything secure. No fuss, just a setup that works.
This setup follows a layered structure, separating resources by environment (development, staging, production etc.,) and using centralized modules for reusable components.
Modules are kept in a central repository, allowing environments to source specific versions for controlled updates and consistent configurations.
Environment Directory Structure:
main. tf
Defines core resources for the environment by referencing modules from the central repository. Each module is tagged to ensure a specific version is used.
Example:
module "network" {
source = "git::https://github.com/terraform-aws-modules/terraform-aws-vpc.git//?ref=v3.19.0"
vpc_cidr = var.vpc_cidr
}
module "compute" {
source = "git::https://github.com/terraform-aws-modules/terraform-aws-ec2-instance.git//?ref=v4.2.0"
instance_count = var.instance_count
instance_type = var.instance_type
}variables. tf
Declares input variables, making the configuration adaptable. For example, instance_type might vary between environments (e.g., t2.micro in dev, t3.large in prod).
variable "vpc_cidr" {
type = string
description = "CIDR block for the VPC"
}
variable "instance_count" {
type = number
description = "Number of compute instances"
}
variable "instance_type" {
type = string
description = "Type of instance"
default = "t2.micro"
}provider. tf
Configures the cloud provider and backend for remote state storage, which tracks deployed resources. This setup is crucial for collaborative workflows.
terraform {
backend "s3" {
bucket = "my-terraform-state"
key = "${terraform.workspace}/terraform.tfstate"
region = "us-west-2"
}
}
provider "aws" {
region = "us-west-2"
}outputs. tf
Defines output values, making it easy to retrieve information, like IP addresses or resource IDs, after deployment.
output "vpc_id" {
value = module.network.vpc_id
}
output "instance_ips" {
value = module.compute.instance_ips
}dev. tfvars (Environment-Specific Variables)
Contains values for variables declared in variables. tf, tailored to this environment. Each environment (dev, staging, prod) will have its own .tfvars file.
vpc_cidr = "10.0.0.0/16"
instance_count = 2
instance_type = "t3.micro"Centralized Modules Repository Breakdown
Modules are organized into folders by type (e.g., network, compute) within a separate repository. This structure allows consistent usage across environments by sourcing each module from a specific version tag in the central repository.
Modules Directory Structure:
Points to consider while using modules:
Use versioned module tags.
Centralize module source in a remote repository.
Refactor modules for reusability as project scales.
Avoid hardcoding values; use variables for flexibility.
Keep module logic focused on a single responsibility.
Define clear input and output variables for each module.
Document module usage and parameters in a README.
Test modules independently before applying in environments.
With this structured approach, each team or environment can deploy, test, and update infrastructure independently.
Hope this was useful in clarifying how to structure your Terraform projects.
🔴 Get my DevOps & Kubernetes ebooks! (free for Premium Club and Personal Tier newsletter subscribers)
Looking to promote your company, product, service, or event to 48,000+ DevOps and Cloud Professionals? Let's work together.
