Infrastructure as Code for CLI-First Network Teams

Infrastructure as code can sound like a demand that network engineers abandon the CLI and become software developers. That framing creates resistance for the wrong reason. IaC is primarily a control model: represent intended infrastructure state in versioned files, review changes before applying them, use repeatable tooling to reconcile real systems with that intent, and verify the result. The CLI can still be valuable for exploration and troubleshooting.

Cisco now treats infrastructure as code as a core network-automation skill in the current 350-901 AUTOCOR track, while 300-435 ENAUTO focuses automation on enterprise platforms and can serve as a concentration in CCNP Enterprise. The current 350-401 ENCOR foundation still matters because automation is safe only when the desired state reflects correct network behavior.

For a team that has lived in terminal sessions for years, the best migration is incremental: capture intent, generate plans, verify changes, and move repeatable pieces into code without pretending every legacy device became cloud-native overnight.

IaC begins with a desired-state model

A CLI workflow often starts with commands: enter configuration mode, create a VLAN, add an interface, set an IP address. IaC starts one level earlier: what should exist after the change? That desired state may be represented as YAML, JSON, HCL, a controller template, or another structured format.

The model should describe business-relevant objects where possible: site, device role, interface purpose, prefix, routing peer, policy, or service. Tool-specific syntax belongs below that layer. Otherwise the team simply stores CLI commands in Git without gaining much abstraction.

The better the intent model, the easier it becomes to test whether two sites that should be identical actually are.

When desired state lives in version control, every change has an author, diff, timestamp, review, and previous version. That is a major improvement over pasting commands into a terminal and saving an incomplete transcript in a ticket.

A useful review shows semantic change: which prefix changed, which interface policy moved, which site was added. Generated configuration can be included for validation, but reviewers should not have to infer intent from hundreds of nearly identical command lines.

Rollback also becomes more disciplined. Instead of inventing reverse commands during an incident, the team can identify the last known-good state and reconcile toward it—provided the automation tool understands the relevant resources safely.

Plan before apply

Good IaC workflows separate planning from execution. The plan compares desired and observed state and shows what the system proposes to create, modify, or remove. Humans or policy gates can review that plan before any write occurs.

This is especially important in networks because “replace” can be far more disruptive than “update.” A tool may decide that changing one immutable property requires deleting and recreating an object. Network engineers must understand lifecycle semantics before approving the plan.

The same safety principle applies to controller templates and custom scripts: produce a concrete change set first, then apply it intentionally.

Idempotence turns reruns into normal operations

An IaC workflow should converge. If the real network already matches the desired state, another run should produce no change. If a run stops halfway, a subsequent run should continue toward the same intended outcome rather than duplicating configuration.

That property changes the operational model. Engineers no longer need a unique script for “build” and another for “repair.” The desired state remains the same; the tool reconciles differences.

Idempotence depends on accurate provider or API behavior. Test it against the exact platform and software versions in use rather than assuming every network resource behaves like a cloud object.

Drift is a signal, not automatically an error

CLI-first teams often continue making emergency manual changes after IaC adoption. Those changes create drift between the declared state and the real network. Detecting drift is valuable because it reveals that the two sources disagree.

But automatic correction can be dangerous if the manual change was a deliberate incident response. Mature processes decide whether the declared state should overwrite the device, the device change should be imported back into code, or an exception should remain temporarily.

Treat drift events as reconciliation decisions. The goal is to restore one authoritative truth, not to punish every out-of-band change blindly.

Terraform and configuration tools solve different shapes of problem

Terraform-style tools are strong at managing resources through providers and desired-state graphs. Configuration tools such as Ansible are often strong at procedural or declarative device configuration and orchestration. Controller-native APIs can provide higher-level intent for domains they own.

The current Terraform Associate 004 inventory is a useful adjacent reference because the important Terraform concepts—state, planning, providers, dependencies, and lifecycle—translate into network-IaC reasoning even when the managed objects are routers rather than cloud instances.

The tool should follow the resource model. Do not force every network operation into one framework merely because the team standardized on its syntax.

State files and secrets become production assets

IaC systems often maintain state describing managed resources. That state can contain addresses, identifiers, relationships, or sensitive values. Losing it can make future plans unsafe; exposing it can leak infrastructure detail. Protect it with access control, backups, and locking where the tooling supports those features.

Credentials, API tokens, and private keys should not be committed alongside ordinary configuration. Use a secret-management mechanism and short-lived or scoped credentials where practical. Automation accounts should have only the privileges needed for the managed domain.

Once code can change hundreds of devices, the credential that runs the code is as sensitive as an administrator account—often more so because its blast radius is larger.

Pipelines add gates, not just speed

Continuous integration can validate syntax, schema, naming rules, duplicate addresses, prefix overlap, policy constraints, and test fixtures before a change reaches a device. A pipeline can also generate a plan and require peer approval before deployment.

That is where IaC becomes more than “automated configuration.” The system prevents classes of errors earlier. A subnet overlap can fail in code review instead of during a maintenance window.

Pipelines should remain understandable to network operators. If only one platform engineer can explain why a deployment failed, the organization traded CLI tribal knowledge for CI/CD tribal knowledge.

Start with low-risk, high-repeatability domains

A successful adoption does not begin by converting the most fragile core routing policy in the company. Start with inventories, lab builds, standard access ports, repeatable branch objects, or validation rules. Build trust in plan/apply/verify behavior before moving into high-risk domains.

Keep manual escape hatches during the transition, but make their use visible and reconcile afterward. The team should learn how tooling behaves during partial failure, API timeouts, controller outages, and unexpected device state.

The network-automation foundations represented by network automation become operationally useful when the process is designed for failure, not only for the happy-path demo.

CLI skills still matter after IaC adoption

When a deployment fails, engineers still need to inspect the live system. They must understand routing, switching, security, logs, counters, and controller behavior. IaC changes the normal path to configuration; it does not remove the need to diagnose the resulting infrastructure.

The healthiest teams use the CLI for investigation and exceptional recovery while using code for repeatable desired state. Discoveries made manually should feed back into the model, tests, and validation so the same problem is easier to prevent next time.

Infrastructure as code is therefore not a replacement for network engineering. It is a way to make network engineering intent reviewable, repeatable, and auditable. CLI-first teams already understand the systems; IaC gives them a safer way to express what those systems should look like at scale.

Network environments often end up with overlapping automation: Terraform creates an object, Ansible configures it, a controller manages part of it, and an engineer can still edit it through the CLI. Without ownership boundaries, each tool can interpret the other tool’s change as drift and overwrite it. That is configuration ping-pong, not automation.

Assign authoritative ownership by resource or layer. A controller may own campus fabric intent, Terraform may own cloud connectivity objects, and an Ansible workflow may own a set of legacy device settings. If one tool must read an object owned elsewhere, make the dependency explicit rather than importing it into competing state.

Migration periods need special rules. Mark resources that are still manually managed, document which changes must be reconciled back into code, and avoid automatic enforcement until the team is confident about ownership. A smaller IaC footprint with clear authority is safer than declaring the entire network managed while half of it still changes through unrelated systems.

Testing should include destructive-looking plans in a safe environment. Engineers need to recognize when a provider proposes replacement rather than in-place modification, when dependency graphs cause cascading changes, and when importing existing resources changes identifiers. Those behaviors are easy to miss if the team only tests greenfield creation.

Network-specific policy checks can add enormous value before apply: reject duplicate addresses, overlapping prefixes, invalid BGP AS relationships, forbidden VLAN ranges, missing route-policy defaults, or changes that would reduce path diversity below the design minimum. These tests encode institutional knowledge so reviewers are not relying entirely on memory.

The end state is not “everything is code.” It is “repeatable intent is controlled.” Some emergency actions, diagnostics, and one-off recovery steps will remain interactive. IaC succeeds when normal infrastructure changes become predictable and reviewable while exceptional work remains visible and is reconciled back into the source of truth afterward.

Use the same discipline for decommissioning as for creation. Removing a VLAN, prefix, policy, or device should require proof that no declared dependency still references it and that monitoring confirms the service has moved elsewhere. IaC makes deletion easy to express, which is exactly why deletion deserves explicit review and staged verification in network environments where a forgotten dependency may be several routing hops away.