Cisco Certified Network Associate (CCNA) 200-301 · Free study guide

Objective 6.6 — Compare Ansible and Terraform capabilities

Ansible and Terraform both support repeatable infrastructure work, but their common mental models differ. Ansible organizes tasks in playbooks and applies them to inventory targets through modules or collections. Terraform describes desired resources through providers, compares configuration with recorded and observed state, and proposes lifecycle actions in a plan. Real deployments can overlap, so focus on workflow and state rather than slogans.

Read an Ansible workflow

An inventory defines target hosts and groups plus associated variables. A playbook maps plays and tasks to those targets. Modules perform operations, and handlers can react to reported changes. Well-designed tasks strive for idempotence: applying the same desired setting again should report no change when the target already matches.

Task order can still matter, and a generic command task is not automatically idempotent. Variables, templates, device platform, connection method, and collection version influence behavior. Preview or check capabilities vary by module and should not be assumed to perfectly model every action.

Read a Terraform workflow

Terraform configuration declares resources and relationships through providers. A plan compares desired configuration, saved state, and provider observations to show proposed changes. Apply performs an approved plan or calculates and performs actions according to the chosen workflow. State maps managed objects to remote resources and can contain sensitive values, so it needs controlled storage, locking, backup, and access.

Declarative does not mean consequence-free. A small configuration edit can propose replacement or deletion. Review every plan and provider-specific action. Manual changes can create drift, and importing or reconciling existing resources requires care.

Worked scenario

A team uses an Ansible playbook to standardize NTP and syslog lines on existing switches, then uses Terraform to manage a cloud lab's network resources and lifecycle. An unreviewed Terraform plan proposes replacing a subnet after an immutable property changes. The team stops because the desired text looked minor but the plan reveals destructive impact. For Ansible, it checks that a second run reports no unexpected changes.

Choose by operational fit

Consider whether the task manages configuration inside existing devices, resource lifecycle, or both. Examine platform support, source-of-truth ownership, drift handling, transaction boundaries, secret storage, review, and recovery. Neither tool removes the need to understand the network or validate service outcomes.

Verification evidence

For Ansible, review selected inventory, resolved variables, task results, changed-versus-ok status, errors, and device postchecks. For Terraform, review provider versions, state controls, the exact saved plan, proposed create/update/ replace/delete actions, apply result, and observed resources. Protect logs and artifacts from secrets.

Common traps

• Calling every Ansible task idempotent.
• Treating Terraform state as harmless cache data.
• Applying a plan without reading replacement or deletion actions.
• Mixing manual changes with no drift-reconciliation policy.
• Assuming a successful tool run proves application reachability.

Readiness checklist

• I can identify inventories, playbooks, tasks, and modules.
• I can identify providers, configuration, plans, applies, and state.
• I compare tools by workflow rather than brand shorthand.
• I verify both managed state and network outcomes.