SD-WAN Manager's administration API uses an authenticated session. A short-schedule script must make several administration calls without logging in for every one. Which authentication pattern should the script use across those calls?
Select an answer to reveal the explanation.
Short Explanation
Log in once, then reuse your session cookie—and include a CSRF token when an endpoint requires one—for each call, like using one pass for several stops. Log out when you’re finished.
Full Explanation
The correct approach matches the API’s stated authentication model: log in once, retain the authenticated session cookie, and include any CSRF token required for subsequent state-changing requests. This avoids repeated logins while preserving the session’s security checks; logging out when the script finishes also closes the session cleanly. An OAuth bearer token is a common pattern for APIs that support OAuth, but it is not a substitute for the authenticated session specified here. Attaching a bearer token to each request therefore uses the wrong credential mechanism for this API. Likewise, API keys are widely used for service-to-service access, but provisioning and sending a key does not establish or reuse the required authenticated session. The cookie-only approach correctly reuses a session, but it fails to supply the CSRF token that this scenario says is required, so protected requests may be rejected or lack the expected cross-site request protection. Exam caveat: some products expose separate APIs or configuration modes with OAuth or API-key authentication, so do not generalize this answer beyond the stated interface. Practical check: inspect the API’s login response and endpoint documentation for the session cookie’s handling, CSRF header or token requirements, and logout procedure, then test the script against a non-production account.