Cisco 350-401: Automation, Programmability and APIs — Study Guide

By Laurynas Brazys · 15 August 2026 · #cisco #350-401 #certification #exam-prep #study-guide

Part of the Cisco CCNP Enterprise 350-401 ENCOR — Study Guide. Practice with verified answers in the Cisco exam hub, or take timed practice tests on ExamRoll.io.

Overview

Enterprise networks are moving from device-by-device configuration toward controller-based, intent-driven operations with closed-loop automation. Programmability exposes network state and control through APIs and data models, while tools like Python, Ansible, and Git enable repeatable, testable workflows. The goal is to express desired outcomes declaratively, have controllers translate intent into policy and configuration, measure results through telemetry and assurance, and remediate deviations automatically or with human approval. Achieving this requires understanding controller roles, APIs and protocols (REST, NETCONF/RESTCONF with YANG), data formats (JSON, XML, YAML), automation platforms (Cisco DNA Center), and operational disciplines (idempotency, version control, testing, risk management, and rollback).

Controllers, Intent, and Closed-Loop Operations

• Controller-based networking and roles:
  • Cisco SD-WAN separates planes: vManage provides the single management plane; vSmart manages the control plane and distributes policies that steer data forwarding across the fabric; vBond orchestrates onboarding and can act as a STUN server to traverse NAT. SD‑WAN edge routers use OMP as the control-plane protocol to communicate with vSmart.
  • Cisco SD‑Access creates an overlay network that provides logical Layer 2 and Layer 3 separation. A fabric control-plane node maintains a global endpoint-to-location database, while a fabric border node connects the fabric to external networks. In wireless, Radio Resource Management runs on the wireless controller.
• Intent and declarative configuration:
  • Intent describes the desired outcome, not how to implement it on each device. Declarative systems (for example, “segment guests everywhere with Internet-only access”) allow controllers to compile policy into device-specific configurations.
  • Trade-offs: Declarative models simplify operations and reduce drift, but can conceal implementation details. Operators need transparent tooling for diff/preview and rollback to maintain trust.
• Closed-loop operations:
  • Measure: Collect state via streaming telemetry and controller assurance.
  • Analyze: Detect deviations from intent (for example, segmentation violations, SLA drops).
  • Act: Remediate through policy updates, configuration changes, or traffic engineering.
  • Failure modes: Event storms or noisy telemetry can trigger false positives; remediation loops can oscillate. Guardrails (rate limits, hysteresis, human-in-the-loop approvals) and robust correlation prevent thrashing.

APIs, Data Models, and Protocols

• REST APIs:
  • Methods: GET (read), POST (create/action), PUT (replace), PATCH (partial update), DELETE (remove), HEAD/OPTIONS (metadata).
  • Status codes: 2xx success (200 OK, 201 Created), 3xx redirects, 4xx client errors (400 bad input, 401 unauthorized, 403 forbidden, 404 not found, 409 conflict, 429 rate limit), 5xx server errors (500, 503).
  • Authentication: Basic (over TLS), token/bearer schemes, and OAuth 2.0. Always use TLS; avoid embedding credentials in URIs. Handle token refresh and expiry.
  • Rate limits: Servers may throttle with 429 and Retry-After. Implement exponential backoff, jitter, and request budget tracking in clients.
• Data formats and validation:
  • JSON is common for REST; XML remains prevalent in NETCONF; YAML is used for human-authored files (inventories, playbooks, variable sets). Convert YAML to JSON internally when needed.
  • Schema validation: Use JSON Schema for JSON payloads; XML Schema for XML; YANG for model-based management (types, constraints, must/when statements). Validate client-side before sending to catch errors early.
• NETCONF, RESTCONF, YANG, RPCs, and datastores:
  • YANG models define data structures and operations for configuration and state.
  • NETCONF uses XML over SSH, operations like , , , , , . Datastores typically include running and candidate; candidate enables prepare-and-commit with atomicity.
  • RESTCONF maps YANG-modeled resources to a RESTful interface over HTTP(S), using JSON or XML with standardized media types. Methods map to NETCONF semantics (PATCH/PUT for edits).
  • Failure modes and design:
    • Lock contention: Coordinate to avoid deadlocks; use narrow scope and timeouts.
    • Partial failures: Prefer candidate datastore + for transactional changes. If only running is available, use structured change groups and checkpoints.
    • Model drift: Devices may support different YANG module revisions; negotiate capabilities and test during CI.
• Concise examples:
  • RESTCONF partial update (HTTP exchange): PATCH /restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet1 Content-Type: application/yang-data+json { “ietf-interfaces:interface”: { “name”: “GigabitEthernet1”, “description”: “Uplink”, “enabled”: true } }
  • NETCONF with Python (ncclient): from ncclient import manager cfg = """ GigabitEthernet1 Uplink true """ with manager.connect(host=“r1”, port=830, username=“netops”, password="***", hostkey_verify=False) as m: m.edit_config(target=“candidate”, config=cfg) m.commit()

Tooling and Workflows: Python, Ansible, Git, and Pipelines

• Cisco DNA Center automation:
  • Northbound REST APIs provide inventory, templates, provisioning, and assurance access. Southbound interfaces connect the controller to devices (CLI, SNMP, NETCONF/RESTCONF) to enact intent.
  • Discovery workflows can use CDP, LLDP, and IP ranges. Use role-based access control, project-based templates, and per-site variables. Assurance correlates telemetry into issues, health scores, and suggested remediations—key inputs to closed-loop automation.
• Python fundamentals for network automation:
  • Core language: types, functions, modules, virtual environments, and logging.
  • Libraries: requests/httpx (REST), ncclient (NETCONF), jinja2 (templating), pyyaml, json, pandas (data wrangling), rich/logging for observability.
  • Practices: input validation, retries with backoff, structured exceptions, timeouts, and unit tests. Serialize business logic away from I/O to simplify tests.
• Ansible:
  • Inventory defines hosts and groups; keep host_vars/group_vars in YAML.
  • Playbooks declare desired state; modules such as ios_config, ios_facts, iosxe_config, restconf_config, and uri perform actions. Use roles to encapsulate reusable logic.
  • Idempotency: Modules ensure repeated runs converge without unintended changes. Use check_mode and diff to preview; notify handlers to save only when changed.
  • Example:
    • hosts: edge connection: network_cli gather_facts: no tasks:
      • ios_config: parents: interface GigabitEthernet1 lines: - description Uplink notify: save handlers:
      • name: save ios_config: save_when: changed
  • Change control: use maintenance windows, serial or batched strategy, and per-site throttling to limit blast radius. Capture pre/post checks automatically.
• Git, versioning, testing, and pipelines:
  • Store network intent (YAML vars, Jinja templates, playbooks), generated configs, and tests in Git. Use branches, pull requests, and code review. Semantic commits and tags align versions with deployments.
  • Testing: lint YAML and playbooks, validate YANG/JSON schemas, run unit tests and Ansible Molecule scenario tests. Integrate synthetic prechecks (for example, reachability) in CI.
  • Pipelines: Dev → staging/lab → canary in production → phased rollout. Gates include static analysis, dry-runs against simulators, approvals, and automatic rollback on health regression.

Telemetry, Event-Driven Automation, and Risk Management

• Telemetry streaming:
  • Model-driven telemetry (IOS XE, NX-OS) publishes YANG-modeled state at defined intervals over gRPC/gNMI or NETCONF, with dial-in or dial-out subscriptions. Benefits include low latency and structured data, outperforming periodic CLI scraping or SNMP polling.
  • Example (IOS XE, concise): telemetry ietf subscription 100 encoding gpbid filter xpath /interfaces-state/interface receiver ip 10.0.0.50 port 57500 protocol grpc-tcp
  • Design tips: Align sampling frequency with use case; ensure message bus capacity; design downsampling/aggregation pipelines; protect against telemetry loss with buffering and acknowledgments.
• Event-driven automation:
  • Trigger actions on webhooks, syslog, SNMP traps, DNA Center events, or Kafka topics. Use correlation and rate limiting to avoid storm-induced flaps. Maintain idempotent handlers that can safely re-run.
  • Closed-loop: A controller detects a policy breach, validates with secondary signals, opens a change ticket or triggers a limited remediation, then re-measures and finalizes.
• Risk management, rollback, and credentials:
  • Guardrails: staged rollouts, concurrency limits, blast-radius controls, dynamic backoff on 429/5xx responses, and timeouts. Use transactions where available (NETCONF candidate + commit), or device checkpoints and configure replace.
  • Rollback: Maintain golden configs, diffs, and per-device checkpoints. Prefer commit-confirmed semantics where supported; otherwise implement automated fallback using timers and reachability checks.
  • Credential protection: enforce RBAC, short-lived tokens, and per-job just-in-time secrets. Use secret stores (for example, Ansible Vault or an external vault), never embed secrets in playbooks or Git. Rotate credentials on schedule and after personnel changes. Secure controller-to-device credentials and audit access.

Practical Problem Scenario

Aurelius Logistics plans to standardize campus and branch configurations, enforce consistent segmentation, and implement closed-loop assurance using Cisco DNA Center, while enabling safe changes via Ansible and Git.

1. Baseline and discover the network

• Rationale: DNA Center discovery using IP ranges plus CDP/LLDP enumerates devices and topology, establishing authoritative inventory. This enables intent scoping and variable inheritance by site. Collecting assurance data establishes pre-change health baselines for comparison and rollback triggers.

2. Model intent and templates in DNA Center

• Rationale: Express segmentation (for example, employee, IoT, guest) and QoS policies declaratively. Use parameterized templates with site variables for interfaces, routing, and ACLs. Declarative policy allows the controller to compile device-specific configs, reducing human error and drift.

3. Implement Git-driven configuration management

• Rationale: Store templates, site variables (YAML), and validation tests in Git. Feature branches and pull requests enforce peer review. Tags align deployments with versions, enabling precise rollback. This provides an auditable change history and supports automated pipeline triggers.

4. Build CI/CD pipeline with validation gates

• Rationale: Pipeline stages lint YAML, validate JSON/YANG payloads, unit-test Jinja rendering, and simulate API calls in a sandbox. DNA Center dry runs and Ansible check_mode/diff validate changes with no impact. Only upon passing all gates does the pipeline allow operator approval to proceed.

5. Deploy incrementally with Ansible and DNA Center APIs

• Rationale: Use DNA Center northbound APIs to push templates to a canary site first, then roll out serially by site with batch size limits. For devices supporting NETCONF/RESTCONF, Ansible modules perform targeted, idempotent updates. This dual approach leverages the controller for policy-heavy tasks and direct device automation for fine-grained changes, while minimizing blast radius.

6. Activate streaming telemetry and assurance-driven checks

• Rationale: Configure model-driven telemetry on edge devices to feed DNA Center Assurance and the company’s observability stack. Define SLOs (for example, onboarding success rate, latency) and event subscriptions that raise alerts if post-change metrics regress. This enables immediate detection of negative outcomes.

7. Enable controlled closed-loop remediation

• Rationale: For well-understood deviations (for example, interface down with known workaround), allow the pipeline to trigger a constrained playbook to revert the last change or apply a hotfix. Require human approval for broader remediations. Implement exponential backoff and cooldown to prevent oscillations.

8. Prepare and test rollback paths

• Rationale: Before each change, create device checkpoints or use NETCONF candidate + commit-confirmed if available. Archive pre-change configurations and tag the Git repository. If health scores drop or telemetry shows SLA breaches, the pipeline executes configure replace or NETCONF discard/rollback, restoring the prior state quickly.

9. Protect credentials and enforce access control

• Rationale: Store device/controller credentials in a vault; inject short-lived tokens into jobs. Use DNA Center RBAC to restrict API scopes. Never log secrets; scrub outputs in CI. Rotate credentials and tokens regularly and after personnel changes to reduce risk.

10. Operationalize with documentation and runbooks

• Rationale: Document intent definitions, variable schemas, failure modes (rate limits, API errors, model mismatches), and recovery steps. Train the NOC to interpret assurance signals and pipeline statuses, ensuring consistent, quick responses to incidents.

This approach creates a safe, testable path from intent to implementation, leverages controllers for policy distribution (with vManage/vSmart in SD‑WAN and DNA Center in the campus), uses idempotent tooling for convergence, and closes the loop with telemetry-backed validation and controlled remediation.

← Enterprise Security and Identity Services · All domains · Network Assurance →

Practice these questions → · Timed practice on ExamRoll.io →