hardMultiple ChoiceObjective-mapped
200-901 Practice Question: Is designing a REST API using Python Flask to…
A network engineer is designing a REST API using Python Flask to allow provisioning of VPN tunnels. The API must support multiple clients and must be secure. Which approach is most appropriate for authenticating and authorizing API requests?
⚠ Common exam trap
Cisco often tests the misconception that 'API tokens' are the same as 'shared secrets' or that OAuth 2.0 is always the most secure choice, but the trap here is that for a simple, multi-client provisioning API, issuing and validating API tokens provides the right balance of security, statelessness, and manageability without the overhead of a full OAuth 2.0 framework.
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
✓
Issue API tokens to each client and validate them on each request
Issuing API tokens (e.g., using Flask's built-in session management or a library like Flask-JWT-Extended) allows the server to validate each request statelessly without storing client credentials on every call. This approach scales well for multiple clients, supports token revocation, and avoids exposing long-lived secrets in transit or at rest, aligning with RESTful statelessness and security best practices.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Use OAuth 2.0 with client credentials grant
Why it's wrong here
OAuth 2.0 with the client credentials grant authenticates the client application itself, not an end user, and therefore cannot authorise individual human operators or distinguish between multiple clients sharing the same credentials. The scenario requires per-client authentication and authorisation for provisioning VPN tunnels, which demands a grant type that conveys user identity, such as the authorisation code grant. This option is tempting because client credentials are simple to implement for server-to-server communication where no user context is needed, such as a backend service calling another API without human interaction.
- ✗
Use HTTP Basic Authentication with a dictionary of usernames and passwords
Why it's wrong here
Basic auth sends credentials in plaintext (unless over HTTPS) and is not recommended for APIs.
- ✗
Embed a shared secret in each client's source code
Why it's wrong here
Embedded secrets are insecure and hard to rotate.
- ✓
Issue API tokens to each client and validate them on each request
Why this is correct
API tokens are a standard, secure method for API authentication and can include scopes.
Go deeper
Related to this question
About these practice questions
This 200-901 question is part of Courseiva's 989-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 by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
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.