A developer updates an AWS Lambda function that an Amazon API Gateway API uses. The API is the backend for a web application. The developer needs to test the updated Lambda function before deploying t

Question

Options

• ACreate a canary release deployment for the existing API stage. Deploy the API to the existing
• BUpdate the API Gateway API endpoint type to private. Deploy the changes to the existing API
• CCreate a new test API stage in API Gateway. Add stage variables to deploy the updated Lambda
• DCreate a new AWS CloudFormation stack to deploy a copy of the entire production API and

• A
  16% (4)
• B
  8% (2)
• C
  72% (18)
• D
  4% (1)

Explanation

Option C is correct because API Gateway stage variables let you point a specific stage (e.g., "test") to the updated Lambda function version or alias, completely isolating it from the production stage - no production users are affected, and no duplication of infrastructure is needed.

Why the distractors fail:

• A (Canary release): Canary deployments split production traffic - a percentage of real users will hit the new code, which directly violates the "must not affect production users" requirement.
• B (Private endpoint): Changing the endpoint type to private restricts network access, not Lambda version routing - it doesn't isolate the updated function from production and breaks the public app.
• D (New CloudFormation stack): Spinning up a full copy of the production API is operationally expensive and slow - it works, but it's the least efficient option when stage variables solve the problem natively.

Memory tip: Think of API Gateway stages like Git branches - each stage can point to a different Lambda alias or version via stage variables (${stageVariables.lambdaAlias}). "Test stage → test alias, prod stage → prod alias" is the standard pattern for safe pre-production testing without infrastructure duplication.

No community discussion yet for this question.