What happens when your company needs to set up 50 identical networks across different regions—but doing it by hand would take weeks and inevitably cause mistakes? That's exactly the problem Terraform solves. For the DevNet Associate exam, you need to understand how Terraform lets you describe your entire network infrastructure as code, so you can build, change, and destroy it predictably, all from a single set of files.
Jump to a section
A simple way to picture Terraform and Infrastructure as Code for Networking
When you buy a house, the builder doesn't start hammering nails randomly. First, your architect draws a detailed blueprint—a precise plan for every wall, wire, and pipe. That blueprint exists as a digital file. Now, imagine you want to add a second floor. Instead of tearing down walls and guessing, you edit the digital blueprint, save it, and the builder executes exactly what's drawn. No mistakes, no forgotten rooms, no arguments later.
This is exactly how Terraform works for computer networks. Your network has routers, firewalls, virtual servers—each like a room or pipe in a house. In the old way, an IT person would manually click through web pages to add each piece, like a builder hammering each nail by hand. That's slow and error-prone. With Terraform, you write a "blueprint" file—called a configuration file—that describes exactly what your network should look like: five virtual machines, two subnets, one firewall rule allowing web traffic. When you press go, Terraform reads that file and builds everything automatically, in the right order. The crucial part is this file becomes the single source of truth. If someone later wants to change something, they don't click around—they edit the file. And Terraform keeps track of every change in a "state file," which is like a photograph of what actually exists at that moment. No guessing, no manual errors, just repeatable, reliable construction from a plan.
Terraform is a tool that lets you treat your infrastructure—servers, networks, storage—as if it were software code. Instead of clicking through a web interface to create a virtual machine or a network subnet, you write a plain-text configuration file that says exactly what you want. Terraform then goes and makes it happen. This entire approach is called Infrastructure as Code, or IaC.
Before IaC, if a company needed a new network, an IT administrator would log in to a cloud provider's dashboard, click "Create Virtual Network," fill out forms, and click again for each part. This is called manual provisioning. It's slow, error-prone, and impossible to repeat exactly. If you needed 10 copies of the same network, you'd have to click through the same forms 10 times, hoping you didn't mistype a setting.
Terraform works differently. You write a configuration file using HashiCorp Configuration Language, or HCL, which is a human-readable way to describe infrastructure. For example, you might write a block that says:
resource "aws_vpc" "main" {
cidr_block = "10.0.0.0/16"
}
This tells Terraform: "I want an Amazon Web Services Virtual Private Cloud (VPC) with this IP address range." Terraform then contacts the AWS API—the programming interface that lets tools talk to AWS—and creates that VPC. The configuration file is your plan. Terraform is the builder.
Terraform uses providers to do this. A provider is a plugin that knows how to talk to a specific service, like AWS, Microsoft Azure, or Google Cloud. Each provider has resources and data sources. A resource is something you want to create, like a router or a firewall rule. A data source is information you want to read from an existing service, like the current list of availability zones. When you run Terraform, it loads the appropriate provider and uses it to create or update resources.
Key to this whole process is state management. Terraform keeps a state file, usually named terraform.tfstate, that records the exact current state of everything it has built. This file is critical. It maps the resources in your configuration to real-world objects in the cloud. When you make a change to your configuration—say, add a new subnet—Terraform compares the desired state in your config with the current state in its file and figures out what to add, change, or remove. If you lose the state file, Terraform has no idea what it already created, which can lead to duplicate resources or broken infrastructure.
Terraform follows a standard workflow of three steps: Write, Plan, Apply. First, you write your configuration files. Second, you run terraform plan, which shows you a preview of every change Terraform will make—nothing actually happens yet, you just see the plan. This is like checking the blueprint before cutting any wood. Finally, you run terraform apply, which executes the plan and makes the changes. If you want to tear everything down, you run terraform destroy. This workflow replaces manual clicking with a repeatable, auditable, and automatable process.
For the DevNet exam, you need to grasp that Terraform is not just for servers—it's heavily used for networking. You can create entire virtual networks, subnets, firewalls, routing tables, VPN connections, and load balancers all from code. Companies use Terraform to manage network resources across multiple cloud providers consistently. Because the configuration is code, you can store it in version control (like Git), review changes through pull requests, and collaborate with your team. That's why it's called Infrastructure as Code.
Write Configuration Files
Initialise Terraform
Run a Plan
Apply the Configuration
Manage State and Changes
Let's walk through a real scenario. Sarah is a network engineer at a mid-sized company that runs its applications across AWS and Google Cloud. Her company is launching a new e-commerce platform. She needs to set up a multi-region network that includes a VPC in each cloud provider, subnets for public-facing web servers and private databases, firewall rules to allow only HTTP and HTTPS traffic from the internet, and a VPN tunnel connecting the two clouds securely.
Here's how she uses Terraform:
She creates a new directory on her laptop and writes a main.tf file. In that file, she defines two provider blocks—one for AWS and one for Google Cloud. Each block tells Terraform which region to use and where to find credentials (like API keys).
She writes resource blocks for the AWS VPC, specifying an IP range like 10.1.0.0/16, then adds subnets for public and private tiers. For Google Cloud, she does the same but using Google's resource names like google_compute_network and google_compute_subnetwork.
She defines firewall rules in the same config file. For AWS, she uses resource "aws_security_group" "web_sg" and specifies rules for ports 80 and 443. For Google Cloud, she uses resource "google_compute_firewall" "allow_http_https".
Finally, she creates the VPN connection: an AWS VPN gateway, a Google Cloud VPN gateway, and the tunnels linking them. Each of these is a separate resource block in the configuration.
Sarah runs terraform init, which downloads the needed provider plugins. Then she runs terraform plan. The plan output shows her every resource that will be created: 1 VPC, 4 subnets, 10 firewall rules, 2 VPN gateways, and 4 tunnel connections. She reviews the plan with her team on a Git pull request.
When everyone approves, she runs terraform apply and types "yes" to confirm. Within minutes, the entire multi-cloud network exists—every VLAN, every rule, every tunnel. If a month later the company needs to add a third subnet, Sarah edits the config file, re-runs plan and apply, and Terraform makes only that one change.
The state file is stored in a shared location (like Amazon S3) so the whole team can access it. This prevents conflicts—if someone else tries to make changes, Terraform knows the current state and won't accidentally create duplicates. The entire infrastructure is now codified, version-controlled, and reproducible. That's the power of Terraform and Infrastructure as Code for networking.
The 200-901 exam tests your understanding of Terraform workflows, providers, and state management specifically for network resources. You won't be asked to write Terraform code from scratch—the exam is multiple-choice and drag-and-drop. But you must know the concepts cold.
What they love to test:
The Terraform Workflow: Know the three steps—Init, Plan, Apply. They might ask the purpose of each. For example: "Which command downloads provider plugins?" Answer: terraform init. Or: "Which command shows a preview of changes?" Answer: terraform plan. They may also test terraform destroy and its role.
Provider: Understand that a provider is a plugin that translates Terraform's resource definitions into API calls for a specific cloud or service. A common trap: they might ask which provider is used for Cisco network devices. The answer is the "ciscoasa" or "cisco-mso" provider—not AWS or Azure. Know that each provider has its own documentation.
State File: This is a major exam topic. They test that the state file maps configuration to real-world resources, and that it must be stored securely (not in plain sight in your code repository) because it can contain sensitive values like passwords. They also test that using a remote backend (like Terraform Cloud or an S3 bucket) allows team collaboration and locks the state to prevent simultaneous conflicting changes.
Resources vs Data Sources: A resource creates something (e.g., a virtual network). A data source fetches existing information (e.g., the list of available IP ranges). The exam might ask you to identify which is which from a code snippet.
Networking-Specific Resources: Expect questions on creating VPCs, subnets, security groups/firewall rules, and VPN connections. Know that Terraform can manage network devices like Cisco IOS routers, firewalls, and SD-WAN controllers via specific providers. For example, the "iosxe" provider can configure a Cisco switch.
Traps to watch for:
They might present a scenario where the state file is lost and ask what happens next. Correct answer: Terraform will not know what it already created, and running apply may create duplicate resources or error out.
They might mix up "plan" and "apply". Remember: plan shows, apply does.
They might ask about manual changes. If someone manually deletes a resource in the cloud console (not through Terraform), the state file becomes out of sync. The correct approach is to run terraform refresh to update the state file with reality, then terraform plan to see the drift.
They might test that Terraform is declarative—you declare the end state, not the steps to get there. This is in contrast to imperative tools like Ansible or Chef, where you define the steps.
Key definitions to memorise:
Infrastructure as Code (IaC): Managing and provisioning infrastructure through machine-readable definition files, rather than manual processes.
Declarative: You specify the desired end state, the tool does the rest.
Resource: A block in Terraform that creates or manages a piece of infrastructure.
Provider: A plugin that enables Terraform to interact with a specific platform.
State: A file that tracks the resources Terraform manages, mapping configuration to reality.
Terraform is a declarative tool that creates, updates, and destroys network infrastructure from code.\n
A provider is a plugin that allows Terraform to communicate with a specific service like AWS, Azure, or Cisco IOS.\n
The state file (terraform.tfstate) maps your configuration to real-world resources and is critical for Terraform to work correctly.\n
The Terraform workflow is init, plan, apply — plan shows changes before making them, apply executes them.\n
When a resource is manually changed outside Terraform, the state becomes out of sync; use terraform refresh to reconcile.\n
Terraform can manage network resources like VPCs, subnets, firewall rules, VPNs, and even router configurations using appropriate providers.\n
Infrastructure as Code means all networking is defined in version-controlled text files, making it repeatable and auditable.
These come up on the exam all the time. Here's how to tell them apart.
Declarative (Terraform)
You describe the end state of the network
You don't specify step-by-step actions
Terraform handles the order of operations automatically
Imperative (Ansible)
You write scripts that specify each step
You define 'install this, then configure that'
Ansible executes steps sequentially from your playbook
Provider
A plugin that communicates with a platform
Examples: aws, azurerm, cisco.ios
Installed by terraform init
Resource
A specific piece of infrastructure to create
Examples: aws_vpc, azurerm_subnet, cisco_ios_interface
Defined inside configuration files
terraform plan
Reads config and state, shows changes
No infrastructure is created during plan
Used for review and approval
terraform apply
Executes the changes from plan
Creates, updates, or destroys resources
Requires user confirmation by default
Configuration File
Written by user, stored in version control
Describes desired infrastructure
Human-readable HCL syntax
State File
Generated by Terraform, not manually edited
Records actual infrastructure state
Contains sensitive data, stored in a backend
Mistake
Terraform is a programming language like Python or JavaScript.
Correct
Terraform uses HCL (HashiCorp Configuration Language), which is a declarative configuration language, not a general-purpose programming language. You don't write loops or conditionals in the same way.
Many beginners see "code" in Infrastructure as Code and assume it's programming, when it's actually about declaring desired state.
Mistake
The state file is optional; you can run Terraform without it.
Correct
The state file is mandatory. Without it, Terraform cannot track which resources it created. Running apply without a state file would either re-create everything or fail entirely.
People think Terraform reads your config and just figures it out. They don't realise the state file is the only record of what exists.
Mistake
Terraform only works with cloud providers like AWS, Azure, and GCP.
Correct
Terraform has hundreds of providers, including those for on-premises networking gear like Cisco IOS and NX-OS, VMware vSphere, and even database services like Postgres.
The exam focuses a lot on cloud, so students assume that's all Terraform does. But the DevNet exam specifically covers network device provisioning.
Mistake
Once you run terraform apply, you should never edit the state file manually.
Correct
While you should never manually edit the state file, you can use terraform import to bring existing resources under Terraform management, and terraform state commands to move or remove entries safely.
Beginners think state is completely off-limits, but there are safe, supported commands to manage it. The confusion comes from warnings about manual edits.
Mistake
Terraform and Ansible are the same thing.
Correct
Terraform is declarative (you define the end state) and focused on provisioning infrastructure. Ansible is imperative (you define the steps) and focused on configuration management—like installing software on already-provisioned servers.
Both can manage infrastructure, but their philosophies differ. The exam may test the distinction.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Terraform will not be able to download the provider plugins, and running plan or apply will fail with a message saying 'required providers not found'. Always run init first.
Yes. There are Terraform providers for Cisco IOS, NX-OS, and other Cisco platforms (e.g., the cisco.ios provider). You can define router interface settings, VLANs, and ACLs as Terraform resources.
No. The state file can contain sensitive information like IP addresses, resource IDs, and even plaintext secrets. Use a remote backend (like Terraform Cloud, Amazon S3, or Azure Storage) with encryption instead.
terraform plan only shows you what Terraform intends to do—a preview. terraform apply actually executes those changes, creating or modifying infrastructure.
Yes. If you delete a resource from your configuration and run apply, Terraform will destroy it. You can also run terraform destroy to tear down everything defined in the config.
You don't need to write HCL from scratch, but you may be shown code snippets and asked to identify what a resource block does, or whether a given snippet is correct. Understanding basic syntax helps.
You've finished Terraform and Infrastructure as Code for Networking. Continue through the 200-901 study guide to build a complete picture of the exam.
Done with this chapter?