A network engineer must run 'show cdp neighbors' on forty access switches through Catalyst Center and save the output for a report. The POST to the Command Runner endpoint returns quickly with a task ID while devices are still replying. Which workflow collects the finished command output for that task?
Select an answer to reveal the explanation.
Short Explanation
Command Runner is asynchronous, so your POST queues the work and gives you a task ID while the switches are still replying. Poll the task until it finishes, then download its result file to collect each switch’s output for your report.
Full Explanation
The Command Runner POST starts an asynchronous job, so its quick response supplies a task ID rather than finished CLI output. Poll the Task API with that ID to determine when processing is complete, then download the task’s result file to obtain the per-device command output for the report. Polling to completion and reading CLI output directly from the task-detail JSON gets the waiting step right, but task details track the task and provide the result-file reference; they are not a substitute for downloading the file. Polling status and then collecting replies from the original Command Runner response body fails because that response arrives while the switches are still responding. Running the same show command over SSH in parallel can collect CLI output, but it bypasses Catalyst Center, the required command-execution path in this scenario. Exam caveat: task completion and result availability are distinct from receiving the initial task ID, so a successful POST does not mean the output is ready. Practical check: confirm the task reaches a completed state, then verify the downloaded result file contains output entries for all forty switches before preparing the report.