Postman & Ansible – Network Automation, REST APIs, and Playbooks

1. Why Network Automation? — The Context

Traditional network management relies on engineers logging into each device individually, typing commands manually, and verifying changes one by one. In small networks this is manageable. In enterprise environments with hundreds or thousands of devices, it is slow, error-prone, and impossible to scale.

Network automation replaces manual CLI work with programmatic control — using APIs, scripts, and automation platforms to configure, verify, and manage devices consistently and at scale. Postman and Ansible are two of the most widely used tools in this space and appear explicitly in the CCNA DevNet curriculum.

  Manual workflow:
  Engineer → SSH to Switch 1 → type commands → verify → SSH to Switch 2 → repeat × 200

  Automated workflow:
  Engineer writes playbook/API call once →
  Tool executes against all 200 devices simultaneously →
  Results reported back centrally → idempotent: safe to re-run

  Key benefits:
  ┌─────────────────────────────────────────────────────┐
  │ Speed        — minutes instead of hours             │
  │ Consistency  — identical config on every device     │
  │ Auditability — changes tracked in version control   │
  │ Scalability  — same effort for 1 device or 1000     │
  │ Idempotency  — re-run safely; no duplicate changes  │
  └─────────────────────────────────────────────────────┘

2. Postman — REST API Testing and Development

What Is Postman?

Postman is a graphical API development and testing platform that enables engineers to construct, send, inspect, and automate HTTP/HTTPS requests without writing code. In networking it is used to interact with the programmable interfaces (REST APIs) of network controllers (Cisco DNA Center, NSO), cloud platforms (AWS, Azure), and individual devices that support RESTCONF or a vendor API.

  Postman sits between you and the API:

  Engineer                  Postman               Network API
  (builds request)  ──→  (sends HTTP request) ──→  (returns JSON/XML response)
                     ←──  (displays response)  ←──

  Without Postman: write curl commands or code for every test.
  With Postman:    point-and-click request builder + automated test scripts.

HTTP Methods — The CRUD Verbs

REST APIs map operations to HTTP methods. Understanding which method to use for each operation is a CCNA exam requirement:

HTTP Method	CRUD Operation	Purpose	Request Body?	Network Example
GET	Read	Retrieve a resource or list of resources; does not modify anything	No	Fetch device interface status, retrieve VLAN list, get routing table
POST	Create	Create a new resource; body contains the resource definition in JSON or XML	Yes	Create a new VLAN, add a static route, provision a new device
PUT	Update (full)	Replace an existing resource completely with the data in the request body	Yes	Update full interface configuration, replace an ACL policy
PATCH	Update (partial)	Modify only specific fields of an existing resource — does not replace the whole object	Yes (partial)	Change only the description field of an interface without affecting other parameters
DELETE	Delete	Remove an existing resource	No	Delete a VLAN, remove a static route, deprovision a device

HTTP Status Codes — Reading API Responses

Every HTTP response includes a status code. Knowing these is essential for writing Postman test scripts and diagnosing API failures:

Code	Category	Meaning	Common Cause
200	Success	OK — request succeeded; response body contains result	Successful GET, PUT, PATCH, DELETE
201	Success	Created — new resource successfully created	Successful POST
204	Success	No Content — request succeeded but no body returned	Successful DELETE
400	Client Error	Bad Request — malformed syntax, invalid JSON, missing required field	Typo in request body; wrong Content-Type header
401	Client Error	Unauthorised — authentication required or token invalid	Missing or expired Bearer token; wrong credentials
403	Client Error	Forbidden — authenticated but not permitted to perform this action	Insufficient privileges; RBAC policy denying access
404	Client Error	Not Found — the requested resource does not exist	Wrong URL path; resource ID that does not exist
500	Server Error	Internal Server Error — the API server encountered an unexpected error	Bug in the API; server overloaded; database error

3. Postman Interface — Key Components

Component	What It Does	Network Automation Use
Collections	Group related API requests into named folders; can be exported as JSON and shared	Organise all API calls for a device type (e.g., all Cisco DNA Center endpoints in one collection)
Requests	Individual HTTP requests — define method, URL, headers, authentication, and body per request	One request per API operation: GET interfaces, POST VLAN, DELETE route, etc.
Environments	Named sets of variables — switch between environments (dev/test/prod) without editing request URLs	Store different controller IPs, API tokens, and credentials per environment
Variables	Placeholders in double braces (`{{name}}`) that resolve to values at runtime; scoped globally, per-environment, per-collection, or per-request	`{{base_url}}`, `{{auth_token}}`, `{{vlan_id}}` — keep requests reusable
Pre-request Scripts	JavaScript that runs before a request is sent — used to generate tokens, set dynamic variables, or prepare the request	Auto-fetch and store auth token before every API call in the collection
Tests tab	JavaScript that runs after a response is received — used to validate status codes, response body fields, and timing; results shown in the Test Results panel	Assert that a VLAN was created (status 201), that the returned VLAN ID matches the one sent, and that RTT is under 500ms
Collection Runner	Run an entire collection sequentially with optional data files (CSV/JSON) to iterate over multiple inputs	Provision 50 VLANs from a CSV file in one run
Workspaces	Personal or team project spaces with version history and collaboration features	Team workspace for the NOC to share and maintain all network API collections

4. Postman Variables and Environments — In Depth

Variables eliminate hardcoded values from requests, making collections portable across environments. Variable resolution follows a scope hierarchy — more specific scopes override broader ones:

  Variable scope (highest priority first):
  Request variable → Data variable (Collection Runner CSV) →
  Local variable (set in script) → Environment variable →
  Collection variable → Global variable

  Practical example:
  ┌─────────────────────────────────────────────────────────────┐
  │ Environment: Production                                      │
  │   base_url = https://dnac.prod.example.com                  │
  │   auth_token = eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ...     │
  │                                                             │
  │ Environment: Lab                                             │
  │   base_url = https://10.10.20.85                            │
  │   auth_token = eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ...     │
  └─────────────────────────────────────────────────────────────┘

  Request URL (same for both environments):
  GET  {{base_url}}/api/v1/network-device

  Switch from Lab to Production: change active environment → no URL edits needed.

Setting Variables from Scripts

  // Pre-request Script — fetch token and store it as environment variable:
  pm.sendRequest({
    url: pm.environment.get("base_url") + "/api/v1/auth/token",
    method: "POST",
    header: { "Content-Type": "application/json" },
    body: {
      mode: "raw",
      raw: JSON.stringify({
        username: pm.environment.get("username"),
        password: pm.environment.get("password")
      })
    }
  }, function(err, res) {
    pm.environment.set("auth_token", res.json().Token);
  });

  // Test Script — validate response and extract a value:
  pm.test("Status is 200", function () {
    pm.response.to.have.status(200);
  });

  pm.test("VLAN ID matches request", function () {
    var jsonData = pm.response.json();
    pm.expect(jsonData.vlanId).to.eql(200);
  });

  // Store returned device ID for use in the next request:
  var responseJson = pm.response.json();
  pm.environment.set("device_id", responseJson.id);

5. Newman — Running Postman Collections from the CLI

Newman is the official command-line companion to Postman. It executes Postman collections without the GUI, making it the bridge between Postman and CI/CD pipelines. Newman produces pass/fail test results and rich reports in multiple formats.

  Install Newman (requires Node.js):
  npm install -g newman

  Basic collection run:
  newman run MyCollection.json

  Run with a specific environment:
  newman run MyCollection.json -e ProductionEnv.json

  Run with a data file (iterate over CSV rows):
  newman run VlanProvision.json -d vlans.csv

  Run with HTML report output:
  newman run MyCollection.json -e ProdEnv.json --reporters html --reporter-html-export report.html

  Common flags:
  -e  --environment   Environment file
  -d  --iteration-data  CSV/JSON data file for Collection Runner
  -n  --iteration-count  Number of times to run the collection
  --delay-request   Milliseconds to wait between requests
  --reporters       Output format: cli, json, html, junit

  CI/CD integration example (Jenkins pipeline snippet):
  pipeline {
    stages {
      stage('API Regression Tests') {
        steps {
          sh 'newman run collections/NetworkAPI.json \
                -e environments/Production.json \
                --reporters cli,junit \
                --reporter-junit-export results/api-test-results.xml'
        }
      }
    }
  }
  // If any Postman test assertion fails, Newman exits with a non-zero code
  // → Jenkins marks the build as FAILED automatically

6. Complete Postman Scenario — Cisco DNA Center VLAN Workflow

A network engineer needs to create VLAN 200 ("Engineering") on the fabric managed by Cisco DNA Center using its REST API. The workflow requires authentication first, then the VLAN creation, then verification.

  Environment variables set up:
    base_url   = https://sandboxdnac.cisco.com
    username   = devnetuser
    password   = Cisco123!
    auth_token = (will be set by the first request)

  ── Request 1: Authenticate ──────────────────────────────────────
  Method:  POST
  URL:     {{base_url}}/dna/system/api/v1/auth/token
  Auth:    Basic Auth (username + password)
  Body:    none

  Expected response (200):
  {
    "Token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9..."
  }

  Test Script:
  pm.test("Status 200", () => pm.response.to.have.status(200));
  pm.environment.set("auth_token", pm.response.json().Token);

  ── Request 2: Create VLAN ────────────────────────────────────────
  Method:  POST
  URL:     {{base_url}}/api/v1/network/vlan
  Headers: X-Auth-Token: {{auth_token}}
           Content-Type: application/json
  Body:
  {
    "vlanId": 200,
    "vlanName": "Engineering"
  }

  Expected response (201):
  {
    "executionId": "b47e8f12-...",
    "executionStatusUrl": "/dna/intent/api/v1/task/b47e8f12-..."
  }

  Test Script:
  pm.test("VLAN created (201)", () => pm.response.to.have.status(201));

  ── Request 3: Verify VLAN Exists ────────────────────────────────
  Method:  GET
  URL:     {{base_url}}/api/v1/network/vlan/200
  Headers: X-Auth-Token: {{auth_token}}

  Expected response (200) body snippet:
  {
    "vlanId": 200,
    "vlanName": "Engineering"
  }

  Test Script:
  pm.test("VLAN 200 exists", function() {
    pm.expect(pm.response.json().vlanName).to.eql("Engineering");
  });

7. Ansible — Agentless Network Automation

What Is Ansible?

Ansible is an open-source, agentless automation platform developed by Red Hat. "Agentless" means that no additional software needs to be installed on the devices being managed — Ansible connects to them over SSH (for Linux servers) or over the device's API/SSH (for network devices like Cisco IOS, NX-OS, Arista EOS, Juniper JunOS). This makes deployment extremely simple and is the characteristic that most distinguishes Ansible from tools like Chef or Puppet, which require an agent to be installed and running on every managed node.

  Ansible Architecture:

  ┌──────────────────────┐       SSH / API / NETCONF
  │    Control Node       │ ──────────────────────────→  Cisco Switch
  │  (admin PC or CI/CD) │                              Cisco Router
  │                      │ ──────────────────────────→  Arista Switch
  │  ansible installed   │                              Linux Server
  │  playbooks stored    │ ──────────────────────────→  Juniper Router
  │  inventory here      │
  └──────────────────────┘

  No agents on managed devices — Ansible connects, runs tasks, disconnects.
  Python-based modules are transferred and executed temporarily, then removed.

Core Concepts

Concept	Description	File/Format
Inventory	List of all managed hosts and devices, optionally organised into named groups (by role, site, vendor, etc.)	INI format (`inventory.ini`) or YAML; can also be dynamic (generated from a CMDB or cloud API)
Playbook	The automation workflow — one or more "plays" that target a host group and define a list of tasks to execute in sequence	YAML (`playbook.yml`); must start with `---`
Play	A single section within a playbook that maps a set of tasks to a target group of hosts	Defined by `- hosts:` in the playbook
Task	An individual action — calls a module with specific parameters; tasks run in the order listed	YAML block under `tasks:`
Module	A reusable unit of code that performs a specific function — Ansible ships with hundreds of built-in modules; community modules add thousands more	Referenced by name in tasks (e.g., `ios_config:`)
Variables	Named values used in playbooks and templates; can be defined in the inventory, in variable files, passed on the command line, or set dynamically	Referenced with `{{ variable_name }}` (Jinja2 syntax)
Handlers	Tasks that only run when notified by another task — typically used to restart services or reload configurations after a change	Defined under `handlers:`
Roles	A structured directory layout for reusable automation — bundles playbooks, tasks, handlers, templates, variables, and files for a specific function (e.g., "configure-ospf")	Defined directory structure under `roles/`
Ansible Vault	Built-in encryption for sensitive data — passwords, API keys, and tokens can be stored encrypted in playbooks or variable files	Encrypted with AES-256; decrypted at runtime with a vault password

8. Ansible Inventory File

The inventory tells Ansible which devices to manage and how to connect to them. Groups allow a single playbook to target different device sets.

  INI-format inventory (inventory.ini):
  ────────────────────────────────────────────────────────
  [core_switches]
  core1 ansible_host=10.0.0.1 ansible_network_os=ios ansible_user=admin ansible_password=Cisco123!
  core2 ansible_host=10.0.0.2 ansible_network_os=ios ansible_user=admin ansible_password=Cisco123!

  [access_switches]
  access1 ansible_host=10.0.1.10 ansible_network_os=ios ansible_user=admin ansible_password=Cisco123!
  access2 ansible_host=10.0.1.11 ansible_network_os=ios ansible_user=admin ansible_password=Cisco123!

  [arista_switches]
  eos1 ansible_host=10.0.2.1 ansible_network_os=eos ansible_user=admin ansible_password=arista123

  [all_switches:children]
  core_switches
  access_switches
  arista_switches
  ────────────────────────────────────────────────────────

  Key connection variables:
  ansible_host         → IP address or hostname of the device
  ansible_network_os   → tells Ansible which module family to use
                         (ios, nxos, eos, junos, etc.)
  ansible_user         → SSH username
  ansible_password     → SSH password (better: use Ansible Vault)
  ansible_become       → yes/no for privilege escalation
  ansible_become_method → enable (for Cisco IOS)
  ansible_connection   → network_cli (IOS), httpapi (NX-OS/DNA Center)

9. Ansible Playbook — YAML Syntax and Structure

Playbooks are YAML files. YAML uses indentation (2 spaces, never tabs) to represent structure. A playbook contains one or more plays, each targeting a host group and listing tasks to execute.

  Annotated playbook structure:

  ---                          ← YAML document start (required)
  - name: Configure VLANs      ← play name (human-readable description)
    hosts: access_switches     ← which inventory group to target
    gather_facts: no           ← skip automatic fact gathering (faster for network devices)
    connection: network_cli    ← use SSH CLI mode for network devices

    vars:                      ← variables scoped to this play
      vlan_id: 200
      vlan_name: Engineering

    tasks:                     ← list of tasks — run in order, top to bottom
      - name: Create VLAN {{ vlan_id }}    ← task name (shown in output)
        ios_config:                         ← module to call
          lines:                            ← module parameter
            - vlan {{ vlan_id }}
            - name {{ vlan_name }}
        register: vlan_result              ← save the module output to a variable

      - name: Verify VLAN was created      ← second task
        ios_command:
          commands:
            - show vlan brief
        register: vlan_output

      - name: Display VLAN output          ← debug task for visibility
        debug:
          var: vlan_output.stdout_lines

Idempotency — The Critical Property

Idempotency means that running the same playbook multiple times produces the same end result — it will not create duplicate VLANs or apply duplicate configuration lines. Ansible modules check the current state before making changes and only apply a change if the current state differs from the desired state.

  Idempotency in practice:

  Run 1 (VLAN 200 does not exist):
  TASK [Create VLAN 200] → changed: [access1]   ← change was applied

  Run 2 (VLAN 200 already exists):
  TASK [Create VLAN 200] → ok: [access1]         ← no change needed

  Run 3 (same):
  TASK [Create VLAN 200] → ok: [access1]         ← still no change

  Safe to run in a scheduled job or CI/CD pipeline without risk
  of creating duplicate configuration or breaking a working device.

10. Key Ansible Modules for Network Automation

Module	Platform	Purpose	Example Use
ios_config	Cisco IOS / IOS-XE	Push configuration lines; compares desired lines against running config and only applies differences	Configure VLANs, interfaces, routing protocols, ACLs on IOS switches and routers
ios_command	Cisco IOS / IOS-XE	Run show commands and return output for parsing or verification; does not change config	`show version`, `show ip route`, `show vlan brief`
ios_facts	Cisco IOS / IOS-XE	Gather structured facts about the device — hostname, version, interfaces, routing — for use in templates or conditionals	Collect device inventory automatically from all managed routers
nxos_config	Cisco NX-OS	Push configuration to Nexus data-centre switches	Configure VPC, VRF, BGP on Nexus 9000 series
eos_config	Arista EOS	Push configuration to Arista switches	Configure MLAG, BGP, VLANs on Arista EOS
junos_config	Juniper JunOS	Push configuration to Juniper routers and switches	Configure interfaces, routing policies on MX/EX series
net_vlan	Multi-vendor	Vendor-agnostic VLAN management — works across IOS, NX-OS, EOS using a single task	Provision the same VLAN on a mixed-vendor environment with one play
uri	Any (HTTP/REST)	Make HTTP requests to REST APIs from within Ansible — enables Ansible to interact with any REST API	Call Cisco DNA Center API, Meraki API, or any RESTCONF endpoint

11. Ansible Vault — Securing Secrets

Storing passwords and API tokens in plain text in inventory files or playbooks is a significant security risk — especially when those files are committed to a Git repository. Ansible Vault solves this by encrypting sensitive data with AES-256.

  Create an encrypted variable file:
  ansible-vault create secrets.yml
  (prompted for a vault password)

  Edit an existing encrypted file:
  ansible-vault edit secrets.yml

  Encrypt a single string value (for embedding in a playbook):
  ansible-vault encrypt_string 'Cisco123!' --name 'ansible_password'
  Output:
  ansible_password: !vault |
    $ANSIBLE_VAULT;1.1;AES256
    62343132313234313...

  Run a playbook using vault-encrypted data:
  ansible-playbook playbook.yml --ask-vault-pass
  (or)
  ansible-playbook playbook.yml --vault-password-file ~/.vault_pass.txt

  View without decrypting:
  ansible-vault view secrets.yml

  Rekey (change the vault password):
  ansible-vault rekey secrets.yml

12. Jinja2 Templates in Ansible

Jinja2 is the templating engine built into Ansible. It allows dynamic generation of configuration files — a single template can produce unique device configurations for hundreds of devices by substituting variables, running loops, and applying conditional logic.

  Template file: interface_config.j2
  ────────────────────────────────────────
  interface {{ interface_name }}
   description {{ description }}
   ip address {{ ip_address }} {{ subnet_mask }}
   no shutdown
  {% if ospf_enabled %}
   ip ospf {{ ospf_process_id }} area {{ ospf_area }}
  {% endif %}
  ────────────────────────────────────────

  Variables in playbook:
  vars:
    interface_name: GigabitEthernet0/1
    description: "Uplink to Core"
    ip_address: 192.168.10.1
    subnet_mask: 255.255.255.0
    ospf_enabled: true
    ospf_process_id: 1
    ospf_area: 0

  Task using the template:
  - name: Generate interface config
    template:
      src: interface_config.j2
      dest: /tmp/interface_config.cfg

  Generated output:
  interface GigabitEthernet0/1
   description Uplink to Core
   ip address 192.168.10.1 255.255.255.0
   no shutdown
   ip ospf 1 area 0

13. Complete Ansible Scenario — Multi-VLAN Provisioning

An engineer needs to provision VLANs 100, 200, and 300 on all access switches, using variables for reusability and Ansible Vault for credentials.

  ── inventory.ini ────────────────────────────────────────────────
  [access_switches]
  access1 ansible_host=10.0.1.10
  access2 ansible_host=10.0.1.11
  access3 ansible_host=10.0.1.12

  [access_switches:vars]
  ansible_network_os=ios
  ansible_user=admin
  ansible_connection=network_cli
  ansible_become=yes
  ansible_become_method=enable

  ── secrets.yml (encrypted with Ansible Vault) ───────────────────
  ansible_password: !vault |
    $ANSIBLE_VAULT;1.1;AES256
    62343132...

  ── vlan_vars.yml ────────────────────────────────────────────────
  vlans:
    - id: 100
      name: Sales
    - id: 200
      name: Engineering
    - id: 300
      name: Management

  ── vlan_provision.yml (playbook) ────────────────────────────────
  ---
  - name: Provision VLANs on Access Switches
    hosts: access_switches
    gather_facts: no
    vars_files:
      - secrets.yml
      - vlan_vars.yml

    tasks:
      - name: Create each VLAN
        ios_config:
          lines:
            - vlan {{ item.id }}
            - name {{ item.name }}
        loop: "{{ vlans }}"
        loop_control:
          label: "VLAN {{ item.id }} - {{ item.name }}"

      - name: Verify VLANs created
        ios_command:
          commands: show vlan brief
        register: vlan_output

      - name: Display result
        debug:
          var: vlan_output.stdout_lines

  ── Execute ───────────────────────────────────────────────────────
  ansible-playbook -i inventory.ini vlan_provision.yml --ask-vault-pass

  ── Sample output ─────────────────────────────────────────────────
  PLAY [Provision VLANs on Access Switches] ****
  TASK [Create each VLAN] ****
    changed: [access1] => (item=VLAN 100 - Sales)
    changed: [access1] => (item=VLAN 200 - Engineering)
    changed: [access1] => (item=VLAN 300 - Management)
    changed: [access2] => (item=VLAN 100 - Sales)
    ...
  PLAY RECAP ****
  access1: ok=3  changed=1  unreachable=0  failed=0
  access2: ok=3  changed=1  unreachable=0  failed=0
  access3: ok=3  changed=1  unreachable=0  failed=0

14. Postman vs Ansible — When to Use Each

Dimension	Postman	Ansible
Primary use	Exploring, testing, and debugging REST APIs; API-driven workflow automation	Configuration management; bulk provisioning; multi-device automation at scale
Interface	Graphical (GUI) with optional CLI via Newman	Command-line; YAML-based declarative files
Transport	HTTP/HTTPS (REST APIs, RESTCONF)	SSH, network_cli, httpapi, NETCONF
Automation language	JavaScript (test scripts, pre-request scripts)	YAML (playbooks); Jinja2 (templates)
Idempotency	Not inherent — depends on API and test logic	Built-in — modules check state before applying
Multi-vendor	Works with any HTTP API regardless of vendor	Vendor-specific modules (ios, nxos, eos, junos) plus generic `net_*` and `uri` modules
Best for	API exploration; CI/CD API regression tests; SDN controller interaction; development teams documenting APIs	Mass device provisioning; configuration drift correction; scheduled compliance checks; multi-vendor environments
CCNA DevNet relevance	Understanding REST API concepts, HTTP methods, and JSON — directly tested	Understanding agentless automation, YAML syntax, playbook structure, and idempotency — directly tested

15. Troubleshooting Common Issues

Tool	Symptom	Likely Cause	Fix
Postman	401 Unauthorised on every request	Auth token missing, expired, or not in the correct header	Re-run the auth request to get a fresh token; verify the header name matches what the API expects (Authorization vs X-Auth-Token vs api-key)
Postman	400 Bad Request on POST/PUT	Malformed JSON body; wrong Content-Type header; missing required field	Check the JSON syntax in the body tab; ensure `Content-Type: application/json` header is set; compare body to API documentation
Postman	Could not send request / SSL error	Self-signed certificate on lab device; HTTPS strict validation failing	In Postman settings, disable SSL certificate verification for lab environments (never in production)
Ansible	UNREACHABLE — SSH connection failed	Wrong IP in inventory; SSH not enabled on device; firewall blocking port 22; wrong credentials	Test manually: `ssh [email protected]`; verify `ansible_host` IP; check `ansible_user` and `ansible_password`; confirm SSH is enabled on the device
Ansible	YAML syntax error / parsing failed	Incorrect indentation (tabs instead of spaces); missing colon after key; unclosed string	Validate YAML with `yamllint playbook.yml` before running; use a YAML-aware editor; never use tabs — always 2 spaces
Ansible	Module not found / No module named ios_config	Missing Ansible collections for network devices	Install the required collection: `ansible-galaxy collection install cisco.ios`
Ansible	Decryption failed — vault password wrong	Wrong vault password provided at runtime	Re-encrypt with the correct password: `ansible-vault rekey secrets.yml`; or use a password file with `--vault-password-file`

Ansible Verbosity Flags

  ansible-playbook playbook.yml -v     # Basic verbose — show task results
  ansible-playbook playbook.yml -vv    # Show files and directories searched
  ansible-playbook playbook.yml -vvv   # Show SSH connection details
  ansible-playbook playbook.yml -vvvv  # Show all connection debug info

  Dry run (check mode — don't actually make changes):
  ansible-playbook playbook.yml --check

  List hosts that will be targeted:
  ansible-playbook playbook.yml --list-hosts

  Limit execution to specific hosts or groups:
  ansible-playbook playbook.yml --limit access1
  ansible-playbook playbook.yml --limit access_switches

16. Exam Tips & Key Points

Postman: Know the five HTTP methods and their CRUD equivalents — GET (Read), POST (Create), PUT (Update/Replace), PATCH (Update/Partial), DELETE (Delete).
Know the key HTTP status codes: 200 (OK), 201 (Created), 400 (Bad Request), 401 (Unauthorised), 403 (Forbidden), 404 (Not Found), 500 (Server Error).
Postman variables use {{double_braces}}. Environments are named sets of variables — switch environment to change all variable values at once without editing requests.
Newman is the CLI tool that runs Postman collections — it integrates Postman with CI/CD pipelines (Jenkins, GitLab CI, Azure DevOps).
Ansible is agentless — no software installed on managed devices; connects over SSH or API.
Ansible playbooks are written in YAML — indentation is significant; 2 spaces, never tabs.
Ansible idempotency — running the same playbook multiple times produces the same result; modules check current state before applying changes.
Know the three-part Ansible topology: Control Node (where Ansible runs), Managed Nodes (devices being configured), Inventory (list of managed nodes).
Key modules: ios_config (push IOS config lines), ios_command (run show commands), ios_facts (gather device facts).
Ansible Vault encrypts sensitive data (passwords, tokens) with AES-256; run playbooks with --ask-vault-pass or a vault password file.
Jinja2 templates use {{ variable }}, {% if condition %}, and {% for item in list %} to dynamically generate device configurations.

17. Summary Reference Table

Topic	Postman	Ansible
Primary role	REST API testing and development	Agentless configuration management and automation
Language	JavaScript (scripts); JSON (collections)	YAML (playbooks); Jinja2 (templates)
HTTP methods	GET, POST, PUT, PATCH, DELETE	N/A directly (uses `uri` module for REST)
Variable syntax	`{{variable_name}}`	`{{ variable_name }}`
CLI/automation tool	Newman (`newman run collection.json`)	`ansible-playbook playbook.yml`
Secrets management	Environments (not encrypted by default)	Ansible Vault (AES-256 encryption)
Key network module	Any REST API endpoint	`ios_config`, `ios_command`, `ios_facts`
Idempotency	Not built-in	Built-in at module level

Postman and Ansible Quiz

1. What is the primary role of Postman in network automation workflows?

A. Network packet capture and deep protocol analysis — it captures raw traffic on an interface for troubleshooting B. REST API development, testing, and automation — it sends HTTP requests to programmable network controllers, devices, and cloud platforms and validates their responses C. Firewall policy configuration — it generates ACL rules and pushes them to network devices over SSH D. Physical device monitoring — it polls SNMP MIBs and displays interface utilisation graphs

Correct answer is B. Postman is an API development and testing platform that allows engineers to construct and send HTTP requests (GET, POST, PUT, PATCH, DELETE), inspect responses, write automated test scripts in JavaScript, and organise API calls into reusable collections. In networking it is used to interact with the REST APIs of SDN controllers (Cisco DNA Center, NSO), cloud management platforms, and any device or service that exposes a RESTCONF or vendor REST API. It is not a packet capture tool (that is Wireshark), not directly a firewall config tool, and not an SNMP monitoring platform.

2. An engineer needs to fully replace an existing VLAN configuration resource on a Cisco DNA Center via its REST API. Which HTTP method should be used?

A. GET — retrieves the current VLAN resource without modifying it B. DELETE — removes the VLAN resource from the controller C. POST — creates a new VLAN resource; used when the resource does not yet exist D. PUT — replaces an existing resource completely with the data in the request body; the correct choice when updating an existing VLAN's full configuration

Correct answer is D. REST APIs map operations to HTTP methods in a standardised way. PUT replaces an existing resource in its entirety — the body of the PUT request becomes the new complete state of the resource. If the resource does not exist, some APIs will create it; if it does exist, it is replaced. PATCH (not listed here) performs a partial update — only the fields in the PATCH body are changed. POST creates a new resource (maps to Create). GET reads without modifying (maps to Read). DELETE removes the resource (maps to Delete). The CRUD mapping is: Create→POST, Read→GET, Update→PUT/PATCH, Delete→DELETE.

3. An engineer has a Postman collection that runs against a lab controller. They need to run the same collection against the production controller without editing any request URLs. How should they achieve this?

A. Create two Postman environments — "Lab" and "Production" — each defining the same variable names (such as base_url and auth_token) with different values; switch the active environment to change all requests instantly without editing URLs B. Duplicate the collection and manually update every URL in the new copy to point to the production controller C. Create a new Postman workspace for production and migrate all requests into it D. Generate new API documentation for each environment and reference it manually

Correct answer is A. Postman environments and variables are the solution to this exact problem. A variable like {{base_url}} in a request URL resolves to the value set in the currently active environment. By defining two environments — one with base_url = https://lab.controller.com and another with base_url = https://prod.controller.com — the engineer can switch between them with a single click in the environment selector, and every request in the collection immediately uses the new value. This is the primary use case for Postman environments: separating credentials, base URLs, and configuration values by deployment stage (lab, staging, production) while keeping request logic identical.

4. In Ansible's architecture, what is the Control Node and what is distinctive about the Managed Nodes?

A. The Control Node is a managed device that receives and executes tasks; Managed Nodes are the admin workstations running Ansible B. The Control Node is a network device with Ansible pre-installed; Managed Nodes are the CI/CD servers that trigger playbook runs C. The Control Node is the machine where Ansible is installed and playbooks are executed from; Managed Nodes are the devices being configured and require no Ansible software — Ansible connects to them over SSH or API D. The Control Node is an Ansible agent running on each managed device; Managed Nodes are the servers that distribute playbooks to those agents

Correct answer is C. Ansible's architecture is built around a single Control Node — the machine (workstation, server, or CI/CD runner) where the ansible and ansible-playbook commands run, where playbook files and the inventory are stored, and from which all connections originate. Managed Nodes are the devices being configured — routers, switches, servers. Critically, they require no Ansible installation whatsoever. This "agentless" design is Ansible's defining architectural characteristic and is what differentiates it from tools like Puppet (requires a Puppet agent on every managed node) and Chef (requires a Chef client). Ansible connects to network devices over SSH (network_cli) or via their HTTP API (httpapi), executes tasks, and then disconnects.

5. What file format are Ansible playbooks written in, and what is one critical syntax requirement that causes errors if violated?

A. JSON — playbooks use curly brace notation; missing commas cause parse errors B. YAML — playbooks use YAML indentation-based structure; using tabs instead of spaces causes parse errors because YAML requires consistent space indentation C. XML — playbooks use angle-bracket tags; unclosed tags cause parse errors D. INI — playbooks use section headers and key=value pairs like inventory files

Correct answer is B. Ansible playbooks use YAML (Yet Another Markup Language) — a human-readable data serialisation format that uses indentation to represent structure. The critical syntax rule in YAML is that indentation must use spaces, never tabs. YAML parsers treat tabs as invalid characters — a single tab in a playbook will cause a parsing error. The standard is 2 spaces per indentation level. Additionally, playbooks must begin with --- (YAML document start marker), list items begin with -, and key-value pairs use key: value notation. Note that inventory files can be in INI format, but playbooks are always YAML.

6. What does "agentless" mean in the context of Ansible, and why does this matter for network device automation?

A. Ansible does not require installation on the Control Node — it runs as a hosted cloud service that manages devices remotely B. Ansible only works with Windows devices because Linux devices require a resident agent C. Ansible requires a lightweight agent installed on each managed device, but the agent is self-managing and requires no ongoing maintenance D. No software agent needs to be installed or maintained on the managed devices — Ansible connects via SSH or the device's API, executes tasks, then disconnects; this is critical for network devices because Cisco IOS, for example, cannot run third-party agents

Correct answer is D. Agentless operation is one of the most important aspects of Ansible, especially in a network context. Traditional automation tools like Puppet and Chef require a software agent to be permanently installed and running on every managed node. For general Linux servers this is feasible. For network devices (Cisco IOS routers, Arista switches, Juniper routers) it is impossible — these operating systems do not provide a mechanism to install and run arbitrary third-party software. Ansible solves this by using only the device's existing remote access mechanism: SSH (network_cli connection type) or the device's built-in HTTP API (httpapi connection type). No pre-installation, no ongoing agent management, no agent version compatibility issues.

7. What is Newman and in what scenario is it specifically useful compared to the Postman GUI?

A. Newman is Postman's official command-line runner — it executes Postman collections without a GUI, making it ideal for integrating API regression tests into CI/CD pipelines where no graphical interface is available B. Newman is a Jenkins plugin that generates Postman collection files from Jenkins pipeline definitions C. Newman is a Docker container that runs Ansible playbooks inside an isolated environment D. Newman is Ansible Tower's web interface for scheduling and monitoring playbook runs

Correct answer is A. Newman is the official Node.js-based CLI companion to Postman. The key use case is CI/CD integration — when a network configuration change is committed to a Git repository, a CI/CD pipeline (Jenkins, GitLab CI, Azure DevOps) automatically runs Newman to execute a Postman collection of API regression tests against the updated system. If any test assertions fail, Newman exits with a non-zero code, the CI pipeline marks the build as failed, and the change is not deployed. This gives network teams automated, continuous validation of their API-driven infrastructure with every commit. Newman can also produce reports in CLI, HTML, JSON, and JUnit XML formats for integration with test reporting dashboards.

8. What does an Ansible inventory file define, and what are the two main formats it can use?

A. It defines the tasks and modules to run — written in YAML, it is essentially another name for a playbook B. It defines encrypted secrets such as passwords and API tokens — it is the Ansible Vault file by another name C. It defines the target hosts and devices Ansible will manage, their connection parameters, and how they are organised into groups — it can be written in INI format or YAML format D. It defines Jinja2 templates for dynamic configuration generation — it is stored in the templates/ directory of a role

Correct answer is C. The Ansible inventory file is the source of truth for which devices Ansible manages. It lists each device's hostname or IP, the connection variables needed to reach it (ansible_host, ansible_user, ansible_password, ansible_network_os, ansible_connection), and organises devices into named groups (e.g., [core_switches], [access_switches]). Playbooks then reference these group names in their hosts: field to target specific subsets of devices. The inventory can be written in INI format (the classic, simple format with [group_name] headers) or YAML format (more structured). Inventories can also be dynamic — a script that queries a CMDB, cloud API, or DNS to generate the host list at runtime rather than maintaining a static file.

9. What is Ansible Vault used for, and how is a playbook that uses Vault-encrypted variables executed?

A. Ansible Vault automates deployments by scheduling playbook runs at defined intervals B. Ansible Vault encrypts sensitive data such as passwords, API keys, and tokens using AES-256; a playbook using Vault-encrypted variables is executed with the --ask-vault-pass flag (prompts interactively) or --vault-password-file pointing to a file containing the vault password C. Ansible Vault monitors network device health and triggers playbooks when thresholds are exceeded D. Ansible Vault is a GUI dashboard for running and monitoring playbook executions — it is the enterprise version of Ansible

Correct answer is B. Ansible Vault is the built-in secrets management solution. Without Vault, passwords and API keys in inventory files and playbooks are stored in plain text — a serious security risk, especially when those files are committed to version control systems like Git. Vault encrypts any file or individual string values using AES-256 encryption. Encrypted values are tagged with the !vault YAML type and cannot be read without the vault password. At runtime, Ansible decrypts them in memory and uses the plain-text values for connections. The two primary runtime methods are: --ask-vault-pass (prompts for password interactively — good for manual runs) and --vault-password-file <path> (reads from a file — good for CI/CD pipelines where interactive input is not possible).

10. What does idempotency mean in Ansible, and why is it particularly valuable for network automation?

A. Idempotency means the playbook runs as fast as possible — duplicate tasks are automatically removed to optimise performance B. Idempotency means the playbook can only be run once — re-running it causes an error to prevent accidental duplicate changes C. Idempotency means Postman collections and Ansible playbooks can be used interchangeably for the same task D. Idempotency means running the same playbook multiple times always produces the same end state — Ansible modules check current device state before applying changes and only make a change if the current state differs from the desired state; this makes scheduled or repeated runs safe

Correct answer is D. Idempotency is one of the most important properties of Ansible and appears directly in the CCNA curriculum. An idempotent operation produces the same result regardless of how many times it is applied. In Ansible, modules achieve this by comparing the desired state (what the playbook specifies) against the current state (what is actually on the device). If VLAN 200 already exists when an ios_config task runs to create it, the task reports ok (no change needed) rather than attempting to create it again. This is especially valuable for network automation because: (1) playbooks can be scheduled and run repeatedly for compliance checking without risk of breaking working configs; (2) CI/CD pipelines can run the same playbook on every code commit; (3) after a device reload, the playbook can be re-run to restore all desired configuration without manually identifying what is missing.

← Back to Home