A Python job pulls configuration and health data from an SD-WAN Manager appliance using the automation service account instead of an engineer's interactive session. The job makes hundreds of calls, must open a single session and reuse it, and must recover on its own if the manager later rejects that session. Which authentication flow should the script use for the whole run?
Select an answer to reveal the explanation.
Short Explanation
The login call is the only place your credentials belong, and it hands back a session cookie that every later call must carry. It works like a building badge: one swipe gets you in, and the doors read it for the rest of the visit. Logging in again when the manager rejects the session keeps a long job running instead of dying halfway.
Full Explanation
The correct flow uses the service account to establish the manager’s client-login session, carries the returned session cookie on each API request, and creates a replacement session when the manager rejects the existing one. Reusing one session avoids unnecessary logins across hundreds of calls, while relogin lets the job recover without an engineer’s intervention. Starting a new session for each batch is a reasonable way to limit session lifetime, but it violates the requirement for one session throughout the entire run, even if each batch reuses its cookie and rejected sessions trigger relogin. Using an engineer’s credentials can work technically with the same cookie and recovery pattern, but it violates the explicit identity requirement: automation must authenticate as the service account rather than depend on an interactive user’s account. Stopping when a session is rejected is a defensible fail-closed policy in some systems, but it does not meet the requirement that the job recover on its own; it leaves recovery to an operator. Exam caveat: SD-WAN Manager authentication details can vary by release, so confirm the documented login endpoint, cookie name, and any CSRF-token requirements rather than assuming every API uses the same session mechanics. Practical check: in a test environment, verify that all calls carry the same session cookie and that an intentionally invalidated session leads to a fresh service-account login and successful continuation.