A parks department API Gateway has stages for test and prod. Developers want each stage to invoke a different Lambda alias without cloning the entire API definition. Which feature provides that dynamic stage-to-backend binding?
Select an answer to reveal the explanation.
Short Explanation
Staging variables are the sticky notes on each stage door: test points at alias test, prod at alias prod—same API blueprint. Cloning the whole API or hard-coding prod ARNs everywhere is how parks APIs turn into a paperwork swamp.
Full Explanation
API Gateway stages for a parks department API should reuse one API definition while binding each stage to a different backend—commonly different Lambda aliases for test versus prod. Stage variables provide that dynamic binding: each stage supplies values (alias name, integration URI fragments, or related config) resolved at runtime so developers do not clone the entire API per environment. The blueprint stays one; the sticky notes on each stage door differ.
Hard-coding the production alias ARN in every method ignores stages and forces risky edits when promoting. Creating a separate AWS account per HTTP method is operationally absurd and unrelated to stage-to-alias mapping. Replacing API Gateway with unsigned public Lambda function URLs abandons stage management, auth integration patterns, and civic API governance.
Exam caveat: stage variables are configuration indirection for stages; they are not a substitute for IAM auth, nor do they by themselves implement canary traffic unless combined with alias weights.
Operational check: deploy the same API to test and prod stages, set stage variables to the intended Lambda aliases, invoke each stage URL, and confirm CloudWatch/X-Ray show traffic hitting the expected alias without duplicating the API definition for parks.