200-901 Application Deployment and Security Practice Question
An application running on a Cisco IOS XE device must call an external REST API that uses a self-signed certificate. The developer's Python script using the requests library fails with an SSL verification error. The security team requires that the script still validates the server identity. Which approach satisfies the requirement?
⚠ Common exam trap
The trap here is treating the SSL error as something to suppress with verify=False rather than as a signal to supply the correct trust anchor.
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
✓
Provide the path to the server's CA certificate through the verify parameter
A self-signed certificate is not chained to a public root authority, so the default trust store cannot validate it. Supplying that certificate, or the CA that issued it, to the verify parameter gives the client an explicit trust anchor while keeping hostname and chain validation active. Disabling verification or stripping the trust store would silence the error at the cost of the identity assurance the security team requires.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Downgrade the request to plain HTTP on port 80 so TLS is not involved
Why it's wrong here
Switching to unencrypted HTTP eliminates transport security entirely, exposing credentials and payloads to interception. It also assumes the API listens on port 80, which a TLS-only service typically does not. This avoids the certificate error by removing encryption, which is the opposite of what a security-conscious integration should do.
- ✓
Provide the path to the server's CA certificate through the verify parameter
Why this is correct
Pointing verify at a PEM file containing the certificate or its issuing CA lets the requests library build a trust chain for that specific server. Validation remains fully enforced, so a mismatched hostname or an untrusted certificate still fails. This is the standard way to trust a self-signed certificate without weakening TLS verification for the connection.
- ✗
Pass verify=False to the requests call to skip certificate validation
Why it's wrong here
Disabling verification removes the protection the security team wants to retain. With verify=False, the client accepts any certificate, including one presented by an attacker performing a man-in-the-middle interception. This also generates noisy InsecureRequestWarning messages. It resolves the immediate error but directly violates the stated requirement that server identity continue to be validated.
- ✗
Set the REQUESTS_CA_BUNDLE environment variable to an empty string before running the script
Why it's wrong here
An empty CA bundle leaves the client with no trusted roots, so verification cannot succeed and the connection still fails. Clearing the bundle does not disable validation; it just removes the material needed to perform it. The correct direction is to add the specific certificate to a trust file, not to empty the trust store.
Go deeper
Related to this question
About these practice questions
This 200-901 question is part of Courseiva's 975-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Cisco exam blueprint
This 200-901 practice question is part of Courseiva's free Cisco certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the 200-901 exam.