Putting It All Together: Application and Infrastructure Workflows with Terraform
After three weeks of building, breaking, and rebuilding infrastructure, this is where everything finally connects.
Version control. Testing. CI/CD. Terraform Cloud. Sentinel policies. Cost estimation.
Individually, these are useful tools. Together, they form a coherent system for safely delivering infrastructure at scale.
This post walks through how application and infrastructure workflows converge into a single pipeline—and why the concept of immutable artifact promotion is the most important shift in thinking.
🔧 The Integrated Pipeline
At the core of this system is a CI pipeline that runs on every pull request.
For infrastructure, the pipeline enforces a strict sequence:
Format check
Initialization
Validation
Unit testing (
terraform test)Execution plan generation
By the time a pull request is reviewed, we already know:
The code is syntactically correct
The configuration is valid
The modules behave as expected
The infrastructure changes are fully visible
The critical output here is not just validation—it’s the plan file:
terraform plan -out=ci.tfplan
This file becomes the foundation of everything that follows.
📦 Immutable Artifact Promotion
In traditional workflows, infrastructure is re-evaluated at each environment:
You run
terraform planin stagingThen again in production
Hoping nothing changes in between
That assumption is fragile.
Instead, this workflow introduces a much stronger guarantee:
The exact same plan that was reviewed is the one that gets applied.
The .tfplan file is treated as an immutable, versioned artifact:
Generated once in CI
Stored and reviewed
Promoted across environments
Applied without modification
This mirrors how application code works:
Build a Docker image once
Promote it through staging → production
Never rebuild it mid-way
Result: No drift. No surprises. No “it worked in staging but failed in production.”
🛡️ Policy as Code with Sentinel
Automation without guardrails is dangerous. That’s where Sentinel comes in.
1. Enforcing Terraform Ownership
Every resource must include:
ManagedBy = "terraform"
This policy ensures:
No unmanaged resources
Full traceability
Clean ownership boundaries
If a resource is missing this tag, the run fails immediately.
2. Cost Estimation Gate
Before any infrastructure change is applied, Terraform Cloud evaluates:
“How much will this cost?”
A Sentinel policy enforces a simple rule:
- If the monthly cost increase exceeds a defined threshold → block the run
Example:
Small change → passes automatically
Large scaling change → requires review
This introduces something most teams lack:
Financial accountability built directly into the deployment pipeline
⚙️ Where Application and Infrastructure Meet
At this point, the workflows look almost identical.
| Stage | Application | Infrastructure |
|---|---|---|
| Source | Git | Git |
| Validation | Tests | terraform validate + tests |
| Artifact | Docker image | .tfplan file |
| Policy | Linting / SAST | Sentinel |
| Promotion | Image across envs | Plan across envs |
| Deployment | Container runtime | terraform apply |
This is the key realization:
Infrastructure is no longer “configured”—it is engineered, tested, versioned, and promoted.
🧠 Reflection: What Actually Changed
1. What Clicked
The biggest shift was understanding artifacts over environments.
I used to think in terms of:
“Deploy to staging”
“Then deploy to production”
Now I think:
“Build once”
“Promote the exact same thing everywhere”
That applies to both applications and infrastructure.
2. What Broke
Two things consistently caused friction:
State management
Remote state introduces coordination challenges
Locking, drift, and conflicts are real concerns
Module design
Writing reusable modules is harder than writing raw Terraform
Poor design leads to tight coupling and painful refactoring
3. What Surprised Me
How similar infrastructure workflows are to application workflows—once done properly.
Before this, infrastructure felt:
Manual
Fragile
Hard to reason about
Now it feels:
Predictable
Testable
Governed
4. What I Would Do Differently
If I started again:
Set up remote state on Day 1
Introduce modules much earlier
Design environments before writing resources
Treat CI/CD as mandatory, not optional
Most of the early mistakes came from treating Terraform as a tool—not a system.
5. What Comes Next
The next step is applying this to a real-world project:
Containerized application deployment
Full CI/CD pipeline
Terraform-managed infrastructure
Policy enforcement via Sentinel
Cost-aware deployments
The goal is not just to deploy infrastructure—but to build a repeatable, governed platform.
🧩 Final Insight
If there is one idea to carry forward, it’s this:
You do not deploy infrastructure changes—you promote infrastructure artifacts.
That single shift:
Eliminates inconsistency
Reduces risk
Aligns infrastructure with modern software practices
🔚 Closing
Most engineers learn Terraform as a provisioning tool.
But at scale, Terraform is not about provisioning—it’s about:
Workflow design
Risk management
Policy enforcement
System thinking
That’s what this journey has really been about.
