An engineer attaches one device template to forty branch routers through the SD-WAN Manager Configuration API and receives an identifier for the push job rather than any configuration result. The audit log must reflect what each router actually accepted, beyond the request being accepted. How should the script use that identifier to report the outcome of the device template push?
Select an answer to reveal the explanation.
Short Explanation
That identifier is a work order rather than a receipt, so it only tells you the push started. You poll the action status until it settles and read each router's own message — it's like tracking a shipment to see which boxes actually arrived.
Full Explanation
Attaching a device template starts a multi-device configuration job: SD-WAN Manager validates the variable bindings, builds a device-specific configuration for every router in the request and pushes it out, which takes far longer than the HTTP call itself, so the response returns only a process identifier for the whole batch. The device action status endpoint is where the real outcome lives, because it reports progress for that process along with activity and status entries that name each router and show whether it took the configuration. Reading the device list immediately confuses inventory state with deployment state, since that list never describes this push and cannot show which routers accepted it. Stopping at the preview request proves the rendered configuration is well formed rather than delivered, so a clean preview says nothing about forty live devices. Querying the attached-devices endpoint answers a different question, because it lists template membership rather than the result of this particular job. Caveat: the job can look finished while an individual router still shows an error, so read the per-device entries instead of the overall flag. Practical check: attach the template to one lab router, poll the status identifier until it settles, and compare that result with the running configuration.