A city wants edge scripts and on-device automation to run local to each Catalyst 9000 rather than only in a central VM. What does DEVCOR 5.5 emphasize?
Select an answer to reveal the explanation.
Short Explanation
Hosting on the device means the tool lives at the curb with that switch—IOx on Catalyst 9000—not only in a downtown VM that merely talks to it.
Full Explanation
DEVCOR 5.5 emphasizes on-box hosting via IOx on platforms such as Catalyst 9000 so the application is local to that network device. A city that wants edge scripts and on-device automation running beside each Catalyst—not only in a central VM—is describing that objective: place the app on the switch through IOx and CAF rather than redefining “host on a network device” as somewhere else entirely in the data center.
Pushing the same app only to a data-center VM as the definition of “host on a network device” fails the on-box intent of the objective. Answering with cloud high-availability placement patterns from Domain 1 as the 5.5 hosting answer confuses domains and blueprints. Disabling IOx and relying on off-box CI runners exclusively for supposed on-device apps abandons the hosting framework the section teaches municipal engineers to use.
Exam caveat: central controllers and VMs remain valid for many city applications; 5.5 specifically tests when the requirement is local to the network device. Combine this idea with Guest Shell, AppGigabitEthernet mapping, and storage prerequisites from sibling items.
Operational check: deploy a minimal IOx app or Guest Shell script on a Catalyst 9000 at the edge, confirm it runs without the central VM being reachable, and document when on-box versus off-box placement is preferred in architecture notes.