When people first start learning Terraform, they often hear that it uses something called a declarative language.
If you’re new to Infrastructure as Code, that phrase might not mean very much at first. However, understanding the difference between declarative and imperative approaches will help you understand why Terraform works the way it does.
More importantly, it explains why Terraform has become such a popular tool for managing infrastructure.
The Traditional Way: Imperative Instructions
For many years, infrastructure automation relied on what is known as an imperative approach.
An imperative approach focuses on describing the exact steps required to achieve a result. In other words, you write instructions that tell the system precisely what to do and in what order.
You can think of it like following a cooking recipe. A recipe might say something like:
- First heat the pan.
- Then add oil.
- Then add onions.
- Then cook for five minutes.
Each step happens in a specific order, and the final result depends on executing each instruction correctly.
Many scripting tools work in this way.
A script might tell the system to create a server, configure networking, install software, and then apply security settings. The script controls the entire sequence of actions.
This approach can work well, but it also introduces complexity. As environments grow, scripts often become long and difficult to maintain.
Engineers must carefully manage the order of operations, and even small changes can sometimes break the workflow.
The Terraform Approach: Declarative Infrastructure
Terraform takes a different approach. Instead of describing the steps needed to build infrastructure, Terraform focuses on describing the final state you want the infrastructure to be in.
This is called a declarative approach. Rather than writing instructions that say:
“Create a network, then create a server, then attach the server to the network.”
You simply describe the end result:
“I want a server connected to this network.”
Terraform then works out the steps required to reach that state. This might sound like a small difference, but it fundamentally changes how infrastructure is managed.
Instead of managing the process step by step, you define the desired outcome, and Terraform takes care of the rest.
A Simple Example
Consider a very simple Terraform configuration.
resource “azurerm_resource_group” “example” {
name = “terraform-demo-rg”
location = “UK South”
}
In this example, you are not telling Terraform how to build the resource group. You are simply declaring that the resource group should exist.
Terraform examines the current infrastructure, compares it with the configuration, and then determines what actions are required.
If the resource group does not exist, Terraform creates it. If it already exists and matches the configuration, Terraform does nothing.
The important point is that Terraform is always working toward the desired state described in the configuration.
Why This Matters
The declarative model solves many of the problems that appear with traditional scripting approaches.
Because Terraform understands the desired end state, it can safely determine what needs to change. It can also show you those changes before applying them, which is why the terraform plan command is so valuable.
Another major advantage is maintainability. Declarative configurations tend to be easier to read and understand because they focus on the infrastructure itself rather than the steps required to build it.
This also makes it easier for teams to collaborate. Engineers can review infrastructure definitions in the same way they review application code, and changes can be tracked using version control systems.
Letting Terraform Do the Hard Work
One of Terraform’s strengths is that it understands relationships between resources.
If a virtual machine depends on a network, Terraform automatically works out that the network must be created first. Engineers do not need to manually define every step in the process.
This allows teams to focus on what they want to build, rather than worrying about the exact order in which infrastructure must be deployed.
Terraform effectively acts as an engine that calculates the safest way to reach the desired infrastructure state.
Why Engineers Care About This Difference
At first, the difference between declarative and imperative approaches might seem subtle. In practice, it has a huge impact on how infrastructure is managed.
A declarative approach reduces complexity, improves readability, and allows automation tools to make smarter decisions about how infrastructure should change over time.
It also fits naturally with modern DevOps practices.
Infrastructure definitions can be stored in version control, reviewed by team members, and automatically deployed through pipelines.
For organizations managing large cloud environments, these advantages quickly become essential.
The Big Idea
Terraform is powerful not just because it can create infrastructure, but because of how it manages infrastructure.
By using a declarative model, Terraform allows engineers to describe the infrastructure they want, while the tool itself handles the process of building and maintaining that infrastructure.
Instead of writing complex scripts that try to control every step, engineers can focus on defining the environment clearly and letting Terraform take care of the rest.
Final Thoughts
When you understand the difference between declarative and imperative approaches, Terraform’s design starts to make much more sense.
Rather than acting like a script that performs tasks one by one, Terraform behaves more like a system that constantly works to ensure your infrastructure matches the configuration you defined.
That idea, defining infrastructure as code and allowing tools to manage the process is at the heart of modern cloud engineering.
And once you start using Terraform this way, it becomes clear why so many organizations have adopted it as a core part of their infrastructure strategy.
