A managed service provider's onboarding script logs in to Cisco Catalyst SD-WAN Manager with JWT, adds a new operator account, then pulls certificate view data for an audit. Every administration API sits under the /dataservice root, POST calls must carry the XSRF token, and new accounts are added at the user resource. Which request set completes the onboarding workflow on SD-WAN Manager?
Select an answer to reveal the explanation.
Short Explanation
You can complete the workflow by logging in at /jwt/login, POSTing the new account to /dataservice/admin/user with Bearer and XSRF headers, and then GETting /dataservice/certificate/view for the audit. Keep the user resource in mind: POST creates the account, while PUT updates an existing one.
Full Explanation
SD-WAN Manager, formerly vManage, uses the /dataservice prefix for the resources in this workflow: /dataservice/admin/user and /dataservice/certificate/view. Logging in at /jwt/login returns a token and a CSRF value; send the token in the Authorization header as a Bearer token and the CSRF value in the X-XSRF-TOKEN header for POST requests. Creating a new account uses POST on the user resource, so the request set that POSTs to /dataservice/admin/user with both headers and then GETs /dataservice/certificate/view meets the workflow requirements. A POST with only a Bearer header omits the required XSRF token. PUT with both headers uses the update method rather than the method for creating a new account. Paths that omit /dataservice, such as /admin/user and /certificate/view, do not use the required resource prefix. Exam caveat: session-based login with a cookie plus a separately fetched XSRF token is also available on this platform, though the workflow here specifies JWT login. Practical check: after the POST, GET /dataservice/admin/user and confirm the new userName is listed.