Ansible vs Terraform: which tool for what

The one-line rule

Terraform creates and changes infrastructure (networks, virtual machines, load balancers, DNS records) from a declared desired state, and it remembers what it built in a state file. Ansible configures what already exists (packages, files, users, services, device settings) by running tasks from a playbook on each managed host, without installing an agent. The decision rule for an exam: if the scenario is about making resources appear, pick Terraform; if it is about changing the settings on machines or devices that are already there, pick Ansible. Both can do a little of the other’s job, which is exactly why exam questions are built on the difference in their design, not on what is theoretically possible.

Side by side: the decisions exams test

Question the scenario asks	Terraform	Ansible
Primary job	Provision infrastructure	Configure and operate systems
Style	Declarative: describe the end state	Playbooks list tasks; most modules declare a desired state
Remembers what it did?	Yes, in a state file	No state file; it inspects the host each run
Preview before change	`terraform plan` shows creates, updates, destroys	Check mode (`--check`) simulates a run, with limits
On the target	Calls provider APIs (cloud, SaaS); nothing installed on resources	Agentless: the control node connects over SSH or, for many network platforms, an API
Language	HCL (HashiCorp Configuration Language)	YAML
Typical exam phrase	“provision”, “multi-cloud”, “drift”, “plan and apply”	“agentless”, “push”, “playbook”, “inventory”, “push NTP to all switches”

Two terms deserve care. Declarative means you state the result you want and the tool works out the steps; the opposite, imperative, is a script of ordered commands (see declarative vs imperative infrastructure as code). Idempotent means that running the same operation again leaves the system unchanged once it already matches. Ansible’s documentation states that when a system already matches the state a playbook describes, Ansible makes no changes. That holds for modules that check state before acting. A raw command or shell task has no such check unless you add one, so idempotence is a property of well-written tasks, not magic.

How each tool works

Terraform follows three stages. You write configuration files, terraform plan compares the configuration with real infrastructure and shows what it would create, update or destroy, and terraform apply carries out the changes in dependency order. It talks to platforms through providers, which is how one workflow covers several clouds. The state file is the record Terraform uses to decide what has to change, and losing or corrupting it is a real operational risk. That is why teams keep state in a shared remote backend and not on a laptop. Changing something by hand outside Terraform creates drift: the next plan shows the difference.

Ansible has a control node (where it is installed and commands run), an inventory (the list of managed nodes), modules (the units of work, such as installing a package) and playbooks (YAML files that call modules in order). Because it is agentless, managed Linux hosts need only SSH access and Python. Network modules are different in a way worth remembering: they run on the control node, not on the managed device, and reach it over CLI via SSH, NETCONF (XML over SSH) or an HTTP(S) API. That is what lets Ansible configure a switch that cannot run Python at all.

Worked example: a small web tier

A team needs two web servers behind a load balancer in a cloud subscription, with nginx installed and a standard configuration file on each.

Terraform declares the virtual network, the two virtual machines, the public IP and the load balancer. plan lists every resource it would add; after review, apply creates them and records them in state. Later, changing the VM count from two to three produces a plan that adds exactly one machine.
Ansible takes the inventory of the new machines, runs a playbook with a package task (nginx, state present), a file task for the configuration and a service task (state started). Running it again changes nothing.

Terraform can pass a startup script to a VM, and Ansible has cloud modules that can create VMs, so the lines blur. The clean split above is still the answer a certification expects, and it is how many teams run it in practice: Terraform for the infrastructure layer, Ansible for the configuration layer, often triggered from the same pipeline (see CI/CD explained).

For Azure-only provisioning, the native alternatives are ARM templates and Bicep, compared in ARM vs Bicep vs Terraform.

Which exams test this

Exam	How the topic appears	Where on this site
CCNA 200-301	v1.1 (bookable until February 2, 2027), Automation and Programmability (10%): objective 6.6 asks you to recognize the capabilities of configuration management mechanisms such as Ansible and Terraform. v2.0 (from February 3, 2027), AI, and Network Operations and Management (10%): objective 5.5 asks you to use configuration management mechanisms such as Ansible to execute commands, and 5.3 lists infrastructure as code among network management approaches. Terraform is not named in v2.0	AI and network operations explained (v2.0)
Cisco CCNA Automation 200-901	Infrastructure and Automation (20%): describe what Ansible, Terraform and Cisco NSO can do (5.6) and interpret the workflow an Ansible playbook automates, such as package management, users, basic service configuration and start/stop (5.8)	Infrastructure and automation explained
AZ-400	Indirect: Design and implement build and release pipelines (50–55%) asks you to recommend and implement a configuration management technology and define an IaC strategy. The tools it names are ARM, Bicep, Azure Automation State Configuration and Azure Machine Configuration, not Terraform or Ansible	Build and release pipelines explained

How exam questions are built around the topic

The scenario describes a job and hides the tool in one or two constraint words. “Agentless”, “over SSH” or “push configuration to existing devices” points to Ansible. “Provision”, “create the resources”, “preview the changes before they are applied”, “track the real infrastructure” or “state” points to Terraform. “Idempotent” appears in both worlds, so read the rest of the sentence.

The common trap is choosing by familiarity. A question that asks for a tool to roll out the same VLAN and NTP settings to 300 existing switches is not a Terraform question just because the word “infrastructure” appears. The second trap is mixing up Ansible with agent-based tools such as Puppet and Chef, where software runs on every managed node; the CCNA v1.0 blueprint named those, so some older study material still does. The AZ-400 outline names Bicep and ARM, not Terraform, so a question that stays inside Azure usually wants Bicep or ARM; Terraform becomes the better answer when the stem says multiple clouds or a non-Microsoft platform.

Practice questions

Question 1. A team must create virtual networks, virtual machines and a load balancer from a version-controlled definition. Before any change is made, reviewers must see exactly which resources would be created, changed or destroyed. Which tool and step fit?

A. Ansible, running a playbook of shell commands
B. Terraform, running the plan step before apply
C. Terraform, running apply and reviewing the result afterward
D. Ansible, with an inventory of the future virtual machines

Show answer

Answer: B

Terraform provisions infrastructure from declared configuration and its plan step lists the resources it would create, update or destroy before apply. Ansible is built to configure systems over SSH and does not keep a state record of provisioned resources. Running apply first would change infrastructure before review. A playbook with raw shell commands is imperative and gives no comparable preview.

Question 2. An administrator must push the same NTP and logging settings to 200 existing switches over SSH. Nothing may be installed on the switches, and rerunning the job must not cause repeated changes. Which approach fits best?

A. Terraform with a state file for each switch
B. An agent-based configuration tool installed on every switch
C. Manual CLI changes on each switch, documented afterward
D. An Ansible playbook run from a control node against an inventory of the switches