A team runs one Amazon API Gateway REST API with separate dev, test and prod stages, all backed by the same Lambda function. They want each stage to invoke its matching Lambda alias (dev, test, prod) so promoting code never requires editing the integration or redeploying a different API. How should the developer wire the integration?
- ADefine a stage variable such as lambdaAlias on each stage and reference it in the integration URI with a syntax like function:name:${stageVariables.lambdaAlias} so each stage resolves its own alias. Correct
- BCreate three separate REST APIs, one per environment, and hard-code the matching Lambda alias ARN into each API integration request so every stage stays isolated.
- CAttach a Lambda authorizer to each method that reads the requesting stage and forwards the call to the correct alias before the main integration executes the function.
- DUse a single $LATEST integration for every stage and rely on the deployment history of the API to send each stage to the right version of the function automatically.
Why A is correct: A stage variable injected into the integration URI lets one API resolve a different Lambda alias per stage at invoke time, so promotion only changes the variable value with no integration edit.
Why B is wrong: Three duplicate APIs multiply maintenance and drift, and hard-coding alias ARNs is exactly the per-stage editing the team wants to avoid when promoting code.
Why C is wrong: An authorizer returns an IAM policy for authorisation and cannot reroute an invocation to a different alias, so it is the wrong mechanism for per-stage backend selection.
Why D is wrong: Pointing all stages at $LATEST gives every environment the same unversioned code, and API deployment history tracks stage snapshots, not which Lambda alias is invoked.