Terraform Basics Providers and State

Introduction

Infrastructure automation has become essential in modern network engineering. Manually configuring devices through a GUI — sometimes called Click-Ops — is slow, error-prone, and difficult to scale. A single misclick buried several levels deep in a configuration menu can introduce inconsistencies that take hours to troubleshoot. Terraform offers a fundamentally different approach: you describe the infrastructure you want in code, and Terraform builds it for you.

In this lesson you will learn the foundational concepts behind Terraform, including what makes it unique as an infrastructure-as-code tool, how providers connect Terraform to the platforms you manage, and how the state file keeps track of everything Terraform has created or changed. By the end you will understand the core Terraform workflow — init, plan, apply, and destroy — and be ready to write your first configuration file.

Key Concepts

What Is Terraform?

Terraform is an infrastructure-as-code tool that lets you define, provision, and manage infrastructure using simple configuration files. Several characteristics set it apart from other automation approaches:

• Agentless — Terraform does not require any software to be installed on the devices or platforms it manages. It communicates through APIs and providers.
• Declarative — You describe the intended goal (the desired state of your infrastructure) rather than writing step-by-step procedures to reach that goal. Terraform figures out what actions are needed.
• Stateful — Terraform keeps track of every change it makes in a state file, so it always knows the current condition of the infrastructure it manages.
• No special programming skills required — While basic knowledge of scripting and configuration concepts is helpful, Terraform uses its own simple configuration language (HCL) that is straightforward to learn.

Note: Terraform was originally open source under the Mozilla Public License (MPL 2.0). HashiCorp has since changed the license to the Business Source License (BSL). This does not affect your ability to learn and use Terraform, but it is worth being aware of when evaluating it for production use.

Terraform vs. Click-Ops

A natural question is: why use Terraform when platforms like Catalyst SD-WAN Manager already provide orchestration and automation through their own GUI? The answer comes down to standardization, repeatability, and scale.

Approach	Strengths	Weaknesses
Click-Ops (GUI)	Visual, intuitive for small changes	Error-prone at scale, no version control, hard to replicate
Terraform (IaC)	Repeatable, version-controlled, consistent	Requires learning HCL, initial setup effort

Key advantages of moving away from Click-Ops:

• Eliminate manual errors — It is incredibly easy to make a mistake when you are nested several levels deep in a GUI entering data by hand.
• Ensure standardization — Reusable code blocks guarantee consistent implementations every time. Deviations from standards become easy to spot.
• Reduce configuration complexity — Do you really need multiple policy profiles doing the same thing in multiple places? Terraform encourages you to consolidate and simplify.
• Reduce troubleshooting time — Simpler, standardized systems are easier to troubleshoot.
• Scale your team — When you can easily repeat a task the same way every time, you get more done in less time and more often. Project timelines shrink and your team capacity grows.

Core Terraform Terminology

The four commands below represent the essential Terraform workflow. Every Terraform project follows this sequence:

Command	Purpose
terraform init	Downloads provider plugins and initializes the working directory
terraform plan	Determines the required actions to achieve the desired state — a dry-run that shows what will change without making changes
terraform apply	Applies the configuration to the infrastructure — executes the plan
terraform destroy	Destroys all infrastructure managed by Terraform

Best Practice: Always run terraform plan before terraform apply. The plan output lets you review every proposed change and catch mistakes before they reach your infrastructure.

How It Works

The Terraform Workflow

Terraform operates through a straightforward lifecycle:

1. Write — You create configuration files (.tf files) that declare the resources you want. These files specify a provider (the platform you are targeting) and the resources you want to create or manage.
2. Initialize — Running terraform init downloads the necessary provider plugins. For Cisco infrastructure, providers exist for IOS-XE, ACI, MSO (Nexus Dashboard Orchestrator), and Catalyst SD-WAN, among others.
3. Plan — Running terraform plan compares your declared configuration against the current state file. Terraform calculates exactly which resources need to be created, modified, or deleted to reach the desired state.
4. Apply — Running terraform apply executes the planned changes against the real infrastructure through the provider APIs.
5. Destroy — When infrastructure is no longer needed, terraform destroy removes everything Terraform created. In production network contexts, this command is used with extreme caution.

Providers

A provider is a plugin that tells Terraform how to communicate with a specific platform or service. Each provider exposes a set of resources and data sources that Terraform can manage.

For Cisco infrastructure, several providers are available:

Provider	Platform	Use Case
CiscoDevNet/iosxe	Cisco IOS-XE	Managing Catalyst switches and routers
CiscoDevNet/aci	Cisco ACI	Data center fabric automation
CiscoDevNet/mso	Nexus Dashboard Orchestrator	Multi-site ACI orchestration
Cisco SD-WAN Provider	Catalyst SD-WAN	WAN edge and policy automation

Each provider is downloaded automatically when you run terraform init, as long as it is declared in your configuration file.

The State File

The state file is one of Terraform's most important concepts. It is a JSON file (typically named terraform.tfstate) that stores information about every piece of managed infrastructure.

Terraform acts as a resource manager for the infrastructure you describe. It uses the state file to:

• Track which resources currently exist
• Map resources in your configuration to real-world objects
• Determine what changes are needed on the next terraform plan or terraform apply
• Detect drift between your declared configuration and the actual infrastructure

Warning: The state file often contains sensitive information such as IP addresses, credentials, and resource identifiers. In team environments, store it in a secure remote backend rather than leaving it on a local workstation.

Configuration Example

Below is an example Terraform configuration that demonstrates the basic structure of a .tf file. This example provisions cloud infrastructure, but the structural concepts — provider blocks, resource blocks, and output blocks — apply identically when working with Cisco providers.

Declaring a Provider

The provider block tells Terraform which platform to target and supplies any required connection parameters:

provider "aws" {
  region = "us-east-1"
}

When working with Cisco IOS-XE, the provider block would reference the CiscoDevNet/iosxe provider instead and include device connection details.

Defining Resources

A resource block declares a single piece of infrastructure. Each resource has a type and a local name that you reference elsewhere in the configuration:

resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.xlarge"

  tags = {
    Name = "MyTerraformInstance"
  }
}

In this example, aws_instance is the resource type and web is the local name. The arguments inside the block — ami, instance_type, and tags — define the desired configuration of the resource.

Defining Outputs

An output block extracts useful information from your managed infrastructure so you can reference it later or display it after a successful apply:

output "instance_ip" {
  value = aws_instance.web.public_ip
}

This output would display the public IP address assigned to the instance after terraform apply completes.

A More Complete Example with Networking

The following expanded example shows how Terraform manages networking constructs such as VPCs, subnets, and security groups:

resource "aws_vpc" "main_vpc" {
  cidr_block = "10.0.0.0/16"
}

resource "aws_subnet" "public_subnet" {
  vpc_id     = aws_vpc.main_vpc.id
  cidr_block = "10.0.1.0/24"
}

resource "aws_subnet" "private_subnet" {
  vpc_id     = aws_vpc.main_vpc.id
  cidr_block = "10.1.2.0/24"
}

resource "aws_security_group" "main_sg" {
  vpc_id = aws_vpc.main_vpc.id
}

resource "aws_instance" "web_server" {
  ami            = "ami-0a897ba00eaed7398"
  instance_type  = "t2.micro"
  private_ip     = "10.1.2.100"
  subnet_id      = aws_subnet.private_subnet.id
  security_groups = [aws_security_group.main_sg.id]
}

Notice how resources reference each other — aws_subnet.private_subnet.id passes the subnet identifier into the instance configuration. Terraform automatically determines the correct order of operations based on these dependencies.

Running the Workflow

After writing your configuration, the commands are executed in order:

terraform init
terraform plan
terraform apply

The init command downloads the provider plugin. The plan command shows a detailed preview of all changes. The apply command executes those changes against the target infrastructure.

Real-World Application

When to Use Terraform for Cisco Infrastructure

Terraform becomes most valuable in environments where consistency, repeatability, and scale matter:

• Multi-site SD-WAN deployments — Use the Catalyst SD-WAN Terraform provider to define edge device configurations, policies, and templates as code. Deploy identical configurations across dozens or hundreds of sites without touching the GUI.
• ACI fabric automation — Manage tenants, VRFs, bridge domains, and contracts through the ACI provider. Track every change in version control alongside your Terraform state.
• IOS-XE device management — Push standardized configurations to Catalyst switches and routers, ensuring every device matches the approved baseline.
• Lab environment provisioning — Stand up and tear down lab environments quickly using terraform apply and terraform destroy. Tools like the SD-WAN Lab Deployment Tool for Cisco Modeling Labs leverage this pattern.

Design Considerations

• Start small — Begin by managing a single resource type (for example, ACI tenants) before expanding to full fabric automation.
• Use version control — Store your .tf files in Git. This gives you a complete history of every infrastructure change and enables code review before applying changes.
• Be cautious with destroy — In production network contexts, terraform destroy removes all managed infrastructure. This is not a command you use casually.
• Watch for multi-repository complexity — When Terraform configurations span multiple repositories, updates are not correlated. Multiple changes in single pull requests can make it difficult for review tools to assess impact. Keep related configurations together.
• Secure your state — The state file contains a complete map of your infrastructure. Treat it as sensitive data and store it in a remote backend with access controls.

Summary

• Terraform is an agentless, declarative, stateful infrastructure-as-code tool that eliminates the errors and inefficiencies of manual GUI-based configuration (Click-Ops).
• The core workflow follows four commands: terraform init to download providers, terraform plan to preview changes, terraform apply to execute changes, and terraform destroy to remove infrastructure.
• Providers are plugins that connect Terraform to specific platforms — Cisco offers providers for IOS-XE, ACI, Nexus Dashboard Orchestrator, and Catalyst SD-WAN.
• The state file tracks all managed infrastructure, enabling Terraform to detect drift and calculate the minimal set of changes needed on each run.
• Standardizing infrastructure as code reduces troubleshooting time, simplifies implementations, and allows your team to accomplish more in less time.

In the next lesson, we will dive into writing Terraform configurations for Cisco platforms, exploring provider setup and resource definitions in detail.