DVA-C02 Development with AWS Services Practice Question
A developer is building a serverless application using AWS SAM that includes an API Gateway REST API and a Lambda function. The developer wants to pass environment variables to the Lambda function based on the deployment stage (dev/prod). The stage name is provided as a SAM parameter. How should the developer define this in the SAM template?
⚠ Common exam trap
The trap here is that candidates may overcomplicate the solution by choosing Parameter Store (Option D) for dynamic values, missing that SAM parameters are the simplest native mechanism for stage-specific environment variables without external service dependencies.
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
✓
Define a SAM Parameter for the stage name, and reference it in the Lambda function's Environment property
AWS SAM allows you to define parameters (e.g., StageName) and reference them directly in the Lambda function's Environment property using CloudFormation intrinsic functions like !Ref. This enables dynamic injection of environment variables based on the deployment stage without modifying the template structure, aligning with Infrastructure as Code best practices for multi-environment deployments.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Define a SAM Parameter for the stage name, and reference it in the Lambda function's Environment property
Why this is correct
Defining a SAM Parameter for the stage name is the correct and recommended approach. This allows the stage name to be passed as an input during the `sam deploy` command, which then populates a CloudFormation parameter. The Lambda function's `Environment.Variables` property can then reference this parameter using `!Ref` or `Fn::Sub`, dynamically injecting the correct stage name into the function's runtime environment based on the deployment target.
- ✗
Use the Globals section of the SAM template to set environment variables
Why it's wrong here
Using the `Globals` section of the SAM template to set environment variables is inappropriate for stage-specific values. The `Globals` section applies static, default properties to all resources of a specified type (e.g., `AWS::Serverless::Function`). While useful for consistent settings like memory or timeout, `Globals` cannot dynamically accept input from deployment parameters, meaning they cannot vary based on the target stage.
- ✗
Hard-code the environment variables with different values in the template
Why it's wrong here
Hard-coding environment variables with different values directly within the template is an anti-pattern for multi-stage deployments. This approach would necessitate maintaining separate, nearly identical SAM templates for each environment (e.g., `template-dev.yaml`, `template-prod.yaml`). Such duplication leads to significant maintenance overhead, increases the risk of configuration drift, and severely hinders the reusability and consistency benefits of infrastructure as code.
- ✗
Use an AWS Systems Manager Parameter Store parameter and reference it in the function
Why it's wrong here
Using AWS Systems Manager Parameter Store fails because the requirement is to derive Lambda environment variables directly from a SAM template parameter (the stage name) at deployment time. Parameter Store is designed for externalising configuration values or secrets, not for dynamically mapping SAM parameter values to environment variables within the template itself. It is tempting as Parameter Store is a robust solution for storing sensitive or frequently changing configuration data, such as API keys or database connection strings, which a Lambda function can then reference. This would be appropriate if the values were pre-defined per stage and not dynamically derived from a SAM parameter.
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
One of 724 original DVA-C02 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.