A regional planning commission wants automation to manage IOS XE boxes with YANG models while operators keep CLI for break-glass work. What should the team enable alongside CLI?
Select an answer to reveal the explanation.
Short Explanation
Think bilingual ops: humans still speak CLI in an emergency, while automation speaks NETCONF/RESTCONF to YANG models. Turning those secure management planes on does not mean throwing away the keyboard—it means giving the robots a proper interface.
Full Explanation
Regional planning automation that drives IOS XE with YANG models needs secure model-driven management planes while humans retain CLI for break-glass work. Enabling NETCONF and/or RESTCONF alongside SSH CLI lets controllers push structured configuration without discarding emergency keyboard access. That dual-path design is standard NetDevOps practice for municipal fleets.
Relying only on Telnet scripting with expect ignores that IOS XE exposes model-driven APIs and reintroduces cleartext management. Disabling SSH entirely so NETCONF owns the management plane removes the break-glass path operators explicitly need. Using SNMPv1 write communities as the primary structured API is cryptographically weak and is not a YANG-model configuration interface comparable to NETCONF/RESTCONF.
Exam caveat: NETCONF typically speaks XML over SSH while RESTCONF uses HTTPS with JSON or XML; both consume YANG, but transport and encoding differ—do not treat them as identical on the exam. Operational check: enable NETCONF/RESTCONF with AAA and secure transport, confirm a controller can read and edit a non-production leaf, and verify CLI SSH still works when the automation bus is unavailable. In municipal NetDevOps programs, document which leaves controllers may change and which remain CLI-only so change control stays clear during planning commission audits.