Insurer Automation: Source of Truth, Compliance, and Telemetry
An insurer has 600 routers and switches across 40 offices, managed by three engineers using CLI templates and spreadsheets. Last quarter, 12% of devices failed a CIS benchmark, and three outages were caused by manual VLAN changes. Mean time to repair is 9 hours because engineers lack current topology and interface data. The company has Cisco DNA Center and Ansible, but no source of truth. It wants zero-touch provisioning for new branches, automated compliance, and streaming telemetry for 200 critical devices. Change approval requires a rollback plan and a pre/post diff. The security team insists on TACACS+ and signed configurations. The target is 80% of routine changes automated within a year.
1. Design the automation architecture: what are the roles of DNA Center, Ansible, Git, and the source of truth? Include the flow for a new branch.
Read the worked answer
Use Git as the source of truth for intent and variables, not as a device backup. Ansible renders configurations from Jinja2 templates and orchestrates workflows; DNA Center provides discovery, image management, templates, compliance, and assurance for Cisco devices. The flow for a new branch: branch record in Git (site ID, subnets, WAN IPs, VLANs) -> CI pipeline validates schema and policy -> Ansible generates intended config and opens a change request -> after approval, Ansible pushes via NETCONF/RESTCONF or a DNA Center template -> DNA Center discovers the device and runs compliance -> telemetry confirms. Do not let Ansible and DNA Center both own the same variables; Git wins, DNA Center is an executor and observer. Use TACACS+ for AAA and signed commits or tags for audit. This separation prevents a controller from becoming an unaudited source of truth.
2. Select protocols and data models for configuration and telemetry. Why NETCONF/YANG versus RESTCONF versus SNMP, and gNMI versus SNMP polling?
Read the worked answer
Use NETCONF with YANG for transactional configuration because it supports candidate datastores, validate, commit, and rollback, which maps to the rollback requirement. RESTCONF is acceptable for HTTP-friendly tools and read operations, but it lacks the same candidate and commit semantics in all implementations. SNMP is for polling and traps, not for scalable configuration; keep it for legacy MIBs only. For telemetry, use gNMI or model-driven telemetry over gRPC rather than SNMP polling. Streaming telemetry pushes only changed data at sub-minute intervals and scales to 200 critical devices. Use OpenConfig models where available and native Cisco YANG where needed. Sign configuration artifacts in Git and verify image signatures; TACACS+ provides command authorization. NETCONF over SSH with AAA is the baseline.
3. Define the compliance and rollback workflow, including pre/post diff and handling of a failed deployment.
Read the worked answer
Compliance workflow: nightly, pull running config and compare to intended config from Git; DNA Center compliance checks CIS benchmarks and Ansible checks custom intent. Classify drift as critical (AAA, ACL, routing) or low (banner). For changes, generate a pre-change config, run a dry-run diff, require peer review, schedule a window, and use commit-confirmed with a rollback timer. Capture pre/post diffs and store them with the change ticket. If deployment fails, Ansible runs a rollback playbook or NETCONF discards the candidate; DNA Center can re-provision from the template. Do not auto-remediate critical drift without approval; open a ticket. For the 80% target, automate VLAN, interface, and SNMP changes first, then routing. Measure success by change success rate, MTTR, and drift percentage, not by playbook count.