Jeff’s Note #
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 understanding the immutability of Lambda versions versus the mutability of $LATEST and how aliases provide deployment pointers. In production, this is about knowing exactly how to create isolated testing environments without creating entirely new Lambda functions or risking production overwrites. This question tests your grasp of Lambda’s version control mechanism combined with API Gateway’s stage-based routing. Let’s drill down.”
The Certification Drill (Simulated Question) #
Scenario #
A fintech startup, PaySecure, has built a transaction validation API using Amazon API Gateway backed by an AWS Lambda function. After a recent production release, customers reported intermittent validation failures. The development team’s Lead Engineer identified a logic error in the Lambda function code and immediately fixed it.
Before promoting the fix to production, the engineer must validate the corrected code in a separate testing environment. However, PaySecure currently only has a production environment deployed. Additionally, the engineering team is distributed across time zones, and there’s a risk that another developer might unknowingly deploy changes to the same Lambda function during the testing window, overwriting the hotfix.
The Lead Engineer needs to create an isolated development environment that:
- Uses the corrected Lambda code
- Allows testing via API Gateway
- Prevents other developers from overwriting the fix during testing
- Requires minimal development effort
The Requirement: #
Implement a solution that enables isolated testing of the Lambda hotfix through API Gateway while guaranteeing code immutability during the test cycle.
The Options #
- A) Create a new resource in the current stage. Create a new method with Lambda proxy integration. Select the Lambda function. Add the hotfix alias. Redeploy the current stage. Test the backend.
- B) Update the Lambda function in the API Gateway API integration request to use the hotfix alias. Deploy the API Gateway API to a new stage named hotfix. Test the backend.
- C) Modify the Lambda function by fixing the code. Test the Lambda function. Create the alias hotfix. Point the alias to the $LATEST version.
- D) Modify the Lambda function by fixing the code. Test the Lambda function. When the Lambda function is working as expected, publish the Lambda function as a new version. Create the alias hotfix. Point the alias to the new version.
- E) Create a new API Gateway API for the development environment. Add a resource and method with Lambda integration. Choose the Lambda function and the hotfix alias. Deploy to a new stage. Test the backend.
Correct Answer #
B and D
Quick Insight: The Immutability Imperative #
For DVA-C02, understanding Lambda version immutability is critical. Published versions are read-only snapshots—they cannot be modified or overwritten. Aliases are mutable pointers to versions. API Gateway stages route traffic to specific Lambda targets (versions, aliases, or $LATEST). This question tests whether you understand:
- How to lock code (publish a version)
- How to route to it safely (create an alias)
- How to expose it for testing (deploy to a new API Gateway stage)
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 #
Options B and D
The Winning Logic #
Why Option D is Essential: #
Lambda’s $LATEST version is mutable—any developer can update it by deploying new code. To prevent overwrites during testing, you must:
- Publish the fixed code as a new version (e.g., version 2)
- Create an alias (e.g.,
hotfix) that points to this immutable version
Key API Calls:
# After fixing the code in $LATEST
aws lambda publish-version --function-name transaction-validator
# Output: { "Version": "2", "FunctionArn": "arn:aws:lambda:...:function:transaction-validator:2" }
# Create alias pointing to the immutable version
aws lambda create-alias \
--function-name transaction-validator \
--name hotfix \
--function-version 2
Why this works:
- Version 2 is now frozen—no one can modify it
- The
hotfixalias provides a stable, human-readable pointer - Other developers can continue working on $LATEST without affecting your test
Why Option B is Essential: #
You need to expose the hotfix alias through API Gateway without disrupting production. Creating a new stage (instead of modifying the production stage) achieves this:
Steps:
- Update the Lambda integration to use the alias:
- In API Gateway console: Integration Request → Lambda Function →
transaction-validator:hotfix
- In API Gateway console: Integration Request → Lambda Function →
- Deploy to a new stage (e.g.,
hotfixordev)
API Gateway Stage Behavior:
# Production stage continues using the original Lambda target
https://api.paysecure.com/prod/validate → transaction-validator:prod
# New hotfix stage routes to your isolated alias
https://api.paysecure.com/hotfix/validate → transaction-validator:hotfix (version 2)
Why this works:
- Zero impact on production traffic
- Independent stage variables and throttling settings
- Minimal effort—no new API creation needed
The Trap (Distractor Analysis) #
Why not Option A? #
- Creating a new resource/method in the current stage and redeploying means you’re modifying the production stage
- API Gateway stages are atomic—when you redeploy, all methods in that stage are updated
- This introduces risk to production and doesn’t create true isolation
- Trap: Confuses “resource-level isolation” with “stage-level isolation”
Why not Option C? #
- Pointing the alias to $LATEST defeats the entire purpose
- $LATEST is mutable—another developer’s push will immediately change what the alias points to
- Trap: Tests your understanding of Lambda version mutability (a core DVA-C02 concept)
Why not Option E? #
- Creating an entirely new API Gateway API is massive overkill
- Requires duplicating resources, methods, authorizers, models, and stage configurations
- Violates the “LEAST development effort” constraint
- Trap: Tests whether you know API Gateway stages provide built-in environment isolation
The Technical Blueprint #
Developer Implementation Flow #
# Step 1: Fix the code locally and test
# (Assume code is in lambda_function.py)
# Step 2: Deploy the fix to $LATEST
aws lambda update-function-code \
--function-name transaction-validator \
--zip-file fileb://function.zip
# Step 3: Publish an immutable version (D)
aws lambda publish-version \
--function-name transaction-validator \
--description "Hotfix for validation logic bug"
# Returns: { "Version": "2", ... }
# Step 4: Create alias pointing to version 2 (D)
aws lambda create-alias \
--function-name transaction-validator \
--name hotfix \
--function-version 2
# Step 5: Update API Gateway integration (B)
aws apigateway update-integration \
--rest-api-id abc123 \
--resource-id xyz789 \
--http-method POST \
--patch-operations op=replace,path=/uri,value=arn:aws:apigateway:us-east-1:lambda:path/2015-03-31/functions/arn:aws:lambda:us-east-1:123456789012:function:transaction-validator:hotfix/invocations
# Step 6: Deploy to new stage (B)
aws apigateway create-deployment \
--rest-api-id abc123 \
--stage-name hotfix \
--description "Hotfix testing stage"
# Step 7: Test
curl -X POST https://abc123.execute-api.us-east-1.amazonaws.com/hotfix/validate \
-H "Content-Type: application/json" \
-d '{"transaction_id": "12345"}'
Lambda Alias Behavior #
{
"AliasArn": "arn:aws:lambda:us-east-1:123456789012:function:transaction-validator:hotfix",
"Name": "hotfix",
"FunctionVersion": "2",
"Description": "Immutable pointer to hotfix version",
"RoutingConfig": {
"AdditionalVersionWeights": {}
}
}
Key Point for DVA-C02: Aliases support weighted routing (e.g., 90% to version 2, 10% to version 3), enabling canary deployments—a common exam scenario.
The Comparative Analysis #
| Option | Code Immutability | API Gateway Isolation | Development Effort | Production Risk | Correct? |
|---|---|---|---|---|---|
| A | ❌ Not addressed | ❌ Modifies production stage | Low | High (prod redeploy) | ❌ |
| B | ⚠️ Depends on D | ✅ New stage = full isolation | Low | None | ✅ |
| C | ❌ Alias → $LATEST (mutable) | ⚠️ Not addressed | Low | High (overwrite risk) | ❌ |
| D | ✅ Published version (immutable) | ⚠️ Not addressed | Low | None | ✅ |
| E | ⚠️ Depends on alias | ✅ New API = isolation | High (full duplication) | None | ❌ |
DVA-C02 Exam Insight: AWS heavily tests the combination pattern—you need BOTH version immutability (D) AND stage-based routing (B). Neither alone is sufficient.
Real-World Application (Practitioner Insight) #
Exam Rule #
“For the exam, when you see ‘prevent overwrites during testing’ + ‘minimal effort,’ always choose:
- Publish a Lambda version (immutability)
- Create an alias (readable pointer)
- Deploy to a new API Gateway stage (traffic isolation)
Never use $LATEST for stable testing environments.”
Real World #
“In production at scale, we extend this pattern with:
- CI/CD automation: GitLab CI publishes versions and updates aliases on merge
- Stage variables: API Gateway stages use
${stageVariables.lambdaAlias}to dynamically target aliases - Alias weighted routing: Gradual traffic shifting (95% prod, 5% canary)
- CloudWatch alarms: Automatic rollback if error rate exceeds threshold
For this startup scenario, the manual approach (B+D) is perfect for a quick hotfix. But enterprises would wrap this in AWS CodePipeline with Lambda@Edge for global deployments.”
Stop Guessing, Start Mastering #
Disclaimer
This is a study note based on simulated scenarios for the AWS DVA-C02 exam. Always refer to the official AWS documentation for the most current best practices.