A museums and culture department wants to run a small Python helper on a Catalyst for local enrichment near the device, not only from a central jump host. Which on-box environment best provides that Linux userspace?
Select an answer to reveal the explanation.
Short Explanation
Guest Shell is a little Linux apartment upstairs on the Catalyst where Python helpers can live next to the exhibits. ROMMON is the basement breaker panel—not a place to run museum enrichment scripts.
Full Explanation
Museums wanting a small Python helper on a Catalyst for local enrichment need Guest Shell (IOx application hosting), which provides a Linux userspace on Catalyst/IOS XE platforms. That on-box environment is the EI feature intended for lightweight local scripts near the device rather than only on a central jump host. It complements—not replaces—controller automation.
The classic ROMMON bootstrap prompt is for recovery/boot, not application hosting. A disabled management VRF with no CPU or filesystem access cannot run helpers. Hardware TCAM programming from the ASIC CLI is not a Linux userspace for Python.
Exam caveat: Guest Shell resources and networking must be constrained; not every SKU or license enables IOx the same way. Operational check: enable Guest Shell on a lab Catalyst, run a trivial Python print via the shell, confirm management reachability model (VRF/routing), and measure CPU impact. Package the museums helper for intentional redeploy after reload rather than assuming persistence. Record the chosen control and the rejected alternatives in the municipal change record so future on-call staff understand which failure modes were avoided for city services. Re-validate after the next maintenance window that counters, logs, and failover behavior still match the documented design intent.