19.1 Configuration Management & Infrastructure as Code (Ansible & Terraform)

19.1 Configuration Management & Infrastructure as Code (Ansible & Terraform)

Core Blueprint Focus: Cisco 350-401 ENCOR v1.2 topic 6.7 (compare agent vs. agentless orchestration tools) tests a candidate's ability to evaluate, construct, and troubleshoot enterprise orchestration workflows and Infrastructure as Code (IaC) solutions. Candidates must differentiate between declarative and imperative configuration models, master Ansible's agentless architecture over SSH (network_cli), construct YAML playbooks with Cisco IOS collection modules (ios_config, ios_command, declarative resource modules), evaluate idempotency, understand Terraform execution workflows (terraform plan/apply, .tfstate, HCL syntax, Cisco providers), and contrast push vs. pull configuration management tools (Ansible, Terraform, Puppet, Chef, SaltStack).

Enterprise networks have grown too complex, distributed, and dynamic for manual, box-by-box command-line interface (CLI) administration. Modern network engineering treats network infrastructure identically to software applications: configurations are defined in structured code, tracked in version control repositories, validated through automated testing pipelines, and deployed predictably using automated orchestration engines.

+---------------------------------------------------------------------------------------------------+
|                    ENTERPRISE NETWORK ORCHESTRATION & IaC ECOSYSTEM                               |
+---------------------------------------------------------------------------------------------------+
|                                                                                                   |
|   +-------------------------------------------------------------------------------------------+   |
|   |                    INFRASTRUCTURE AS CODE (IaC) DEFINITIONS & REPOSITORIES                |   |
|   |    - Ansible Playbooks (YAML)                  - Terraform Configurations (HCL)           |   |
|   |    - Hierarchical Inventories (hosts.yaml)     - State Files & Locks (.tfstate / DynamoDB)|   |
|   +-------------------------------------------------------------------------------------------+   |
|               |                                                            |                      |
|               v                                                            v                      |
|   +-----------------------+                                    +-----------------------+          |
|   |  ANSIBLE CONTROL NODE |                                    |  TERRAFORM CLI ENGINE |          |
|   |  - Push-based Engine  |                                    |  - Declarative Engine |          |
|   |  - Agentless over SSH |                                    |  - Graph Dependency   |          |
|   |  - Modules: cisco.ios |                                    |  - Providers: DNA/SDW |          |
|   +-----------------------+                                    +-----------------------+          |
|               |                                                            |                      |
|       +-------+-------+                                            +-------+-------+              |
|       |               |                                            |               |              |
|       v (SSH/CLI)     v (NETCONF 830)                              v (HTTPS REST)  v (HTTPS REST) |
|   +-----------+   +-----------+                                +-----------+   +-----------+      |
|   | Catalyst  |   | Catalyst  |                                | Catalyst  |   | Catalyst  |      |
|   | 9300 /    |   | 8300 WAN  |                                | Center    |   | SD-WAN    |      |
|   | 9500 Sw.  |   | Edge Rtr. |                                | (DNA-C)   |   | vManage   |      |
|   +-----------+   +-----------+                                +-----------+   +-----------+      |
+---------------------------------------------------------------------------------------------------+

1. Declarative vs. Imperative Configuration Management

At the core of network automation is the distinction between imperative (procedural) and declarative (intent-based) configuration management paradigms. Understanding the architectural differences between these approaches is essential for deploying scalable, reliable automation pipelines.

+---------------------------------------------------------------------------------------------------+
|                      IMPERATIVE VS. DECLARATIVE EXECUTION PARADIGMS                               |
+---------------------------------------------------------------------------------------------------+
|                                                                                                   |
|   IMPERATIVE (PROCEDURAL): "HOW TO DO IT"                                                         |
|   - Administrator writes explicit, step-by-step CLI commands executed in sequential order.        |
|   - Device executes commands blindly without verifying preexisting state.                        |
|   - Example: "Enter config mode -> enter interface Gi1/0/1 -> set description -> exit config."   |
|   - Vulnerable to configuration drift, ordering errors, and unintended side effects.              |
|                                                                                                   |
|   DECLARATIVE (INTENT-BASED): "WHAT THE END-STATE MUST BE"                                        |
|   - Administrator defines the desired end-state of the resource (e.g., VLAN 10 name is VOICE).    |
|   - Automation engine reads the live state, computes the difference (delta), and applies ONLY     |
|     the specific modifications necessary to reach the target state.                               |
|   - Idempotent by design: Running the task 1 time or 1,000 times yields the exact same state.     |
+---------------------------------------------------------------------------------------------------+

In-Depth Comparison Matrix

The Mathematical Principle of Idempotency

In software engineering and network automation, an operation is defined as idempotent if applying it multiple times produces the exact same outcome as applying it a single time, without causing unintended side effects:

$f(f(x)) = f(x)$

• Non-Idempotent Example: Appending description Uplink-to-Core to an interface using a simple CLI string push without checking if the description already exists or if it overwrites an existing critical label.
• Idempotent Example: An Ansible module reading the running configuration of GigabitEthernet1/0/1, determining that the MTU is already set to 9000, and skipping the task (status: ok) rather than issuing redundant CLI commands that could reset the interface ASIC.

2. Ansible Architecture & The Agentless Model

Ansible (developed by Red Hat) is an open-source IT automation and configuration management platform widely adopted in enterprise network operations. Unlike traditional server configuration platforms that require software daemons installed on managed systems, Ansible utilizes an agentless, push-based architecture.

+---------------------------------------------------------------------------------------------------+
|                            ANSIBLE CONTROL NODE TO TARGET WORKFLOW                                |
+---------------------------------------------------------------------------------------------------+
|                                                                                                   |
|  +---------------------------------------------------------------------------------------------+  |
|  |                        ANSIBLE CONTROL NODE (Linux / macOS / WSL)                           |  |
|  |  1. Parse ansible.cfg (forks, timeouts, host key checking)                                  |  |
|  |  2. Load Inventory (hosts.yaml / group_vars / host_vars)                                     |  |
|  |  3. Compile Playbook Tasks (YAML) & Jinja2 Templates                                        |  |
|  |  4. Execute Local Python Module Engine -> Translate task into network CLI commands / RPCs   |  |
|  +---------------------------------------------------------------------------------------------+  |
|                                                |                                                  |
|                     +--------------------------+--------------------------+                      |
|                     | (ansible_connection)                                |                      |
|                     v                                                     v                      |
|  +-------------------------------------+               +-------------------------------------+   |
|  |  network_cli (SSH Port 22)          |               |  httpapi (HTTPS Port 443)           |   |
|  |  - Interactive PTY terminal session |               |  - RESTful API payload delivery     |   |
|  |  - Disables CLI paging (term len 0) |               |  - JSON-RPC / RESTCONF transactions |   |
|  |  - Handles privilege enable prompts |               |  - NX-OS, Arista eAPI, Controllers  |   |
|  +-------------------------------------+               +-------------------------------------+   |
|                     |                                                     |                      |
|                     v                                                     v                      |
|  +-------------------------------------+               +-------------------------------------+   |
|  |  MANAGED NODE (Cisco IOS-XE Switch) |               |  MANAGED CONTROLLER (Catalyst Ctr)  |   |
|  |  - No Python runtime required       |               |  - No local agent required          |   |
|  |  - Native SSH daemon executes CLI   |               |  - HTTPS REST API processes payload |   |
|  +-------------------------------------+               +-------------------------------------+   |
+---------------------------------------------------------------------------------------------------+

Why Agentless is Critical for Enterprise Networking

Traditional enterprise switches, routers, and firewalls run closed, proprietary operating systems (such as Cisco IOS, classic IOS-XE, or ASA) that do not permit end-users to install arbitrary background daemons, root-level packages, or specific Python interpreter versions. Ansible solves this constraint:

1. Zero Client Footprint: The target device requires only standard management access (SSH for CLI/NETCONF, or HTTPS for REST APIs).
2. Local Execution on Control Node: Ansible executes Python modules locally on the Control Node, converts module logic into appropriate target CLI syntax or XML/JSON payloads, and delivers them across standard protocols.
3. Centralized Security: Management credentials and SSH private keys remain securely stored on the control node, without requiring privileged daemon keys distributed across thousands of edge switches.

Ansible Connection Plugins for Networking

Ansible Inventory Architecture (hosts.yaml)

Inventories organize managed nodes into logical, hierarchical groups and associate connection variables. Modern network automation uses YAML-formatted inventories:

# /etc/ansible/hosts.yaml - Enterprise Network Inventory
---
all:
  children:
    campus:
      children:
        core_switches:
          hosts:
            core-sw01.enterprise.local:
              ansible_host: 10.10.10.1
            core-sw02.enterprise.local:
              ansible_host: 10.10.10.2
          vars:
            device_role: campus_core
            stp_priority: 4096
        access_switches:
          hosts:
            acc-sw01.enterprise.local:
              ansible_host: 10.10.20.11
            acc-sw02.enterprise.local:
              ansible_host: 10.10.20.12
          vars:
            device_role: campus_access
            stp_priority: 32768
      vars:
        ansible_network_os: cisco.ios.ios
        ansible_connection: ansible.netcommon.network_cli
        ansible_user: netadmin
        ansible_become: yes
        ansible_become_method: enable

Key Ansible Configuration (ansible.cfg)

# ansible.cfg - Optimized for Network Automation
[defaults]
inventory = ./hosts.yaml
host_key_checking = False
forks = 25                      # Parallel execution threads across network devices
timeout = 30                    # SSH socket connection timeout in seconds
retry_files_enabled = False

[persistent_connection]
connect_timeout = 60            # Maximum time to establish persistent network_cli connection
command_timeout = 45            # Maximum time waiting for a slow CLI show command to return

3. Ansible Playbooks, Modules & Declarative Resource Engines

An Ansible Playbook is a human-readable YAML document mapping target device groups (plays) to ordered sequences of tasks executed by specific modules.

The Cisco IOS Collection (cisco.ios)

Modern Ansible organizes platform support into Collections. For Cisco IOS and IOS-XE platforms, modules reside within the cisco.ios namespace.

+---------------------------------------------------------------------------------------------------+
|                         CISCO IOS ANSIBLE MODULE CLASSIFICATION                                   |
+---------------------------------------------------------------------------------------------------+
|                                                                                                   |
|  1. OPERATIONAL / COMMAND MODULES (Read-Only Inspection)                                          |
|  - Module: cisco.ios.ios_command                                                                  |
|  - Purpose: Runs operational 'show' commands; asserts network health via 'wait_for' conditions.   |
|  - Idempotency: Always reports 'ok' (does not alter device configuration state).                  |
|                                                                                                   |
|  2. TRADITIONAL CONFIGURATION MODULES (Line-Based Push)                                           |
|  - Module: cisco.ios.ios_config                                                                   |
|  - Purpose: Pushes blocks of CLI text commands under hierarchical parents; supports config backup.|
|  - Idempotency: Line-based comparison against running-config (vulnerable to syntax formatting).  |
|                                                                                                   |
|  3. DECLARATIVE RESOURCE MODULES (Structured Data Models)                                         |
|  - Modules: cisco.ios.ios_interfaces, ios_vlans, ios_l3_interfaces, ios_ospf_interfaces, etc.     |
|  - Purpose: Models network features as structured dictionaries independent of CLI syntax.         |
|  - State Engine: merged, replaced, overridden, deleted, gathered, rendered, parsed.               |
|  - Idempotency: 100% True Idempotency with exact delta computation.                               |
+---------------------------------------------------------------------------------------------------+

Complete Production Playbook Example: Command & Config Modules

# deploy_campus_baseline.yaml
---
- name: Campus Switch Baseline Hardening and Verification
  hosts: access_switches
  gather_facts: no
  connection: ansible.netcommon.network_cli

  tasks:
    # Task 1: Check operational BGP / Interface state before making changes
    - name: Verify GigabitEthernet1/0/1 operational link state
      cisco.ios.ios_command:
        commands:
          - show ip interface brief GigabitEthernet1/0/1
        wait_for:
          - result[0] contains "up"
        retries: 3
        interval: 5
      register: link_status

    # Task 2: Push global security and NTP configurations idempotently
    - name: Configure standard NTP servers and domain name
      cisco.ios.ios_config:
        lines:
          - ntp server 10.100.1.10 prefer
          - ntp server 10.100.1.11
          - ip domain name enterprise.local
          - service password-encryption
        backup: yes                     # Pulls running-config backup to control node
        save_when: modified             # Issues 'write memory' ONLY if changes were applied
      register: config_output

    # Task 3: Apply hierarchical interface configuration with parent blocks
    - name: Configure Access Port Security on user ports
      cisco.ios.ios_config:
        parents: interface GigabitEthernet1/0/24
        lines:
          - description Workstation-Access-Port
          - switchport mode access
          - switchport access vlan 20
          - switchport port-security
          - switchport port-security maximum 2
          - switchport port-security violation restrict
          - spanning-tree portfast
          - spanning-tree bpduguard enable

Declarative Resource Modules: The 7 Lifecycle States

Ansible Resource Modules represent the modern standard for network configuration. Instead of pushing raw CLI strings, you define structured dictionaries. The module supports 7 distinct state operations:

+---------------------------------------------------------------------------------------------------+
|                         RESOURCE MODULE STATE ENGINE COMPARISON                                   |
+---------------------------------------------------------------------------------------------------+
|  State Keyword | Target Action & Delta Computation                                                |
| :------------- | :------------------------------------------------------------------------------- |
| **`merged`**   | **Default State.** Adds new configurations or updates existing attributes.       |
|                | Does NOT delete unspecified attributes or existing objects on the device.        |
| **`replaced`** | Updates the specific declared objects to match the playbook exactly.             |
|                | Resets unspecified attributes on declared objects to defaults, but preserves      |
|                | undeclared objects (e.g., updates VLAN 10 attributes, leaves VLAN 20 untouched). |
| **`overridden`**| **Strict Declarative Alignment.** Overwrites the ENTIRE subsystem. Declared      |
|                | objects are updated/created; ANY object on the device NOT in the playbook is      |
|                | **purged and deleted** (e.g., VLANs 40, 50 on switch are deleted if not listed). |
| **`deleted`**  | Deletes the declared resources from the device (e.g., removes declared VLANs).    |
| **`gathered`** | Queries live device state and outputs structured Ansible facts (no changes made). |
| **`rendered`** | Generates raw CLI syntax strings locally on the control node without contacting   |
|                | the live network device (ideal for offline dry-run auditing).                      |
| **`parsed`**   | Parses raw CLI configuration text from a file into structured Ansible dictionary. |
+---------------------------------------------------------------------------------------------------+

Resource Module Example: Managing VLANs with state: overridden

    - name: Enforce strict campus VLAN compliance (purge unauthorized VLANs)
      cisco.ios.ios_vlans:
        config:
          - vlan_id: 10
            name: MANAGEMENT
            state: active
          - vlan_id: 20
            name: CORPORATE_DATA
            state: active
          - vlan_id: 30
            name: VOICE_OVER_IP
            state: active
        state: overridden

[!IMPORTANT] If a switch currently has VLANs 10, 20, 30, 99, and 999 configured, executing the above task with state: overridden will configure VLANs 10, 20, and 30, and immediately purge VLANs 99 and 999 from the switch because they were omitted from the declarative state manifest.

4. Terraform & Infrastructure as Code (IaC)

Terraform (developed by HashiCorp) is an open-source Infrastructure as Code (IaC) tool designed for provisioning, managing, and orchestrating cloud, data center, and network infrastructure. While Ansible excels at day-to-day configuration management across existing devices, Terraform is engineered for lifecycle resource provisioning and lifecycle tracking using declarative definitions written in HashiCorp Configuration Language (HCL).

+---------------------------------------------------------------------------------------------------+
|                             THE TERRAFORM EXECUTION WORKFLOW                                      |
+---------------------------------------------------------------------------------------------------+
|                                                                                                   |
|  1. CODE (HCL)           2. INIT                   3. PLAN                   4. APPLY             |
|  +---------------+      +-------------------+     +-------------------+     +-------------------+
|  | main.tf       | ---> |  terraform init   | --> |  terraform plan   | --> | terraform apply   |
|  | variables.tf  |      | - Downloads       |     | - Reads .tfstate  |     | - Executes API    |
|  | outputs.tf    |      |   Provider Plugin |     | - Compares live   |     |   CRUD operations |
|  +---------------+      |   (Catalyst Ctr)  |     |   infrastructure  |     | - Updates state   |
|                         +-------------------+     | - Displays (+/~/-)|     |   (.tfstate)      |
|                                                   +-------------------+     +-------------------+
|                                                                                       |           |
|                                                                                       v           |
|                                                                             +-------------------+
|                                                                             | Cisco Catalyst    |
|                                                                             | Center / SD-WAN   |
|                                                                             +-------------------+
+---------------------------------------------------------------------------------------------------+

Core HCL Structural Blocks

1. terraform Block: Configures Terraform core settings, required versions, and required provider plugins from the Terraform Registry.
2. provider Block: Configures the target authentication parameters and endpoint URLs for the specific infrastructure platform (e.g., Cisco Catalyst Center, Cisco SD-WAN, Cisco ACI).
3. resource Block: Declares an infrastructure component to be created, managed, and tracked by Terraform.
4. data Block: Queries existing infrastructure or external attributes to feed into other resources without creating a new component.
5. variable & output Blocks: Define parameterized input variables and export values generated after deployment.

Production Terraform Configuration for Cisco Catalyst Center

# main.tf - Provisioning Site Hierarchy and Network IP Pool in Cisco Catalyst Center
terraform {
  required_version = ">= 1.5.0"
  required_providers {
    catalystcenter = {
      source  = "cisco-open/catalystcenter"
      version = "~> 1.0.0"
    }
  }
}

# Configure Cisco Catalyst Center Provider Credentials
provider "catalystcenter" {
  base_url = "https://dna.enterprise.local"
  username = var.dnac_user
  password = var.dnac_password
  insecure  = true               # Disables TLS verification for self-signed certificates
}

# Data Source: Query Global Enterprise Area
data "catalystcenter_site" "global_area" {
  name = "Global"
}

# Resource 1: Create a new Campus Building Site
resource "catalystcenter_site" "san_jose_bldg1" {
  site {
    building {
      name        = "SJ-BLDG-01"
      parent_name = data.catalystcenter_site.global_area.name
      address     = "170 West Tasman Dr, San Jose, CA 95134"
      latitude    = 37.41
      longitude   = -121.94
    }
  }
}

# Resource 2: Provision a Global IPv4 IP Pool for Corporate Workstations
resource "catalystcenter_global_pool" "corp_workstations" {
  ip_pool_name = "CORP-WORKSTATION-POOL"
  ip_pool_cidr = "10.100.0.0/16"
  gateways     = ["10.100.0.1"]
  dhcp_server_ips = ["10.10.10.50", "10.10.10.51"]
  dns_server_ips  = ["10.10.10.10", "10.10.10.11"]
}

# outputs.tf - Export Provisioned Resource Identifiers
output "building_site_id" {
  description = "Unique UUID of the provisioned San Jose Building"
  value       = catalystcenter_site.san_jose_bldg1.id
}

Terraform State Management (.tfstate)

Unlike Ansible which queries the live device state on every playbook run, Terraform maintains a dedicated state file (terraform.tfstate) that acts as the single source of truth mapping your declared HCL configuration to real-world infrastructure IDs.

• State Contents: Tracks metadata, resource attributes, dependencies, and private API identifiers.
• Remote State & State Locking: In enterprise teams, storing .tfstate files locally leads to state drift, race conditions, and accidental credential leakage. Enterprise best practices require Remote State stored in secure object storage (such as AWS S3 with encryption) combined with State Locking (using AWS DynamoDB, Terraform Cloud, or HashiCorp Consul) to prevent multiple engineers or CI/CD pipelines from modifying infrastructure concurrently.

TERRAFORM PLAN SYMBOLS:
  + create       (Resource will be newly created)
  ~ update       (Resource will be modified in-place)
  - destroy      (Resource will be permanently deleted)
-/+ replace      (Resource will be destroyed and recreated)

5. Comparison with Agent-Based Tools: Puppet, Chef & SaltStack

To fully master configuration management for the CCNP 350-401 ENCOR exam, candidates must understand how Ansible and Terraform compare with traditional agent-based platforms: Puppet, Chef, and SaltStack.

+---------------------------------------------------------------------------------------------------+
|                         CONFIGURATION MANAGEMENT EVOLUTION & PARADIGMS                            |
+---------------------------------------------------------------------------------------------------+
|                                                                                                   |
|  [ PUPPET ]           [ CHEF ]             [ SALTSTACK ]          [ ANSIBLE ]      [ TERRAFORM ]  |
|  - Declarative DSL    - Imperative/Decl.   - Declarative/Imp.     - Declarative    - Declarative  |
|  - Agent-based Pull   - Agent-based Pull   - Agent / Agentless    - Agentless Push - Agentless Push|
|  - Puppet Master      - Chef Server        - Salt Master          - Control Node   - CLI Engine   |
|  - 30-min sync        - Periodic sync      - ZeroMQ / Event-bus   - SSH / HTTPS    - REST APIs    |
+---------------------------------------------------------------------------------------------------+

Puppet Architecture

• Model: Declarative language based on Ruby syntax.
• Workflow: Agent-Based Pull. Managed nodes run the puppet-agent daemon. Every 30 minutes (default), the agent compiles local system attributes (Facts via Facter), sends them to the Puppet Master, receives a compiled declarative configuration document (Catalog), and applies deltas locally.
• Network Support: Requires Cisco switches to support Guest Shell (Linux container environment on IOS-XE/NX-OS) to host the puppet-agent or uses proxy agent nodes.

Chef Architecture

• Model: Imperative/Declarative Ruby Domain-Specific Language (DSL).
• Workflow: Agent-Based Pull. Infrastructure is modeled as Recipes bundled into Cookbooks. A central Chef Server stores cookbooks. The Chef Workstation author pushes cookbooks to the server. Target nodes execute the chef-client daemon periodically, pulling recipes and executing Ruby code to converge system state.

SaltStack Architecture

• Model: Declarative YAML (Salt States) or Python execution routines.
• Workflow: High-speed event-driven architecture using Salt Minions (agents) communicating over ZeroMQ (ports 4505/4506) with the Salt Master. Also supports Salt-SSH for agentless execution.

Master Orchestration & Configuration Management Matrix