DVA-C02 Deployment Practice Question
An organization wants to deploy a microservices architecture using AWS Lambda functions. They need to manage environment variables for each function across different stages (dev, test, prod). Which approach is the MOST secure and maintainable?
⚠ Common exam trap
DVA-C02 often tests the misconception that Lambda environment variables are secure enough for secrets, but they are stored in plaintext and lack centralized management; candidates must recognize that Parameter Store (or Secrets Manager) is the preferred secure and maintainable solution for cross-stage configuration.
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 AWS Systems Manager Parameter Store with separate paths for each stage.
AWS Systems Manager Parameter Store allows you to store configuration data and secrets as parameters with hierarchical paths (e.g., /myapp/dev/db-url, /myapp/prod/db-url). This centralizes management, supports versioning, and enables fine-grained IAM access control per stage. Lambda functions can retrieve these parameters at runtime, ensuring that sensitive values are not exposed in code or function configuration. This approach is both secure (encryption via KMS, audit via CloudTrail) and maintainable (update once, applies everywhere).
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 AWS Systems Manager Parameter Store with separate paths for each stage.
Why this is correct
AWS Systems Manager Parameter Store supports hierarchical paths such as /myapp/dev/db_url and /myapp/prod/db_url, enabling a single Lambda function to retrieve stage-specific configuration at runtime via GetParameter. This keeps configuration external to code, can be secured with IAM policies and KMS encryption for SecureString parameters, and supports versioning and change history. It is the correct approach because it is centralized, stage-aware, and directly accessible from Lambda without redeploying infrastructure.
- ✗
Use AWS CloudFormation parameters to pass values at deployment.
Why it's wrong here
AWS CloudFormation parameters are resolved when the stack is created or updated, so they are deployment-time inputs for provisioning infrastructure, not a runtime configuration service. While you could use them to inject values into a Lambda function's environment variables, those values become fixed in the function's configuration and any change requires a stack update and a new function version. This couples configuration to infrastructure lifecycle and cannot be updated independently per stage without separate stack management, making it unsuitable for dynamic runtime configuration.
- ✗
Hardcode the environment variables in each Lambda function code.
Why it's wrong here
Hardcoding environment variables, such as database credentials or service endpoints, directly into Lambda function code violates the separation of configuration from code and creates a serious security risk if the source is committed to a repository. It also prevents stage-specific overrides because the same code cannot behave differently in dev, test, and production without code changes and redeployment. This is not maintainable and is explicitly anti-pattern for microservices that must run across multiple environments.
- ✗
Store environment variables in the Lambda function configuration.
Why it's wrong here
Lambda does let you define environment variables in the function configuration, but these are static key-value pairs attached to a function version, not inherently stage-aware. If you try to manage per-stage values this way, you must create separate functions, versions, or aliases and manually update each configuration, which is error-prone and does not scale. Also, while Lambda can encrypt environment variables with KMS, storing them centrally in Parameter Store with IAM-based access control is more secure and easier to audit across a microservices architecture.
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
This DVA-C02 question is part of Courseiva's 1,135-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Amazon Web Services exam blueprint
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.