How to Make a Lambda Production Alias Available Through API Gateway?

DVA-C02 By islever Editorial Last updated Aug 31, 2026

Short answer

C Deploy the API to a new stage named production. Configure the stage to include a stage variable that points to the prod Lambda function alias.

Question

A company has an Amazon API Gateway REST API that integrates with an AWS Lambda function. The API’s development stage references a development alias of the Lambda function named dev. A developer needs make a production alias of the Lambda function named prod available through the API. Which solution meets these requirements?

Create a new method on the API. Name the method production. Configure the method to include a stage variable that points to the prod Lambda function alias.
Create a new method on the API. Name the method production. Configure an integration request on the API’s development stage that points to the prod Lambda function alias.
Deploy the API to a new stage named production. Configure the stage to include a stage variable that points to the prod Lambda function alias. Correct Answer
Deploy the API to a new stage named production. Configure an integration request on the API’s production stage that points to the prod Lambda function alias.

Key Takeaways

The exam tests the stage-variable pattern for routing Lambda aliases per environment, and the trap is choosing an option that hard-codes the alias directly in the integration request instead of using a stage variable.

API Gateway stage variables let a single REST API integration point to different Lambda function aliases per deployment stage. The community unanimously (100% of votes) agrees that deploying the API to a new production stage with a stage variable referencing the prod alias is the correct solution.

Common mistake: Option D: deploying to a production stage but directly editing the integration request to point at the prod alias. This hard-codes the alias, breaks environment separation, and requires manual integration changes in every stage instead of letting stage variables switch aliases dynamically.

Expert Analysis

Why the Answer Is Correct

AWS's recommended pattern for multi-environment APIs is to reference a Lambda alias through a stage variable. Deploying the REST API to a new stage named "production" and defining a stage variable (for example, lambdaAlias = prod) used in the integration URI (arn:aws:lambda:region:account:function:fn:${stageVariables.lambdaAlias}) exposes the prod alias through that stage. This keeps the dev and prod environments isolated while reusing the same API definition and integration. All 100% of community votes selected C.

Why the Other Options Are Wrong

Options A and B create a new "method" named production, but API methods are HTTP verbs (GET, POST, etc.), not environment names, so this concept is invalid. Option B also hard-codes the prod alias into the development stage's integration request, which would modify the dev environment rather than create a production one. Option D creates the correct production stage but configures the integration request directly instead of using a stage variable, which commenters flagged as not ideal because it requires manually changing the integration in each stage and defeats dynamic environment management.

Community Comment Notes

Every comment supports C. Comment [2] explains that D is wrong because "directly configuring the integration request on the production stage is not ideal" and that stage variables let you "manage different environments without manually changing the integration in each stage." Comment [3] agrees the configuration "should be done using a stage variable, not by configuring the integration request directly." Comment [1] adds that this approach "separates environments and provides flexibility for future alias updates."

Official Reference

These links open the official vendor documentation in a new tab.

Exam Strategy

Whenever a question pairs Lambda aliases with API Gateway stages, choose the option that deploys to a new stage and uses a stage variable in the integration URI. Treat options that create methods named after environments or that edit integration requests directly as distractors. Memorize the pattern arn:aws:lambda:region:account:function:name:${stageVariables.lambdaAlias}.

Community Votes

100%

100% of anonymous learners picked answer C. Votes are pick records left by other test-takers — they are not the verified answer.

Discussion 3 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 3

Arad 👍 2 Answered C

C is the correct answer. D is wrong as directly configuring the integration request on the production stage is not ideal. You should use stage variables to configure the integration dynamically, allowing you to manage different environments without manually changing the integration in each stage.
xdeveloper 👍 2 Answered C

Choose C, D: While it's necessary to create a new stage called "production", the configuration should be done using a stage variable, not by configuring the integration request directly in the production stage.
LingZ 👍 2 Answered C

This solution separates environments and provides flexibility for future alias updates

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Practice All DVA-C02 Questions

Access 100 questions with complete answers and detailed explanations.

View Full DVA-C02 Practice Test →

← Back to DVA-C02 Study Guide