DVA-C02 Deployment Practice Question
A developer is deploying a serverless application using the AWS Serverless Application Model (SAM). The developer wants to set environment variables for the Lambda function that are specific to the deployment stage (e.g., dev, prod). How should the developer accomplish this?
⚠ Common exam trap
Candidates often think they must use complex CloudFormation Conditions or Mappings to manage environment-specific values, but the simplest and most standard approach in AWS SAM is to use Parameters to pass these values during deployment (e.g., via sam deploy --parameter-overrides).
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Use SAM parameters to pass stage-specific values into the template.
AWS SAM natively supports template parameters, which allow you to pass stage-specific values (e.g., environment variables) at deployment time. By defining a parameter in the SAM template and referencing it in the Lambda function's `Environment.Variables` section, you can inject different values for dev, prod, etc., without modifying the template itself. This approach leverages CloudFormation's parameter substitution to keep the template reusable and environment-agnostic.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Use SAM parameters to pass stage-specific values into the template.
Why this is correct
SAM parameters, which are built upon AWS CloudFormation parameters, provide a robust and standard mechanism to inject environment-specific values into a single, reusable template. Developers define these parameters in the `Parameters` section of their `template.yaml` and then supply different values at deployment time, for instance, using `sam deploy --parameter-overrides Environment=Prod`. This allows a single template to be deployed consistently across development, staging, and production environments with distinct configurations, promoting reusability and reducing configuration drift.
- ✗
Define the environment variables in the Lambda function configuration and use 'Ref' with the stage name.
Why it's wrong here
While `Ref` is a valid CloudFormation intrinsic function, it is used to reference existing resources within the template or parameters passed to it. There is no built-in CloudFormation pseudo-parameter or intrinsic function that automatically resolves to a generic "stage name" during deployment, such as `AWS::StageName`. Attempting to use `Ref` with an arbitrary stage name string would lead to an unresolved reference error during CloudFormation stack creation, as the reference target would not exist.
- ✗
Hardcode the environment variables in the SAM template for each stage.
Why it's wrong here
Hardcoding stage-specific environment variables directly within the SAM template would necessitate maintaining separate, distinct `template.yaml` files for each deployment environment (e.g., `template-dev.yaml`, `template-prod.yaml`). This approach severely hinders reusability, introduces significant configuration drift risks, and dramatically increases the operational overhead for maintenance and updates. Any change to the core application structure or shared configuration would require identical modifications across all environment-specific templates, making it impractical.
- ✗
Use AWS CloudFormation 'Conditions' to set environment variables based on the stage.
Why it's wrong here
AWS CloudFormation `Conditions` are primarily designed to conditionally create or omit entire resources or specific resource properties based on parameter values evaluated during stack creation. While technically possible to construct complex conditions to select environment variable blocks, this is an overly verbose, complex, and non-idiomatic approach for managing simple stage-specific *values*. Parameters are the intended and far more efficient mechanism for injecting varying configuration data into a single resource definition across environments, rather than conditionally including entire blocks.
Quick reference
Cloud Service Model Comparison
| Model | You Manage | Provider Manages | Examples |
|---|---|---|---|
| IaaS | OS, runtime, apps, data | Hardware, hypervisor, networking | EC2, Azure VMs, GCP Compute Engine |
| PaaS | Apps and data | OS, runtime, middleware, hardware | Elastic Beanstalk, Azure App Service |
| SaaS | Data and settings only | Everything else | Microsoft 365, Salesforce, Workday |
| FaaS / Serverless | Function code only | Infra, scaling, runtime | Lambda, Azure Functions, Cloud Run |
| CaaS | Containers and apps | Kubernetes, OS, hardware | EKS, AKS, GKE |
Go deeper
Related to this question
About these practice questions
Courseiva writes every DVA-C02 question from scratch — 1,135 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This DVA-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the DVA-C02 exam.