Terraform has become the default way to define and roll out cloud infrastructure across AWS, GCP, Azure, and Kubernetes. The tool works on a simple principle: define the infrastructure you want in code, and let the tool handle the API calls to build or update it. Everything is written in HCL, which is easy to read and keeps the workflow consistent across platforms. The provider system is what makes Terraform practical in real environments. In enterprise practice, Terraform configuration management is not only about provisioning new resources. It is about codifying existing estates, preventing drift, and establishing a clear separation of concerns with configuration management tools such as Ansible.
Terraform Language and Core Principles
Terraform language is the primary user interface for Terraform CLI, HCP Terraform, and Terraform Enterprise. Configuration files written in Terraform language tell Terraform what plugins to install, what infrastructure to create, and what data to fetch. Terraform language also lets you define dependencies between resources and create multiple similar resources from a single configuration block.
The main purpose of the Terraform language is declaring resources, which represent infrastructure objects. All other language features exist only to make the definition of resources more flexible and convenient.
A Terraform configuration is a complete document in the Terraform language that tells Terraform how to manage a given collection of infrastructure. A configuration can consist of multiple files and directories.
The syntax of the Terraform language consists of only a few basic elements:
resource "aws_vpc" "main" {
cidr_block = var.base_cidr_block
}
The general block form is:
```
Block body
}
```
Blocks are containers for other content and usually represent the configuration of some kind of object, like a resource.
Terraform is often called API as Code. It can manage any infrastructure, track changes, and automate the deployment process.
Terraform helps:
- Manage any infrastructure: Cloud, on-premises, etc.
- Track your infrastructure: Keeps a record of all changes.
- Automate changes: Makes applying changes simpler and more reliable.
- Standardize configurations: Ensures consistency across environments.
- Collaborate easily: Teams can work together on infrastructure changes.
The common workflow is:
- Write: Define your infrastructure in code.
- Plan: Preview the changes before applying them.
- Apply: Deploy the changes.
- Destroy: Tear down the infrastructure when it is no longer needed.
A basic Terraform configuration to provision an AWS EC2 instance is:
provider "aws" {
region = "us-west-2"
}
resource "aws_instance" "web" {
ami = "ami-0c55b159cbfafe1f0"
instance_type = "t2.micro"
tags = {
Name = "MyWebServer"
}
}
Initialize the Terraform working directory
terraform init
Preview the changes Terraform will make
terraform plan
Apply the changes to create the infrastructure
terraform apply
Destroy the infrastructure when it is no longer needed
terraform destroy
Terraform maintains a state file terraform.tfstate that acts as the source of truth for your infrastructure. This file should not be stored in version control, as it can lead to security risks and issues with syncing.
Market Position and Enterprise Reality
Terraform holds 34.28% of the configuration management market, and for most engineering teams, it is the default way to define and roll out cloud infrastructure across AWS, GCP, Azure, and Kubernetes. But in real enterprise environments, Terraform rarely covers everything. Large portions of production, built years ago through consoles, CLIs, or older automation, sit outside code, creating a mixed estate with both managed and unmanaged resources.
When only new infrastructure is in Terraform, you lose IaC core benefits: auditability, drift detection, consistency, and predictable deployments. The real requirement for true IaC is simple: every resource must be codified, in state, and reproducible from code alone.
It prevents one-off patterns and ensures that every environment, regardless of who requested it, follows the same module design, tagging, IAM policies, and networking rules.
Codification, Imports, and State Management
The biggest blocker to full codification is imports. Traditional terraform import is slow, manual, and does not generate configuration, making it nearly impossible to codify existing environments at scale. This post breaks down where Terraform workflows start failing in large estates and how modern import workflows, including Terraform Import Blocks and automated tooling, finally make full codification realistic.
Terraform manages resource creation and updates based on what is defined in the configuration and stored in the state. What it does not do is track everything that happens to those resources after they are deployed. Cloud platforms allow direct edits through their consoles, APIs, and other automation. Those changes do not pass through Terraform, and nothing updates the configuration or the state automatically. Over time, this creates mismatches in configuration, data exposure risks, and cost behaviour that the Terraform workflow is not aware of.
| Concern | Terraform Responsibility | Gap |
|---|---|---|
| Resource creation | Instance creation, network topology, security groups, managed services | Direct console edits bypass code |
| Configuration inside OS | Package installation, config files, service management | Outside Terraform scope |
| State consistency | terraform.tfstate as source of truth | Must not be stored in version control |
| Full estate coverage | Import blocks and automated tooling | Traditional import is manual and does not generate config |
Drift, Secrets, and Cost Control Gaps
Drift appears whenever the live configuration in AWS, GCP, or Azure no longer matches what Terraform expects. Terraform can detect this through terraform plan, but only when someone runs it.
Handling the gaps Terraform does not cover requires drift detection and remediation processes, secrets management outside state, and cost controls that are enforced through policy as code.
Terraform continuously monitors for any drift from the intended infrastructure state and manages the decommissioning of resources when they are no longer needed. Drift detection is a core configuration management concern because unmanaged changes undermine auditability and predictable deployments.
Terraform and Ansible Division of Responsibilities
Terraform and Ansible serve complementary roles in infrastructure automation. Terraform excels at provisioning and managing cloud resources - creating VMs, networks, databases, and load balancers. Ansible excels at configuration management - installing software, managing configuration files, and ensuring the desired state of operating systems and applications. Used together, they form a powerful end-to-end automation pipeline.
The key to a successful Terraform-Ansible integration is a clear separation of concerns. Terraform should handle everything that the cloud provider API controls: instance creation, network topology, security groups, and managed services. Ansible should handle everything inside the operating system: package installation, configuration file management, service management, and application deployment.
Blurring this boundary leads to problems. Using Terraform provisioners to install software creates fragile, hard-to-debug configurations.
Ansible is a configuration management tool that executes playbooks, which are lists of customizable actions written in YAML on specified target servers. It can perform all bootstrapping operations, like installing and updating software, creating and removing users, and configuring system services. As such, it is suitable for bringing up servers you deploy using Terraform, which are created blank by default.
Ansible and Terraform are not competing solutions, because they resolve different phases of infrastructure and software deployment. Terraform allows you to define and create the infrastructure of your system, encompassing the hardware that your applications will run on. Conversely, Ansible configures and deploys software by executing its playbooks on the provided server instances. Running Ansible on the resources Terraform provisioned directly after their creation allows you to make the resources usable for your use case much faster. It also enables easier maintenance and troubleshooting, because all deployed servers will have the same actions applied to them.
In a typical tutorial pattern, you deploy Droplets using Terraform, and then immediately after their creation, you bootstrap the Droplets using Ansible. You invoke Ansible directly from Terraform when a resource deploys.
Day 0 Day 1 Day 2 Operational Model
Terraform and Ansible are often described through Day 0, Day 1, and Day 2 operations.
Day 0: Terraform is excellent at provisioning infrastructure. It can prepare and provision complex resource architectures, including servers, networks, storage, etc., according to pre-written infrastructure as code files. Terraform excels at going from nothing to something.
Day 1: Ansible excels at configuration management. It can modify and maintain existing infrastructure consistently with infrastructure as code files.
Day 2 after deployment is where most operational burden happens. Both products also have use cases for Day 2:
Day 2: Terraform and Ansible work together to keep your infrastructure healthy over time, and ensure smooth decommissioning when resources are no longer needed.
Terraform continuously monitors for any drift from the intended infrastructure state and manages the decommissioning of resources when they are no longer needed. Ansible helps with tasks like health checks, updates, and patching for the application and operating system, as well as automating incident response.
However, challenges can arise when Day 2 operations, particularly those involving modifications to resources managed by Terraform, occur outside of the Terraform workflow.
| Phase | Primary Tool | Focus |
|---|---|---|
| Day 0 Provisioning | Terraform | Create VMs, networks, databases, load balancers from nothing |
| Day 1 Configuration | Ansible | Package install, config files, service management inside OS |
| Day 2 Operations | Terraform + Ansible | Drift remediation, health checks, updates, patching, decommissioning |
Integration Patterns and Best Practices
A successful integration guide shows how to integrate Terraform and Ansible effectively, covering several patterns from simple to advanced.
Understanding the division of responsibilities prevents one-off patterns and ensures that every environment follows the same module design, tagging, IAM policies, and networking rules.
When Terraform and Ansible are used together, Terraform should be used to provision infrastructure and Ansible to configure it. Running Ansible on the resources Terraform provisioned directly after their creation makes resources usable faster and enables consistent maintenance.
Avoid using Terraform provisioners for software installation. That blurs the boundary and creates fragile, hard-to-debug configurations. Keep Terraform focused on the cloud provider API and Ansible focused on the operating system and application layer.
State management remains critical. The terraform.tfstate file acts as source of truth and should not be stored in version control. For large estates, import workflows and automated tooling make full codification realistic, reducing unmanaged resources that sit outside code.
Conclusion
Terraform configuration management is about more than writing resource blocks. It requires codifying entire estates, managing state with care, detecting drift, and accepting the limits of what Terraform tracks after deployment. Terraform provides a consistent HCL language for declaring resources, a provider system for multi-cloud support, and a plan-apply-destroy workflow that makes deployments reproducible.
In practice, Terraform rarely covers everything on its own. Mixed estates with legacy resources built through consoles and CLIs remain a blocker until imports and automated codification tooling are applied. True IaC demands every resource be codified, in state, and reproducible from code alone.
Configuration management inside the operating system is a separate concern best handled by Ansible. Terraform provisions blank infrastructure; Ansible configures it. The clear separation of concerns between Day 0 provisioning and Day 1 configuration, with shared responsibility for Day 2 operations, creates an end-to-end automation pipeline that preserves auditability, drift detection, consistency, and predictable deployments.
Sources
- Firefly.ai Terraform IaC Academy
- Terraform Language Documentation
- How to Use Terraform with Ansible for Configuration Management
- Understanding Configuration Management and Infrastructure as Code with Ansible and Terraform
- How to Use Ansible with Terraform for Configuration Management
- Terraform Ansible Unifying Infrastructure Provisioning Configuration Management