County IT runs Python inside Guest Shell and must gather show-command output safely for a compliance script. Which approach best fits controlled on-box command execution?
Select an answer to reveal the explanation.
Short Explanation
The CLI Python module is the polite intercom from Guest Shell to the IOS XE brain: ask for a show, get the answer, leave the secrets alone. It beats rogue expect bots shouting passwords down every VTY.
Full Explanation
County IT running Python inside Guest Shell to gather show-command output for compliance should use the platform CLI Python module (for example cli.execute / clip) to run approved show commands and capture structured or text results. That controlled on-box execution path is designed for scripts that need CLI data without inventing unsafe remote expect loops from the shell.
Spawning unconstrained expect scripts that type enable secrets into every VTY from Guest Shell is a credential and audit hazard. Overwriting running-config from /dev/urandom is destructive nonsense. Disabling AAA so Guest Shell can configure without accounting violates civic compliance goals.
Exam caveat: still apply AAA accounting and least-privilege—Guest Shell command execution is not a free pass around change control. Operational check: run a compliance show via the CLI module, capture output to a secured file path, transfer via approved methods, and verify commands appear in AAA logs. Keep enable secrets out of Guest Shell scripts entirely. 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.