Two ways to describe a change
Ansible’s unit of work is the task: run this module, with these arguments, on these hosts. A playbook lists tasks in order and Ansible executes them top to bottom, which is why it is called procedural, even though most modules check the current state before they change anything.
Terraform’s unit is the resource: this network, this interface, this VLAN, with these attributes. You do not say in what order to build them. Terraform works out the dependencies, compares the configuration with what its state file records, and shows you a plan before it touches anything.
Idempotence, the property both aim for
An idempotent run leaves a device alone when it is already correct, so a second run is safe. Terraform gets this from the comparison against state. Ansible gets it module by module: a module setting an interface description reports “ok” when the description is already right and “changed” only when it had to act.
How they reach the devices
For routers and switches Ansible usually connects with SSH through its network_cli connection, or uses NETCONF or an HTTP API. Terraform providers talk to the target’s API, typically over HTTPS. Both ride TCP (SSH on port 22, HTTPS on 443); the port pairs are listed in TCP vs UDP.
An Ansible play for IOS routers
branch.yml; the inventory sets ansible_network_os=cisco.ios.ios
- name: Describe WAN uplinks on branch routers hosts: branch_routers gather_facts: false connection: ansible.netcommon.network_cli tasks: - name: Set the uplink description cisco.ios.ios_interfaces: config: - name: GigabitEthernet0/1 description: WAN uplink to provider state: mergedRun it with ansible-playbook -i inventory branch.yml --check first: check mode reports what would change without changing it. Nothing is installed on the routers.
The Terraform workflow
The four commands every Terraform run goes through
$ terraform init # download the providers the configuration names$ terraform plan # compare configuration with state, list the changesPlan: 1 to add, 0 to change, 0 to destroy.$ terraform apply # make the planned changes, then update the state file$ terraform destroy # remove what this configuration createdWorkflow per HashiCorp’s Terraform introduction. The state file is how Terraform knows what it already built.
Ansible and Terraform side by side
| Point of comparison | Ansible | Terraform |
|---|---|---|
| Style | Procedural: ordered tasks | Declarative: the desired end state |
| Language | YAML playbooks | HCL configuration files |
| Software on managed devices | None (agentless) | None; providers call the target’s API |
| Memory between runs | None; reads live state each time | A state file records what it manages |
| Preview before changing | Check mode, --check | terraform plan |
| Typical network job | Push configuration, run show commands, collect facts | Provision infrastructure, often cloud networks |
| CCNA topic IDs | v1.1 6.6 · v2.0 5.5 | v1.1 6.6 only |
Which tools the topic lists name
- v1.0
Original 200-301 topics
Ansible plus two agent-based tools that later left the list.
- v1.1, since August 20, 2024
Ansible and Terraform
Topic 6.6: recognize what configuration management tools can do. Terraform stays in scope until v1.1 retires.
- v2.0, from February 3, 2027
Ansible, hands-on
Topic 5.5: use Ansible to run commands. Infrastructure as code appears as a management approach in 5.3; cutover details are on the exam version page.
Frames on Ansible vs Terraform
Sort each frame into Ansible, Terraform or both before reading the options.
Practice frames written by our editors for study, not Cisco items. The 200-301 exam itself mixes multiple choice, drag-and-drop and lab-style items.
Frame 001 of 006 · 0 answered · 0 ok
Keys
1–5 or A–E pick an option (on choose-N frames they toggle; then Check answer) · ← → previous / next frame · ↑ ↓ move in the frame list
- Frame 001 of 006
What is a key difference between Terraform and Ansible for network automation?
Pick an option. The verdict shows here; open the note under any option to see why.
Note on A
Both tools manage cloud and on-premises resources, including physical network devices, through providers or modules.
Note on B
It is the other way round in part: Ansible playbooks are YAML, while Terraform configurations are written in HashiCorp’s HCL.
Note on C
Correct: Terraform describes the end state and works out the changes from its state file, while Ansible playbooks run ordered tasks.
Note on D
Neither needs an agent on network devices: Terraform calls provider APIs, and Ansible connects over SSH or APIs.
Best answer: C · why
Terraform is declarative: you describe the desired infrastructure in HCL, it keeps a state file, and terraform plan works out what must change. Ansible is agentless and pushes YAML playbooks over SSH or APIs. Its playbooks run tasks in order, which is why it is often called procedural, although many of its modules are themselves idempotent. Both manage cloud and on-premises equipment.
- Frame 002 of 006
Which statement best describes the purpose of an Ansible playbook in network automation?
Pick an option. The verdict shows here; open the note under any option to see why.
Note on A
APIs are interfaces that tools call; a playbook is a file whose tasks use modules, which may call APIs in turn.
Note on B
Correct: an Ansible playbook is a YAML file of plays and tasks that Ansible runs, in order, against the hosts in its inventory.
Note on C
Host addresses and groups belong in the Ansible inventory, not in the playbook.
Note on D
This describes a network device such as a switch, not an automation file.
Best answer: B · why
Ansible separates what to manage from what to do. The inventory lists hosts and groups with their addresses. A playbook is a YAML file of plays, each mapping a group of hosts to an ordered list of tasks, and each task calls a module such as cisco.ios.ios_config. Ansible is agentless: the control node runs the playbook and connects to devices over SSH or APIs.
- Frame 003 of 006
Which component in a Terraform configuration file specifies the desired infrastructure state?
Pick an option. The verdict shows here; open the note under any option to see why.
Note on A
Output values expose information after an apply, such as an IP address; they do not define what should exist.
Note on B
Input variables parameterize a configuration, but they describe no infrastructure on their own.
Note on C
Provider blocks configure the plugin that talks to a platform’s API, so they say how to connect, not what to build.
Note on D
Correct: resource blocks declare each object that should exist, such as a VM, a VLAN or a firewall rule, and their arguments set its desired state.
Best answer: D · why
A Terraform configuration is written in HCL, and resource blocks are its core: each declares one piece of infrastructure and its settings, which together form the desired state. Providers are plugins that turn resources into API calls for a platform. Variables feed values in, and outputs return values after apply. terraform plan compares the resource blocks with the state file and lists the changes.
- Frame 004 of 006
Which component of Terraform is responsible for determining what changes need to be made to achieve the desired state?
Pick an option. The verdict shows here; open the note under any option to see why.
Note on A
A resource declares a piece of infrastructure; it does not compute changes.
Note on B
A provider translates resources into API calls but does not decide what needs to change.
Note on C
A module groups resources for reuse and has no role in comparing states.
Note on D
Correct: terraform plan compares the configuration with the state file and real infrastructure and lists what it will add, change or destroy.
Best answer: D · why
Terraform’s workflow is write, plan, apply. terraform plan reads the configuration (resources, modules, variables), refreshes the state file against the real infrastructure, and produces an execution plan of additions, changes and deletions. terraform apply then carries the plan out. Resources, providers and modules are building blocks of the configuration, not the step that computes the difference.
- Frame 005 of 006
What does the term ‘idempotent’ mean in the context of network automation?
Pick an option. The verdict shows here; open the note under any option to see why.
Note on A
Execution priority has nothing to do with idempotence.
Note on B
Approval workflows are a process control, not a property of the operation.
Note on C
Idempotence says nothing about how many devices are targeted; tools apply idempotent tasks to many hosts at once.
Note on D
Correct: an idempotent task changes the system only the first time and makes no further change when it runs again.
Best answer: D · why
An operation is idempotent when running it once or many times leaves the system in the same state. A task that makes sure VLAN 10 exists creates it on the first run and does nothing on later runs. Declarative tools such as Terraform and most Ansible modules work this way, so rerunning automation is safe and drift can be corrected. In REST, GET, PUT and DELETE are idempotent, and POST is not.
- Frame 006 of 006
What is the primary benefit of using infrastructure as code (IaC) tools like Terraform for network automation?
Pick an option. The verdict shows here; open the note under any option to see why.
Note on A
IaC still needs engineers to write, review and approve the code; it automates deployment, not judgment.
Note on B
IaC tools work with text files and a command line, not a graphical interface.
Note on C
IaC configures and provisions infrastructure, hardware included; it does not remove the need for it.
Note on D
Correct: configuration kept as code can live in Git, be reviewed and tested, and be applied the same way every time.
Best answer: D · why
Infrastructure as code means describing infrastructure in text files that tools such as Terraform and Ansible apply. Because the files are code, they can be kept in version control, reviewed, tested in a lab and deployed the same way each time, which cuts configuration drift and manual errors. People still design, review and approve the changes, and physical devices are still needed.
Automation tool questions
Is reading a playbook enough, or should you run one?
For v1.1, recognizing what each tool does is the bar: know what plan and apply do and read a short playbook. v2.0 topic 5.5 asks you to use Ansible to run commands, so run a playbook against a lab router at least once.
Why is Ansible called agentless?
Nothing is installed on the managed router or switch. The control node connects over SSH or an API that the device already offers.
What about other configuration tools in older study material?
Agent-based tools came from the original v1.0 topics and are absent from both v1.1 and v2.0. Leave them out of current study.
References
- [1]Ansible documentation: network automation getting startedChecked October 29, 2026.
- [2]HashiCorp: What is Terraform?Checked October 29, 2026.
- [3]Cisco Learning Network: CCNA v1.1 exam topicsTopic 6.6; v1.1 tested since 2024-08-20. Checked October 29, 2026.
- [4]Cisco Learning Network: CCNA v2.0 exam topicsTopics 5.3 and 5.5; tested from 2027-02-03. Checked October 29, 2026.