Struggling with a messy Terraform DTAP workflow? I’ll break down three real-world strategies—from simple directory structures to a full GitOps promotion model—to manage your dev, test, acceptance, and prod environments without the usual headaches.

Wrestling with Terraform: A Senior Engineer’s Guide to a Sane DTAP Workflow

I still remember the Slack message. It was from a junior engineer, bless his heart, and all it said was, “Uh oh.” My blood ran cold. He’d been tasked with spinning up a new RDS instance in our dev environment. But a misplaced `terraform.tfvars` file and a hastily run `terraform apply` meant he’d just initiated a plan to modify the `prod-aurora-db-cluster`. We caught it at the approval prompt, but we were five seconds away from a very, very bad day. That incident hammered home a lesson I’d been learning for years: Terraform is an incredible tool, but without a rock-solid workflow for managing environments, you’re just piloting a bulldozer in a minefield.

First, Let’s Talk About the “Why”

The core of the problem isn’t a flaw in Terraform itself. It’s that Terraform is a declarative state machine, while DTAP (Development, Test, Acceptance, Production) is a procedural promotion model. You’re trying to fit a linear, step-by-step process onto a tool that just wants to make reality match a config file. The friction comes from managing the inevitable drift and divergence between those four environments. How do you keep the core infrastructure consistent while allowing for different instance sizes, network rules, or feature flags? How do you promote a change from Dev to Test without just copying and pasting, praying you change all the variables correctly?

Let’s break down the common ways to solve this, from the quick-and-dirty to the enterprise-grade.

Solution 1: The “Keep It Simple, Stupid” Directory Method

This is where most of us start, and honestly, for a small team or project, it’s perfectly fine. The concept is dead simple: you create a separate directory for each environment.

Your repository looks something like this:

terraform/
├── environments/
│   ├── dev/
│   │   ├── main.tf
│   │   └── terraform.tfvars
│   ├── test/
│   │   ├── main.tf
│   │   └── terraform.tfvars
│   └── prod/
│       ├── main.tf
│       └── terraform.tfvars
└── modules/
    ├── vpc/
    │   └── ...
    └── rds/
        └── ...

Each environment directory is a self-contained Terraform root. It has its own state file, its own variables, and you run `terraform apply` from within that directory. It calls shared, centralized modules to build the actual resources.

The Good, The Bad, and The Ugly

• Good: It provides maximum isolation. You literally cannot affect production from the `dev` directory. It’s easy for new team members to understand.
• Bad: The code duplication is a killer. Even if you’re using modules, the root `main.tf` files can become nearly identical. When you need to add a new resource or module call, you have to do it in four different places.
• Ugly: This model is incredibly prone to human error and configuration drift. It’s a matter of when, not if, someone updates the `dev` and `test` environments but forgets to copy the change to `prod`.

Darian’s Take: Use this method to get started, but have a plan to move off it. The moment you find yourself writing a script to “sync” the `main.tf` files across environments, you’ve outgrown this pattern.

Solution 2: The “Let’s Get Serious” Approach with Workspaces

This is the “Terraform-native” way to handle environments. Instead of separate directories, you use a single set of configuration files and leverage Terraform Workspaces to create separate state files within the same backend.

You manage the differences between environments using variable files named after your workspaces (e.g., `dev.tfvars`, `prod.tfvars`). Your `main.tf` can even reference the current workspace to make decisions.

# main.tf
resource "aws_instance" "web_server" {
  # Use a map to look up the instance type for the current workspace
  instance_type = var.instance_types[terraform.workspace]
  ami           = "ami-0c55b159cbfafe1f0" # Same AMI for all envs
  # ...
}

# dev.tfvars
instance_types = {
  default = "t3.micro"
  dev     = "t3.small"
  prod    = "m5.large"
}

# prod.tfvars
instance_types = {
  default = "t3.micro"
  dev     = "t3.small"
  prod    = "m5.2xlarge" # Override for production
}

Your workflow becomes:

1. terraform workspace select dev
2. terraform apply -var-file="dev.tfvars"

The Good, The Bad, and The Dangerous

• Good: It’s DRY (Don’t Repeat Yourself). You have one set of infrastructure code to maintain, which is a huge win for consistency.
• Bad: The mental overhead is higher. You have to be constantly aware of which workspace you’re in.
• Dangerous: The command terraform workspace select prod followed by a `terraform apply` is one of the most powerful—and therefore dangerous—combinations in an operator’s toolkit. A single mistake can have massive consequences.

Warning: If you use workspaces, you MUST have CI/CD guardrails. Your pipeline should select the workspace automatically based on the Git branch. Humans should rarely, if ever, be running `apply` against production from their laptops.

Solution 3: The “Endgame” – A Full GitOps Promotion Model

This is where we are at TechResolve, and it’s the gold standard for mature teams. In this model, Git is the single source of truth, and the promotion of code from one environment to the next is handled entirely through your Git workflow (pull requests, merges, etc.).

We use a tool called Terragrunt to keep our configuration DRY, but you can achieve this with CI/CD scripting and workspaces too. The core concept is tying Git branches to environments.

A change is introduced in a feature branch. A pull request to `develop` runs a `terraform plan` for the dev environment. When that PR is merged, the pipeline runs `terraform apply` against dev. To promote that change to Test/Acceptance, you open a new PR from `develop` to `staging`. The same cycle repeats, providing a clear, auditable, and peer-reviewed path to production.

The Good, The Bad, and The Bureaucratic

• Good: Maximum safety and auditability. Every infrastructure change is tied to a pull request. Rollbacks are as simple as reverting a Git commit.
• Bad: The setup complexity is high. You need a robust CI/CD platform (GitHub Actions, GitLab CI, Jenkins) and the discipline to stick to the process.
• Bureaucratic: This can feel slow. A one-line change to a dev environment might require a PR and an approval, which can frustrate developers who want to move fast. It’s a trade-off between speed and safety.

Pro Tip: Don’t try to jump straight to this model. Start with Directory or Workspace separation. Build the discipline on your team first. A GitOps workflow is a cultural shift, not just a technical one. The goal is to make the safe way the easy way.

Ultimately, there’s no single perfect answer. The right DTAP workflow depends on your team’s size, risk tolerance, and maturity. But whatever you choose, choose deliberately. Because the only thing worse than a complex Terraform workflow is not having one when you get that “Uh oh” message.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions