A municipal API Gateway API has distinct stages for development, test, and production. Each stage must invoke a different Lambda alias. How should that wiring be managed?
Select an answer to reveal the explanation.
Short Explanation
Stage variables are name tags on the pipes—dev pipe to dev alias, test to test. One API definition, environment-specific pointers. Hard-coding prod into every stage floods the wrong tank.
Full Explanation
A municipal API Gateway API with distinct stages for development, test, and production should use stage variables so each stage resolves to the matching Lambda alias for that environment. Stage variables keep one API definition while wiring integrations to environment-appropriate aliases—dev to a volatile alias, prod to a pinned release alias. That is the standard multi-stage Lambda integration pattern on DVA-C02.
Hard-coding the production Lambda ARN into every stage's integration and ignoring aliases fails because lower stages then invoke production code or require constant template edits. Creating three completely separate REST APIs with unrelated IDs for each environment and never sharing a definition fails conceptually when the requirement is stage-based wiring of one API. Removing stages and relying on clients to guess function version numbers fails as an unsafe client-driven routing scheme.
Exam caveat: stage variable substitution in integration URIs must be configured correctly (including permissions for each alias invoke). Operational check: set stage variables per stage, invoke each stage, confirm CloudWatch logs show the expected alias/version, and ensure production stage cannot be flipped to $LATEST without a controlled change.