Terraform's declarative approach - Deep Dive

Overview - Terraform's declarative approach

What is it?

Terraform's declarative approach means you describe the desired end state of your cloud infrastructure, not the steps to get there. You write configuration files that say what resources you want, like servers or databases, and Terraform figures out how to create or change them. This way, you focus on the 'what' instead of the 'how'.

Why it matters

Without a declarative approach, managing infrastructure would be like giving someone step-by-step instructions every time you want a change, which is slow and error-prone. Declarative infrastructure lets you automate and repeat setups reliably, saving time and avoiding mistakes. It makes cloud management predictable and scalable, which is crucial for modern applications.

Where it fits

Before learning this, you should understand basic cloud concepts like virtual machines and networks. After this, you can learn about Terraform modules, state management, and advanced automation techniques to manage complex infrastructure efficiently.

Mental Model

Core Idea

You tell Terraform what you want your infrastructure to look like, and it figures out how to make it so.

Think of it like...

It's like telling a GPS your destination instead of giving it turn-by-turn directions; the GPS finds the best route for you.

Desired State (You) ──> Terraform ──> Actual Infrastructure
┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│ Configuration │──────▶│ Terraform     │──────▶│ Cloud Provider│
│ (Desired End) │       │ Engine        │       │ (Actual State)│
└───────────────┘       └───────────────┘       └───────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding Desired State Concept

Concept: Learn what it means to declare the desired state of infrastructure.

Imagine you want a house with 3 rooms and a garden. Instead of telling builders how to build each wall, you just say 'I want a 3-room house with a garden.' This is the desired state. Terraform uses this idea for cloud resources.

Result

You understand that you specify what you want, not how to build it.

Understanding desired state shifts your mindset from manual steps to goal-oriented configuration.

2

Foundation

Terraform Configuration Files Basics

Concept: Learn how to write simple Terraform files that declare resources.

Terraform uses files ending with .tf where you write blocks like 'resource "aws_instance" "web" { ... }' to declare a server. These files describe what you want in simple language.

Result

You can write a basic Terraform file that declares a resource.

Knowing how to declare resources is the first step to using Terraform's declarative power.

3

Intermediate

Terraform Plan and Apply Workflow

🤔Before reading on: Do you think Terraform immediately changes your cloud when you write config, or does it check first? Commit to your answer.

Concept: Learn how Terraform previews changes before applying them.

When you run 'terraform plan', Terraform compares your desired state with the current cloud state and shows what will change. 'terraform apply' then makes those changes happen.

Result

You can safely preview changes and understand their impact before applying.

Knowing the plan step prevents surprises and helps maintain control over infrastructure changes.

4

Intermediate

State File Role in Declarative Approach

🤔Before reading on: Is Terraform's state stored in the cloud provider or locally by default? Commit to your answer.

Concept: Understand how Terraform tracks current infrastructure state.

Terraform keeps a state file that records what resources it manages and their current status. This file helps Terraform know what exists and what needs to change to reach the desired state.

Result

You understand how Terraform remembers your infrastructure between runs.

Knowing about state files explains how Terraform bridges your config and real cloud resources.

5

Intermediate

Idempotency in Terraform

🤔Before reading on: If you run 'terraform apply' twice with no changes, will Terraform make changes again? Commit to your answer.

Concept: Learn that Terraform only makes changes when needed.

Terraform is idempotent, meaning running apply multiple times without config changes won't alter your infrastructure again. It ensures stability and predictability.

Result

You trust Terraform to avoid unnecessary changes.

Understanding idempotency is key to safe, repeatable infrastructure management.

6

Advanced

Handling Drift with Declarative Configurations

🤔Before reading on: Do you think Terraform automatically fixes changes made outside it, or do you need to intervene? Commit to your answer.

Concept: Learn how Terraform detects and manages changes made outside its control.

If someone changes cloud resources manually, Terraform detects this as drift during 'terraform plan'. You can then decide to apply your config to fix it or update your config to match reality.

Result

You can maintain consistent infrastructure even with manual changes.

Knowing how to handle drift prevents configuration mismatches and outages.

7

Expert

Terraform's Dependency Graph and Execution

🤔Before reading on: Does Terraform create resources in the order you write them, or does it decide order based on dependencies? Commit to your answer.

Concept: Understand how Terraform builds and uses a graph to manage resource creation order.

Terraform analyzes resource dependencies to build a graph. It then creates or updates resources in the correct order automatically, even if your config order is different. This ensures resources are ready when others depend on them.

Result

You understand how Terraform manages complex infrastructure safely and efficiently.

Knowing the dependency graph explains how Terraform handles complex setups without manual ordering.

Under the Hood

Terraform reads your configuration files and builds an internal model of the desired infrastructure. It then compares this model with the current state stored in the state file. Using this comparison, Terraform creates a dependency graph to determine the order of operations. It generates an execution plan that includes creating, updating, or deleting resources. When you apply, Terraform calls cloud provider APIs to make the changes and updates the state file accordingly.

Why designed this way?

Terraform was designed to simplify infrastructure management by focusing on the end goal rather than procedural steps. This declarative model reduces human error and makes automation easier. The dependency graph and state file were introduced to handle complex infrastructures reliably and to enable safe, repeatable changes. Alternatives like imperative scripts were error-prone and hard to maintain.

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│ Configuration │──────▶│ Internal Model│──────▶│ Dependency    │
│ Files (.tf)   │       │ & Desired     │       │ Graph Builder │
└───────────────┘       │ State        │       └───────────────┘
                        └──────┬────────┘               │
                               │                        ▼
                        ┌───────────────┐       ┌───────────────┐
                        │ Compare with  │──────▶│ Execution     │
                        │ Current State │       │ Plan          │
                        └───────────────┘       └──────┬────────┘
                                                       │
                                                       ▼
                                              ┌───────────────┐
                                              │ Apply Changes │
                                              │ via Provider  │
                                              └───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does Terraform immediately change your cloud when you save a config file? Commit to yes or no.

Common Belief: Terraform changes cloud resources as soon as you write or save the configuration files.

Reality: Terraform only changes resources when you run 'terraform apply'. Writing config files alone does nothing to the cloud.

Why it matters: Believing this can cause confusion and mistakes, like expecting immediate changes or thinking your cloud is updated without applying.

Quick: Can Terraform manage resources it did not create? Commit to yes or no.

Common Belief: Terraform can manage any cloud resource, even if it was created manually outside Terraform.

Reality: Terraform can import existing resources into its state, but it cannot manage resources it doesn't know about or that are not in its state file.

Why it matters: Assuming Terraform manages all resources can lead to unmanaged drift and unexpected infrastructure states.

Quick: If you manually change a resource in the cloud, will Terraform automatically fix it next time? Commit to yes or no.

Common Belief: Terraform automatically corrects any manual changes made outside its control during apply.

Reality: Terraform detects drift but only changes resources if you run 'terraform apply' after updating the config or state. It does not auto-correct without your command.

Why it matters: Thinking Terraform auto-fixes drift can cause unnoticed inconsistencies and outages.

Quick: Does the order of resource blocks in Terraform config files determine creation order? Commit to yes or no.

Common Belief: Terraform creates resources in the order they appear in the configuration files.

Reality: Terraform uses a dependency graph to decide creation order, ignoring the order in config files.

Why it matters: Misunderstanding this can cause confusion when resources are created in unexpected sequences.

Expert Zone

1

Terraform's state file can be stored remotely to enable team collaboration and prevent conflicts, but managing state locking is crucial to avoid race conditions.

2

The dependency graph not only orders resource creation but also detects implicit dependencies through references, reducing manual dependency declarations.

3

Terraform's declarative approach allows partial updates, but complex changes sometimes require manual intervention or resource replacement, which can cause downtime.

When NOT to use

Terraform's declarative approach is less suitable for very dynamic or ephemeral infrastructure that changes rapidly and unpredictably, where imperative tools or configuration management systems like Ansible might be better. Also, for simple one-off scripts, direct cloud CLI commands may be faster.

Production Patterns

In production, Terraform is used with modules to reuse and organize code, remote state backends with locking for team safety, and CI/CD pipelines to automate plan and apply steps with approval gates. Drift detection and state versioning are monitored to maintain infrastructure integrity.

Connections

Version Control Systems

Both use declarative descriptions to manage state over time.

Understanding how Git tracks file states helps grasp how Terraform tracks infrastructure state and changes.

Database Schema Migration

Both manage desired end states and generate plans to migrate from current to desired states.

Knowing database migration tools clarifies how Terraform plans and applies incremental infrastructure changes safely.

Project Management

Declarative planning in Terraform is like setting project goals and milestones rather than micromanaging tasks.

Recognizing this helps appreciate the efficiency and clarity gained by focusing on outcomes instead of procedures.

Common Pitfalls

#1 Applying changes without reviewing the plan.

Wrong approach:

terraform apply

Correct approach:

terraform plan
# Review output
terraform apply

Root cause:

Assuming Terraform will always make safe changes without verifying can cause unintended resource deletions or modifications.

#2 Editing cloud resources manually without updating Terraform state.

Wrong approach:

Manually changing a server's configuration in the cloud console and not running 'terraform import' or updating config.

Correct approach:

Use 'terraform import' to bring manual changes into Terraform state or update configuration files accordingly.

Root cause:

Not understanding that Terraform only manages resources it knows about leads to drift and inconsistent infrastructure.

#3 Committing local state files to version control.

Wrong approach:

Adding terraform.tfstate to Git repository.

Correct approach:

Use remote state backends like S3 or Terraform Cloud and exclude local state files from version control.

Root cause:

Misunderstanding state file sensitivity and collaboration needs causes conflicts and security risks.

Key Takeaways

Terraform's declarative approach means you describe what you want, not how to do it.

Terraform uses a state file and dependency graph to safely and efficiently manage infrastructure changes.

The plan step lets you preview changes before applying, preventing surprises.

Terraform detects drift but only changes resources when you explicitly apply updates.

Understanding Terraform's internals helps avoid common mistakes and use it effectively in production.