https://www.terraformpilot.com/categories/terraform-features/Recent content in Terraform Features on Terraform PilotHugo -- gohugo.ioen-USMon, 13 Apr 2026 00:00:00 +0000https://www.terraformpilot.com/articles/terraform-bulk-import-guide/Mon, 13 Apr 2026 00:00:00 +0000https://www.terraformpilot.com/articles/terraform-bulk-import-guide/You have 50 AWS resources created manually in the console. You need them in Terraform. The old terraform import CLI required importing one resource at a time. With import blocks (Terraform 1.5+), you can import everything in a single terraform apply and auto-generate the HCL configuration. The Bulk Import Workflow 1. Inventory existing resources (AWS CLI / console) 2. Write import blocks (one per resource) 3. Generate config automatically (-generate-config-out) 4.https://www.terraformpilot.com/articles/terraform-data-sources-explained/Mon, 13 Apr 2026 00:00:00 +0000https://www.terraformpilot.com/articles/terraform-data-sources-explained/Data sources let Terraform read information from your cloud provider or external systems without creating or managing resources. Use them to look up AMIs, reference existing VPCs, read secrets, and query anything you didn’t create with Terraform. Basic Syntax # Data source: reads, never creates data "aws_ami" "al2023" { most_recent = true owners = ["amazon"] filter { name = "name" values = ["al2023-ami-*-x86_64"] } } # Use the result resource "aws_instance" "web" { ami = data.https://www.terraformpilot.com/articles/terraform-depends-on-explained/Mon, 13 Apr 2026 00:00:00 +0000https://www.terraformpilot.com/articles/terraform-depends-on-explained/Terraform automatically determines resource ordering from references in your code. You rarely need depends_on — but when you do, it’s critical. This guide explains when implicit dependencies work, when they don’t, and when depends_on is the right tool. Implicit Dependencies (The Default) Terraform builds a dependency graph from resource references: resource "aws_vpc" "main" { cidr_block = "10.0.0.0/16" } resource "aws_subnet" "public" { vpc_id = aws_vpc.main.id # ← Reference creates implicit dependency cidr_block = "10.https://www.terraformpilot.com/articles/terraform-for-each-vs-count/Mon, 13 Apr 2026 00:00:00 +0000https://www.terraformpilot.com/articles/terraform-for-each-vs-count/Both count and for_each create multiple instances of a resource. The difference: count uses numeric indexes, for_each uses string keys. This matters more than you’d think — count can destroy your resources when you remove an item from the middle of a list. The Problem with count variable "subnet_cidrs" { default = ["10.0.1.0/24", "10.0.2.0/24", "10.0.3.0/24"] } resource "aws_subnet" "main" { count = length(var.subnet_cidrs) vpc_id = aws_vpc.main.id cidr_block = var.subnet_cidrs[count.index] } State addresses:https://www.terraformpilot.com/articles/terraform-locals-explained/Mon, 13 Apr 2026 00:00:00 +0000https://www.terraformpilot.com/articles/terraform-locals-explained/Locals are computed values within your Terraform configuration — think of them as named constants or intermediate variables. They reduce duplication, make complex expressions readable, and keep your code DRY. Basic Syntax locals { project = "myapp" environment = terraform.workspace region = "us-east-1" # Computed from other locals name_prefix = "${local.project}-${local.environment}" } resource "aws_vpc" "main" { cidr_block = "10.0.0.0/16" tags = { Name = "${local.name_prefix}-vpc" # "myapp-prod-vpc" } } Locals vs Variables Feature variable locals Set by User (tfvars, CLI, env) Terraform author (in code) Purpose Configurable inputs Computed/derived values Overridable ✅ Yes ❌ No (fixed in code) Validation ✅ validation block ❌ No Reference var.https://www.terraformpilot.com/articles/terraform-modules-best-practices/Mon, 13 Apr 2026 00:00:00 +0000https://www.terraformpilot.com/articles/terraform-modules-best-practices/Modules are Terraform’s unit of reuse — a directory of .tf files you can call from multiple places. Good modules save hours. Bad modules create more problems than they solve. Here’s how to build modules that work. Standard Module Structure modules/ └── vpc/ ├── main.tf # Resources ├── variables.tf # Input variables ├── outputs.tf # Output values ├── versions.tf # Provider and Terraform version constraints ├── README.md # Documentation └── examples/ └── basic/ └── main.https://www.terraformpilot.com/articles/terraform-variables-vs-outputs/Mon, 13 Apr 2026 00:00:00 +0000https://www.terraformpilot.com/articles/terraform-variables-vs-outputs/Variables are inputs — values passed into your configuration. Outputs are results — values exposed after terraform apply. Together they define how data flows in and out of Terraform modules. Variables (Inputs) Basic Variable variable "instance_type" { type = string description = "EC2 instance type" default = "t3.micro" } resource "aws_instance" "web" { instance_type = var.instance_type } Variable Types # String variable "environment" { type = string default = "dev" } # 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", "us-east-1c"] } # Map variable "instance_types" { type = map(string) default = { dev = "t3.https://www.terraformpilot.com/articles/terraform-ephemeral-resources-explained/Sun, 12 Apr 2026 10:00:00 +0000https://www.terraformpilot.com/articles/terraform-ephemeral-resources-explained/Ephemeral resources are a newer Terraform feature (announced at HashiDays 2025) that solves a long-standing problem: how to use secrets during a Terraform run without storing them in state. Database passwords, API tokens, session credentials — values you need during apply but don’t want persisted anywhere. The Problem With regular resources and data sources, everything goes into state: # ❌ This stores the password in terraform.tfstate! resource "random_password" "db" { length = 32 } # ❌ This stores the secret value in state too!https://www.terraformpilot.com/articles/terraform-import-block-explained/Sun, 12 Apr 2026 10:00:00 +0000https://www.terraformpilot.com/articles/terraform-import-block-explained/The import block (Terraform 1.5+) lets you bring existing infrastructure under Terraform management without CLI commands. Write it in HCL, run terraform plan, and Terraform generates the import plan. This replaces the old terraform import CLI workflow for most use cases. Import Block vs CLI Import Old Way: CLI Import # One resource at a time, imperative terraform import aws_instance.web i-0abc123def456 terraform import aws_s3_bucket.data my-bucket-name terraform import aws_vpc.main vpc-0abc123 Problems:https://www.terraformpilot.com/articles/terraform-moved-block-explained/Sun, 12 Apr 2026 10:00:00 +0000https://www.terraformpilot.com/articles/terraform-moved-block-explained/The moved block (Terraform 1.1+) lets you rename resources, move them between modules, and refactor from count to for_each — all without destroying and recreating the actual infrastructure. It’s the safe way to refactor Terraform code. Why moved Matters Without moved, renaming a resource destroys it and creates a new one: # Renaming from "web" to "app" without moved: # terraform plan # - aws_instance.web (destroy) # + aws_instance.app (create) # 😱 Your production server gets destroyed and recreated!https://www.terraformpilot.com/articles/terraform-stacks-guide/Sun, 12 Apr 2026 10:00:00 +0000https://www.terraformpilot.com/articles/terraform-stacks-guide/Terraform Stacks became generally available in late 2025 and represent the biggest new Terraform feature since workspaces. Stacks let you deploy multiple Terraform configurations as a single, coordinated unit — solving the “how do I manage networking + compute + database together?” problem that teams have worked around for years. The Problem Stacks Solve Without Stacks, deploying a full environment requires multiple terraform apply commands in the right order: # Manual orchestration — error-prone cd networking/ terraform apply # 1.