200-901 Application Deployment and Security Practice Question
A developer is writing a Python application that calls a REST API. The API requires an OAuth 2.0 bearer token. The token must not be stored in the source code. Which approach should the developer use to make the token available to the application at runtime?
⚠ Common exam trap
The trap here is thinking that hiding a secret in bytecode or a comment makes it safe, when any location inside the source or artifact is still exposed.
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
✓
Read the token from an environment variable that is injected by the deployment platform at runtime.
The token must be provided at runtime and kept out of source control. Environment variables are a standard way to inject secrets into a running application without embedding them in code or configuration files committed to the repository. The other options either commit the secret to the repository or ship it inside the application artifact, both of which expose the token.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Read the token from an environment variable that is injected by the deployment platform at runtime.
Why this is correct
This is correct because environment variables are injected at runtime and are not part of the source code or repository. The application can read the token from os.environ without embedding it in code, and the platform can rotate the value without a code change. This satisfies the requirement to keep the token out of source control.
- ✗
Hardcode the token in a configuration file that is committed to the repository so the application can read it on startup.
Why it's wrong here
This is wrong because committing the token to the repository exposes it to anyone with repository access and to history even if later removed. The scenario explicitly requires that the token not be stored in source code, and a committed configuration file violates that requirement. Hardcoded secrets are also difficult to rotate.
- ✗
Store the token in a comment at the top of the main application file so it is easy for the developer to find.
Why it's wrong here
This fails because a comment in the source file is still part of the source code and is committed to the repository. Anyone who can read the code can read the token, and the token would appear in code reviews and history. This directly violates the requirement to avoid storing the token in source code.
- ✗
Embed the token in the application's compiled bytecode so it is not visible in the plain source files.
Why it's wrong here
This is incorrect because embedding the token in bytecode still ships the secret with the application artifact, and bytecode can be decompiled or inspected. It also makes rotation difficult because a new build is required. The token remains part of the application package rather than being injected at runtime.
Go deeper
Related to this question
About these practice questions
Courseiva writes every 200-901 question from scratch — 975 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or 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.