Versions, aliases and stages: DVA-C03 study notes and practice questions
What to know about Versions, aliases and stages for the DVA-C03 exam, from the Testing and Deployment domain (22% of the exam guide), then 3 free questions to test it. Part of the DVA-C03 study guide.
These questions ask how to keep one codebase running in several environments, and how to promote or roll back a release without rebuilding it.
Lambda versions and aliases
A version is a numbered, immutable copy of a function’s code and configuration. Publishing a version does not change any earlier version.
An alias is a named pointer, such as dev, test or prod, to one version. Clients call the alias, so you can move it without changing callers.
Weighted aliases send a percentage of traffic to a second version. This is how canary releases on a Lambda alias work, and it is the basis for CodeDeploy’s Lambda traffic shifting.
Rolling back is usually a matter of pointing the alias back to the previous version, which takes effect almost at once.
Aliases do not hold their own environment variables. Use a different function per environment, or read per-environment settings from Parameter Store or AppConfig.
API Gateway stages
A stage is a named snapshot of a REST API deployment, such as dev or prod. Each stage has its own invoke URL.
Changing an API’s resources or methods does not change a stage until you deploy the API to that stage. A new path can return Not Found on dev until the deployment is made.
Stage variables let one API definition point to different backends. For example, prod can set lambdaAlias=prod, and an integration URI can use ${stageVariables.lambdaAlias}.
Stage canary release settings can send a percentage of a stage’s traffic to a new deployment.
Container image tags
A tag such as v1.4.0 is a label on an image. The same image should be promoted from dev to prod, not rebuilt.
Lambda resolves an image tag to a digest when you create or update the function. Pushing a new image under the same tag does not change the function until you deploy it again.
Use immutable tags in ECR (see the containers note) so a tag always names the same image.
How to choose
Scenario wording
Answer
Keep a stable name for callers while the code behind it changes
Lambda alias
Send 10% of traffic to a new Lambda version
Weighted alias
Undo a bad Lambda release quickly
Point the alias to the previous version
Same API, different backend per environment
API Gateway stage variables
New resource returns Not Found after you saved it
Deploy the API to the stage
Promote a tested container to production
Deploy the same image tag or digest
Common traps
Pointing an alias at $LATEST when the question needs a fixed, testable release.
Rebuilding the image for prod. The tested artifact is no longer the one deployed.
Assuming a saved API change is live. It is live only after a stage deployment.
Changing a published Lambda version’s code. Versions are immutable. Publish a new version instead.
A developer adds a new resource, /orders/{id}, with a GET method to a REST API in Amazon API Gateway, and saves the change.
The dev stage serves the API, and the existing paths still work. Calls to the new path return Not Found, although the method appears in the API Gateway console.
What should the developer do?
Choose one answer.
AA. Delete the dev stage and create it again, so that it reads the latest version of the API definition.
BB. Create a new deployment of the API, and choose that deployment for the dev stage.
CC. Clear the dev stage's cache, since the cache still holds the old API definition.
DD. Turn on canary release for the dev stage and send 100% of its traffic to the canary.
Show the answer and explanation
Answer: B
A. Wrong: Recreating the stage still points it at a deployment, so the new resource is missing until a deployment is created. It also removes the stage's settings and interrupts callers.
C. Wrong: API Gateway caches responses, not the API definition. Clearing the cache does not add the new resource to the deployed API.
D. Wrong: A canary still serves a deployment, and the new resource must be in a deployment first. Sending all traffic to the canary changes which deployment serves requests, not what that deployment contains.
Explanation
API Gateway serves each stage from a deployment, a snapshot of the API's configuration. Changes to resources and methods require a redeployment before any stage uses them. Clearing caches, recreating the stage or using a canary does not put the new resource into the deployment.
The prod alias points to version 5. Shortly after version 5 was released, customers began to see errors from one code path. The team must restore the previous behavior within minutes, without changing any client, and the fix must not depend on code that has not been tested.
What should the developer do?
Choose one answer.
AA. Update the code in $LATEST to match version 4, publish a new version, and point the prod alias at it.
BB. Point the prod alias back at version 4, which is still published and unchanged.
CC. Delete version 5 so that the prod alias falls back to version 4 automatically.
DD. Set an environment variable on the prod alias that switches the failing code path off.
Show the answer and explanation
Answer: B
A. Wrong: Publishing from $LATEST creates a new build from code that may not match version 4 and has not been tested. It takes more steps than moving the alias, and it does not meet the rule against untested code.
C. Wrong: Deleting a version does not move an alias. Prod would still need its alias changed, and the failing code would be removed without any way to compare it with the fix.
D. Wrong: Aliases hold no environment variables. Only a function version or $LATEST has its own configuration, and the failing code would stay live.
Explanation
Each published version of a Lambda function is a fixed snapshot, and an alias is only a pointer to one version. Moving prod back to version 4 is a rollback that needs no code change, and clients keep calling the alias. Deleting versions or using environment variables on an alias does not do this.
A front-end team hosts a React web app with AWS Amplify Hosting, connected to a Git repository.
Commits to main must update the production site. Commits to develop must publish a separate beta site with its own URL for testers. The team wants one Amplify app to manage both, so it does not maintain two sets of hosting configuration.
What should the developer do?
Choose one answer.
AA. Create a second Amplify app connected to the same repository, and point it at the develop branch.
BB. Add the develop branch to the existing Amplify app as a second connected branch.
CC. Copy the develop build output into a folder of the production S3 bucket by hand after each change.
DD. Create an AWS CodeDeploy deployment group that sends develop builds to a test fleet of instances.
Show the answer and explanation
Answer: B
A. Wrong: A second app works, but it creates a second set of hosting configuration, which the team wants to avoid. It also splits management across two apps when one app can host both branches.
C. Wrong: Manual copies bypass the Git-based pipeline, so the beta site is not rebuilt on each commit. They also put untested files in the production bucket.
D. Wrong: CodeDeploy deploys to compute such as EC2 instances or Lambda functions, not to Amplify Hosting apps. It is not connected to a repository branch.
Explanation
Amplify Hosting connects Git branches to an app and deploys each connected branch automatically, with its own URL. Adding a second branch to the existing app keeps production and beta hosting in one place, so there is one set of hosting configuration to manage.
Want more on Versions, aliases and stages? The 5 full-length practice sets have 14 more Versions, aliases and stages questions, 390 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →