Infrastructure and Automation →mediumMultiple Select

200-901 Infrastructure and Automation Practice Question

A developer is building a Python script that consumes a REST API exposed by a Cisco controller. The script must authenticate using a token obtained from a login endpoint and then call protected resources. Which TWO practices are appropriate for handling authentication and session state in this script? (Choose two.)

⚠ Common exam trap

The trap here is treating the token as a one-time artifact or bypassing TLS, when the real requirements are header-based reuse and expiry refresh.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Handle token expiry by detecting an authentication failure response and re-authenticating to obtain a fresh token before retrying the request.

Token-based controller APIs require the client to obtain a token at login, present it on subsequent protected calls, and refresh it when it expires. Storing and attaching the token in a request header satisfies the session requirement, and detecting an authentication failure to re-login keeps unattended scripts working. Replaying credentials, hard-coding tokens, and disabling TLS verification are insecure or nonfunctional alternatives.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Disable TLS certificate verification so the login request succeeds against the controller's self-signed certificate.
Why it's wrong here
Turning off certificate verification exposes the login credentials and token to interception and undermines the trust the API depends on. The correct fix is to trust the controller's certificate authority or pin its certificate, not to weaken transport security just to make the handshake succeed.
✗
Send the username and password with every API request instead of obtaining a token.
Why it's wrong here
Replaying credentials on each call increases exposure and is not how token-based controllers authenticate after login. Some endpoints reject basic credentials outright, and the practice defeats the purpose of the token endpoint, so it is both insecure and functionally unreliable for protected resources.
✓
Handle token expiry by detecting an authentication failure response and re-authenticating to obtain a fresh token before retrying the request.
Why this is correct
Tokens expire after a defined lifetime, and protected calls then return an authentication error. Detecting that response and logging in again to refresh the token keeps the script running unattended, which is essential for long-lived automation that cannot rely on a single token lasting forever.
✗
Hard-code the token value in the script so it never needs to be fetched at runtime.
Why it's wrong here
Hard-coded tokens expire and then break every run, and embedding credentials in source exposes them to anyone with repository access. It also prevents rotation, so a leaked token cannot be invalidated without editing and redeploying the script, making this an insecure and brittle approach.
✓
Store the token returned by the login endpoint and include it in an Authorization or X-Auth-Token header on subsequent requests.
Why this is correct
Token-based APIs expect the credential returned at login to be presented on each protected call. Holding the token in a variable and attaching it to the request header lets the script access resources without resending the username and password, which is the standard session pattern for controller REST APIs.

Go deeper

200-901 Infrastructure and Automation Practice Question

Why each option matters

Option-by-option breakdown

Related to this question