Jeff’s Note #
Unlike generic exam dumps, ADH analyzes this scenario through the lens of a Real-World Lead Developer.
For DVA-C02 candidates, the confusion often lies in how API Gateway stage variables interact with Lambda function aliases. In production, this is about knowing exactly how to configure distinct API Gateway stages to invoke specific Lambda aliases simultaneously. Let’s drill down.
The Certification Drill (Simulated Question) #
Scenario #
SkylineSoft, a growing SaaS startup, has implemented serverless APIs using Amazon API Gateway and AWS Lambda. They manage separate deployment environments—production and development—and use Lambda function versions with corresponding aliases (PROD and DEV). Currently, API Gateway has a single stage pointing to the PROD alias of the Lambda function.
The development team wants to update their API gateway setup so that both PROD and DEV Lambda function versions can be invoked independently and simultaneously via different API Gateway stages.
The Requirement: #
Configure API Gateway such that both PROD and DEV Lambda aliases are accessible concurrently through separate stages.
The Options #
-
A) Enable a Lambda authorizer for the Lambda function alias in API Gateway. Republish PROD and create a new stage for DEV. Create API Gateway stage variables for PROD and DEV stages. Point each stage variable to the PROD Lambda Authorizer or the DEV Lambda authorizer.
-
B) Set up a gateway response in API Gateway for the Lambda function alias. Republish PROD and create a new stage for DEV. Create gateway responses in API Gateway for PROD and DEV Lambda aliases.
-
C) Use an environment variable for the Lambda function alias in API Gateway. Republish PROD and create a stage for Development. Create API Gateway environment variables for PROD and DEV stages. Point each stage variable to the PROD Lambda function alias or the DEV Lambda function alias.
-
D) Use an API Gateway stage variable to configure the Lambda function alias. Republish PROD and create a stage for Development. Create API Gateway stage variables for PROD and DEV stages. Point each stage variable to the PROD Lambda function alias and to the DEV Lambda function alias.
Google adsense #
leave a comment:
Correct Answer #
D
Quick Insight: The Developer’s Imperative #
Using API Gateway stage variables to dynamically reference Lambda function aliases allows seamless environment segmentation without modifying integration URIs for each stage. This grants independent invocation of
PRODandDEVLambda versions while minimizing deployment complexity.
Content Locked: The Expert Analysis #
You’ve identified the answer. But do you know the implementation details that separate a Junior from a Senior?
The Expert’s Analysis #
Correct Answer #
Option D
The Winning Logic #
This solution leverages API Gateway stage variables to dynamically select the Lambda function alias integration URI per stage. By creating separate API Gateway stages (prod, dev), each stage can have a unique variable pointing to the appropriate Lambda alias ARN (arn:aws:lambda:region:acct:function:func:PROD for prod, and similarly for dev). The Lambda integration URI can reference the stage variable like:
arn:aws:lambda:region:acct:function:func:${stageVariables.lambdaAlias}
This approach enables the API Gateway stages to coexist and invoke different Lambda aliases simultaneously without modifying the API deployment or creating redundant APIs.
- For developers, this means better environment isolation and simplified deployment pipelines.
- It also avoids modifying Lambda authorizers or gateway responses which are unrelated to invoking different Lambda versions.
The Trap (Distractor Analysis): #
-
Why not A? Lambda authorizers control authorization, not which Lambda alias is invoked. Changing authorizers won’t solve simultaneous runtime invocation of different aliases.
-
Why not B? Gateway responses customize client responses and error handling but don’t affect which Lambda alias is called.
-
Why not C? API Gateway does not support environment variables in this manner for routing to Lambda aliases; stage variables are the correct method.
The Technical Blueprint #
# Example CLI command to create stage variables in API Gateway for prod and dev
# Prod stage pointing to PROD alias
aws apigateway create-deployment --rest-api-id abcdef1234 --stage-name prod
aws apigateway update-stage --rest-api-id abcdef1234 --stage-name prod --patch-operations op=replace,path=/variables/lambdaAlias,value=PROD
# Dev stage pointing to DEV alias
aws apigateway create-deployment --rest-api-id abcdef1234 --stage-name dev
aws apigateway update-stage --rest-api-id abcdef1234 --stage-name dev --patch-operations op=replace,path=/variables/lambdaAlias,value=DEV
The Comparative Analysis #
| Option | API Complexity | Performance Impact | Use Case |
|---|---|---|---|
| A | High (Lambda Auth) | No effect on Lambda routing | Authorizer configuration, irrelevant here |
| B | Medium (Gateway Responses) | No effect | Custom error/response messages only |
| C | Invalid (Env vars) | Unsupported | Misunderstood API Gateway feature |
| D | Low (Stage Variables) | Optimal | Environment-based Lambda alias routing |
Real-World Application (Practitioner Insight) #
Exam Rule #
“For the exam, always pick API Gateway stage variables when you want to dynamically invoke different Lambda aliases from multiple stages.”
Real World #
“In practice, using stage variables ensures clean separation between environments without duplicating APIs, simplifying CI/CD pipelines and reducing operational overhead.”
(CTA) Stop Guessing, Start Mastering #
Disclaimer
This is a study note based on simulated scenarios for the AWS DVA-C02 exam.