mediumMultiple Choice
200-901 Practice Question: A developer is designing an API that needs to…
A developer is designing an API that needs to support rate limiting per API key. The application is deployed on multiple instances. Which approach ensures consistent rate limiting across all instances?
⚠ Common exam trap
Cisco often tests the misconception that local counters or environment variables can be used for distributed state, when in fact they lack the shared, atomic, and persistent storage required for multi-instance rate limiting.
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
✓
Use a distributed cache like Redis
A distributed cache like Redis provides a shared, atomic counter that all application instances can read and increment, ensuring consistent rate limiting across a multi-instance deployment. Redis supports atomic operations like INCR and EXPIRE, which are essential for implementing sliding window or token bucket algorithms without race conditions.
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 a local in-memory counter
Why it's wrong here
A local in-memory counter is scoped to one process, so each instance tracks its own tally and limits diverge as requests distribute across the fleet. It is tempting because it is the fastest counter available and works perfectly for single-instance deployments or per-process throttling, where no shared state is required.
- ✗
Use a file-based lock
Why it's wrong here
A file-based lock only coordinates processes sharing the same filesystem, so separate instances on different hosts cannot see each other's locks and counters drift. It is tempting because file locking genuinely serialises access for co-located processes, making it correct for single-host concurrency control rather than distributed rate limiting.
- ✗
Use environment variables
Why it's wrong here
Environment variables are read-only configuration injected at process start, so they cannot hold a mutable per-key request tally shared between instances. They are tempting because they do configure per-instance rate-limit thresholds and API key values, which is their actual purpose, but they store no runtime counter state.
- ✓
Use a distributed cache like Redis
Why this is correct
Redis provides a shared, centralised counter store that every application instance reads and writes atomically, so per-API-key request counts remain consistent regardless of which instance handles a request. This satisfies the stem's multi-instance constraint, unlike in-memory limiting, which fragments state across instances and permits exceeding the intended quota.
Go deeper
Related to this question
About these practice questions
One of 975 original 200-901 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.