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

Question

Options

• ACreate a new method on the API. Name the method production. Configure the method to include
• BCreate a new method on the API. Name the method production. Configure an integration request
• CDeploy the API to a new stage named production. Configure the stage to include a stage variable
• DDeploy the API to a new stage named production. Configure an integration request on the API's

• A
  9% (3)
• B
  3% (1)
• C
  3% (1)
• D
  85% (28)

Explanation

Option D is correct because the proper AWS pattern for routing API Gateway stages to specific Lambda aliases is to deploy a new API stage ("production") and configure the integration request to reference the Lambda function ARN using a stage variable (e.g., ${stageVariables.lambdaAlias}), with that variable set to prod on the production stage. This cleanly separates environments at the stage level without duplicating method definitions.

Options A and B are wrong because creating a new method named "production" is a misuse of the API Gateway model - methods represent HTTP verbs (GET, POST, etc.) on a resource path, not deployment environments. You cannot create an environment by adding a method.

Option C is close but wrong because simply adding a stage variable to the stage is insufficient; you must also update the integration request to actually use that stage variable in the Lambda ARN. Without wiring it into the integration, the stage variable has no effect on which Lambda alias is invoked.

Memory tip: Think of it as a handshake - the stage holds a variable (lambdaAlias = prod), and the integration request uses it (function:${stageVariables.lambdaAlias}). Both halves must be configured together; Option C only does one half, Option D does both.

No community discussion yet for this question.