Developers need unfinished API routes isolated from citizens while QA still exercises a stable candidate. How should API Gateway stages be used?
Select an answer to reveal the explanation.
Short Explanation
Stages are lanes on the same bridge—dev traffic here, QA there, citizens elsewhere. Keep unfinished routes on /dev and let QA use /test so production stays calm. Hourly stage-variable roulette is not isolation.
Full Explanation
API Gateway stages separate unfinished work from citizen-facing traffic. Developers should use separate stages such as /dev for active development and /test for QA so unfinished routes stay off the production stage residents call. Stage separation is a core environment-management pattern for municipal APIs when multiple teams need isolation without multiplying entire AWS accounts for every experiment, while still preserving a stable candidate for QA.
Publishing every experimental method on the production stage with only a beta path prefix fails because production still hosts unfinished surface area and residual risk for curious clients. Sharing one stage and rotating stage variables hourly between teams fails conceptually as a collision-prone, non-auditable multiplexing scheme. Disabling stages and exposing Lambda function URLs publicly for all environments fails by abandoning stage-based governance and often widening exposure.
Exam caveat: stage names alone do not isolate data—each stage must point at non-overlapping backends, IAM roles, and parameters or isolation is theater. Operational check: deploy an unfinished route only to the developer stage, confirm the citizen-facing stage lacks it, and verify QA exercises the test stage with stable published candidates.