200-901 Application Deployment and Security Practice Question
A DevNet engineer is building a Python script that calls the Cisco Webex Teams API to post a message. The script currently stores the access token in a plain text variable at the top of the file, which is committed to a Git repository. The team wants to keep the token out of source control while still allowing the script to authenticate. Which approach should be used?
⚠ Common exam trap
The trap here is assuming that encoding or encrypting a secret inside the same committed file provides meaningful protection, when the real requirement is to keep the secret out of version control entirely.
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
✓
Move the token to a .env file and add that file to .gitignore, then load it with python-dotenv.
Keeping secrets out of source control requires storing them in an environment-specific location that is excluded from version control and loading them at runtime. A .env file ignored by Git, combined with python-dotenv, achieves this for local development while allowing the Webex Teams API call to authenticate normally. Encoding or hiding the token in the same file does not remove it from the repository.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Base64-encode the token and assign it to the variable so it is not readable as plain text.
Why it's wrong here
Base64 is an encoding, not encryption, and can be trivially reversed by anyone who sees the value. The encoded token would still be committed to Git and would still grant API access if decoded. This does not meet the requirement of keeping the credential out of source control.
- ✗
Encrypt the token with a symmetric key stored in the same Python file and decode it at runtime.
Why it's wrong here
Embedding both the encrypted token and the symmetric key in the same source file provides no real protection because anyone with repository access can decrypt the token. This is security through obfuscation and fails the requirement of keeping the secret out of source control. The key and ciphertext would still be committed together.
- ✗
Store the token in a comment above the function that uses it so only developers reading the code can see it.
Why it's wrong here
Placing the token in a comment still commits it to the repository and exposes it to anyone with read access, including future clones and forks. Comments are not a secure storage mechanism and do not satisfy the goal of removing the secret from source control. This approach also makes rotation and auditing more difficult.
- ✓
Move the token to a .env file and add that file to .gitignore, then load it with python-dotenv.
Why this is correct
Storing the token in a .env file that is excluded via .gitignore keeps it out of the repository while still making it available to the script at runtime through python-dotenv. This separates configuration from code and prevents accidental exposure in commits. It is a standard local development pattern that preserves authentication functionality without hardcoding secrets.
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.