Understanding and Using APIs →mediumMultiple Select

200-901 Understanding and Using APIs Practice Question

A developer is designing a Python application that consumes several Cisco REST APIs. To make the code maintainable and secure, the developer wants to implement reusable API request handling. Which two practices should be applied? (Choose two.)

⚠ Common exam trap

The trap here is treating convenience measures such as hard-coded keys or disabled TLS verification as acceptable shortcuts, when they directly violate the security and maintainability goals of the scenario.

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

✓

Store API credentials in environment variables or a secrets manager rather than hard-coding them in source files.

Secure and maintainable API clients externalize secrets and centralize shared request logic. Storing credentials in environment variables or a secrets manager prevents accidental exposure, while a reusable client module ensures consistent authentication, headers, and error handling. Hard-coding keys, disabling TLS verification, or duplicating logic all undermine security or maintainability and should be avoided.

Answer analysis

Option-by-option breakdown

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

✓
Store API credentials in environment variables or a secrets manager rather than hard-coding them in source files.
Why this is correct
Embedding secrets in source code risks exposure through version control, logs, or shared repositories. Using environment variables or a dedicated secrets manager separates configuration from code, supports rotation, and limits blast radius if a repository leaks. This is a foundational secure-coding practice for any API-consuming application, including Cisco DevNet workflows.
✗
Disable TLS certificate verification to avoid errors when calling multiple APIs.
Why it's wrong here
Disabling certificate verification removes protection against man-in-the-middle attacks and is never appropriate for production API calls. It might silence errors caused by misconfigured trust stores, but it trades security for convenience. The correct fix is to properly configure CA bundles, not to weaken TLS validation.
✗
Write a separate copy of the authentication and request logic for each API endpoint to keep functions independent.
Why it's wrong here
Duplicating authentication and request logic across endpoints increases code volume and the risk of inconsistent behavior. When a token refresh or header change is needed, every copy must be updated. Centralizing shared logic is the maintainable approach, so this option works against the stated goal.
✗
Hard-code the API key in each script so every team member can run it without configuration.
Why it's wrong here
Hard-coding credentials is a serious security anti-pattern. It exposes secrets to anyone with repository access and makes rotation difficult. Even for internal tooling, credentials should be externalized. This practice directly contradicts the secure, maintainable design the developer is trying to achieve.
✓
Centralize HTTP session creation and common headers in a reusable client module.
Why this is correct
A shared client module avoids duplicating authentication, base URLs, timeouts, and error handling across endpoints. It also simplifies applying consistent retry and logging behavior. This reduces maintenance burden and the chance of inconsistent behavior when APIs change, which is exactly the maintainability goal described in the scenario.

Go deeper

200-901 Understanding and Using APIs Practice Question

Why each option matters

Option-by-option breakdown

Related to this question