ENSDWI Part 12: Management, Operations, and Exam Day

22 July 2026 CiscoENSDWISDWAN

The final domain is the smallest (10%) and the friendliest: Management and Operations, blueprint 6.1–6.4. Then we close the series the way the NSE4 series closed — with a revision plan.

6.1 / 6.2 Authentication, monitoring, and reporting

The blueprint lists these twice deliberately — 6.1 “describe” and 6.2 “configure”. Study them once, at configure depth:

AAA on vManage

  • Local users with role-based access: built-in groups basic / operator (read-only) / netadmin (full), plus custom groups with per-feature read/write permissions. netadmin is the only default group that can do everything, including SSH to devices via vManage.
  • Remote AAA: RADIUS and TACACS+, plus Single Sign-On via SAML 2.0 (IdP metadata upload — Okta/Azure AD/ADFS). Order of authentication attempts is configurable (local fallback matters — don’t lock yourself out).
  • Device-side AAA is separate (template/config-group AAA feature: local users, RADIUS/TACACS for device CLI login) — a question about “SSH login to the edge” is device AAA, not vManage AAA. The same discipline as RADIUS admin auth on the Fortinet estate: management-plane and device-plane auth are different surfaces.

Monitoring and alarms

  • Monitor → Overview/Devices: fabric health, per-device state, tunnel status, app-route charts (the loss/latency/jitter graphs Part 9’s AAR verdicts come from).
  • Alarms: severity Critical / Major / Medium / Minor; alarm correlation (one root cause suppresses child alarms); acknowledge/notes workflow; alarm notifications via email or webhooks (HTTP POST of alarm JSON to your endpoint — the integration answer for “notify our ITSM”).
  • Audit log: who changed what, where — Monitor → Audit Log; ships to syslog if configured.
  • Events vs alarms: events are the raw stream; alarms are stateful conditions raised from them.
  • Statistics collection: vManage polls devices (default index/collection interval 30 min for stats DB; real-time screens query devices live — “real-time” queries hit the device with a NETCONF/CLI fetch, which is why they’re rate-limited). DPI/cflowd statistics land in vManage when enabled by policy.
  • Packet capture / speed test / device bringup checks under Monitor → Devices → Troubleshooting — know they exist and run from vManage against live edges.

6.3 REST API monitoring

Describe-level, and the easiest marks on the paper if you’ve ever touched the API (the MCP server that publishes this site is the same shape of thing — authenticated JSON over HTTPS):

  • Base: https://<vmanage>/dataservice/...
  • Auth flow: POST /j_security_check with credentials → session cookie (JSESSIONID); then GET /dataservice/client/token for the XSRF token required on any POST/PUT/DELETE (post-19.2 fact the exam likes).
  • Monitoring endpoints to recognise:
GET /dataservice/device                          ! inventory + reachability
GET /dataservice/device/counters?deviceId=...    ! per-device health counters
GET /dataservice/device/monitor                  ! device status summary
GET /dataservice/statistics/interface            ! stats DB queries
GET /dataservice/alarms                          ! alarm feed (what the webhook pushes)
  • Responses are JSON ({"data": [...]}); the API covers config and operations too, but blueprint 6.3 is monitoring-scoped. If asked “programmatically retrieve tunnel statistics without SSH” — REST API, session cookie + XSRF, /dataservice/....

6.4 Software image management

vManage as the image librarian for the whole fabric:

  • Repository: Maintenance → Software Repository — upload images (or point at a remote server); controller images, cEdge IOS-XE images, vEdge images all live here.
  • Upgrade workflow is two-step and this is the tested fact: Upgrade (copy image to device, install into the standby slot) then Activate (reboot into it). Activate can be immediate or scheduled; devices keep the previous image for rollback.
  • Set Default Version marks the image a device falls back to on repeated boot failure.
  • Built-in protection: a cEdge that loses control connectivity after an upgrade auto-rolls-back to the previous image after a timer (rollback timer, default 5 minutes of no control-plane) — the safety answer for “what if the new image bricks connectivity to a remote site?”.
  • Order of operations for fabric upgrades: controllers before edges (vManage first, then vBond/vSmart, then edges), version-skew rules allow controllers ahead of edges but not meaningfully behind.
  • ZTP/PnP interaction: onboarding devices can be auto-upgraded to the enforced version on join.

The whole blueprint on one screen

DomainWeightThe three facts I’d check last
1.0 Architecture20%OMP’s 3 route types; TLOC = system-IP+color+encap; vBond needs 1:1 NAT
2.0 Controllers15%org-name exact match; DCONFAIL vs CRTVERFL vs SERNTPRES; staging = control-only
3.0 Routers20%PnP vs ZTP; TLOC extension; OMP advertises connected/static only by default
4.0 Policies20%control@vSmart/reject vs data@edge/drop; hub-spoke = TLOC filter + route rewrite; AAR never blackholes
5.0 Security & QoS15%DNS vs SIG vs embedded; queue 0 = LLQ; FEC vs duplication
6.0 Mgmt & Ops10%upgrade-then-activate + rollback timer; JSESSIONID + XSRF; alarm webhooks

Exam-day notes

Practical points, same advice that closed the NSE series but tuned for Pearson VUE:

  • 90 minutes, ~55–65 questions, no backtracking. Budget ~75 seconds per question; exhibits burn more, drag-and-drops less. Answer and move — you cannot return.
  • Read the verb in scenario questions. “Describe” domains produce “which statement is true” questions; “configure” domains produce “what does this config do” and “what’s missing”. If a policy exhibit appears, check default-action and the apply direction first — that’s the answer more often than the sequences are.
  • Exhibit outputs: you’ll see show sdwan control connections, connection-history error codes, omp routes flags (C/I/R), bfd sessions, and policy-map interface. Every one of those has appeared in this series with the reading key.
  • The passing score is not published and varies (Cisco scales 300–1000, pass typically ~800-ish); unanswered = wrong, so never leave blanks — eliminate one option and guess.
  • Booking: Pearson VUE, online-proctored is fine but the check-in eats 30 minutes — arrive early either way.

Revision plan for the final week

Day 1–2: re-read Parts 2–3 and 6–7 (the two 20% “hard” domains: Architecture, Router Deployment). Lab: bring up two edges against the DevNet sandbox or CML topology from Part 1, break org-name on purpose, read the error codes. Day 3: Parts 8–9, and write one hub-and-spoke control policy + one AAR policy from a blank page. Day 4: Parts 4–5 and 10–11 — these are recognition domains; flashcard the tables. Day 5: Part 12’s endpoints and the upgrade workflow, then every “Exam traps” section in the series back-to-back — they’re the distilled question bank. Rest before the exam; a fresh read of an exhibit beats a tired memory of a fact.

That’s the series. Twelve parts, six domains, one blueprint — and if you’ve labbed alongside, you’ve now built, broken, and fixed every layer the exam asks about. Good luck, and when you pass: the Catalyst SD-WAN deep dive is waiting for the why behind everything you just memorised.