During tonight's window you must push a device template built from feature templates to 20 branch routers from Python and prove each push finished before the window closes. Your script already holds the template ID, the device UUIDs and the filled variable values, and SD-WAN Manager runs the push as a background job. Which API sequence starts the attach and then tracks it to completion?
Select an answer to reveal the explanation.
Short Explanation
Exactly — the attach call starts the job and the action status call is where you watch it finish. One POST queues the template push and hands back a process ID, and the follow-up GET reports each router's outcome. It's like a shipping receipt: acceptance books the job, the tracking page proves delivery.
Full Explanation
Attaching a device template is asynchronous: the attachfeature request takes your list of filled device values, starts a background push and answers with a process ID. The action status endpoint is the documented companion for that ID, and polling it shows each device's result until the job settles, which is the only proof that every router finished inside the window. Treating the HTTP 200 as completion is the classic trap, because that status only means the manager accepted your request and a router can still reject a value minutes later. Generating device input variables with the config input call is a real earlier step in the workflow, but it merely returns the fields you still have to fill in and never touches a router, so it cannot show a push outcome. Reading the attached-device list back confirms which devices the template is associated with, not whether tonight's push succeeded on any of them. Exam caveat: this platform was called vManage for years, so older study material still uses the old name for these same endpoints. Practical check: capture the process ID from the attach response and watch its status reach success before you close the window.