A campus refresh brings twelve new access switches, and the automation lead has asked the team to avoid manual CLI work. Your script must start a discovery job, wait for it to finish, and then read back the inventory so the imported data can be validated. Which sequence of Catalyst Center API calls should the script make on its first run?
Select an answer to reveal the explanation.
Short Explanation
Discovery is asynchronous, so the API hands you a task to watch instead of a finished inventory. Wait for that task to report completion, then pull the device list and compare it with the twelve expected switches to validate the import. Ordering a bulk delivery and checking the box against the packing slip is the same rhythm, and the task endpoint is the tracking number you'll follow.
Full Explanation
The Catalyst Center discovery API is asynchronous, so the request that starts a scan returns a task identifier and task URL rather than a list of devices. Your script polls the task resource until it reports completion, then reads the inventory to validate the results. A GET against the network-device resource returns device records, including fields such as reachability status, software version, and collection status. Compare the returned records with the twelve expected switches to confirm they are present and check their reported status. Creating individual device records through the network-device API skips discovery entirely, contradicting the requirement to scan and also missing anything you never told the controller about. Reading inventory immediately after launch can race the job, so the list may reflect only devices processed so far. Stopping as soon as the task completes trusts the task verdict instead of validating the inventory data the runbook asks you to confirm. Exam caveat: response envelopes and polling details move between releases, so hold on to the three-step shape. Practical check: run a small discovery against a lab subnet and watch the task change state before issuing the inventory read.