DVA-C02 Deployment Practice Question

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.

Go deeper

Related to this question