04 / 07

How do you manage different environments (dev, prod) in Lambda?

Difficulty: 6/10
environment variables, deployment pipelines, configuration management

Managing different environments like development, staging, and production in AWS Lambda ensures safe deployment and isolation of configurations. AWS offers multiple ways to separate and manage environment-specific settings using function versions, aliases, environment variables, and Infrastructure as Code tools.

Common Strategies for Environment Management
  1. 1

    Use Lambda aliases like dev, staging, and prod pointing to specific function versions.

  2. 2

    Set environment-specific configuration using Lambda environment variables.

  3. 3

    Deploy separate Lambda functions for each environment with unique names (e.g., my-function-dev, my-function-prod).

  4. 4

    Use infrastructure tools like CloudFormation, SAM, or Terraform with parameterized templates.

  5. 5

    Manage IAM roles and policies to restrict access based on environment.

  6. 6

    Use separate AWS accounts or isolated VPCs for production-critical functions.

Example: Setting Environment Variables for Different Aliases

Scenario Questions

0-2 years experience

  1. 1You need to store a database connection string that differs between dev and prod. How would you configure your Lambda function to use the correct value in each environment?
  2. 2If you accidentally deploy a Lambda version that still has a hard‑coded API endpoint for dev, what will happen when it runs in prod, and how would you fix it?
  3. 3Describe the steps to set up separate environment variables for dev and prod using the AWS console.

2-5 years experience

  1. 1Your CI/CD pipeline promotes a Lambda from dev to prod, and it fails in prod but works in dev. Walk me through how you would investigate the environment configuration differences.
  2. 2Explain the trade‑offs between using Lambda aliases with versioned environment variables versus maintaining separate CloudFormation stacks for dev and prod.
  3. 3You need to add a feature flag that should be enabled only in dev. How would you implement this without redeploying the prod Lambda?

5-8 years experience

  1. 1We have dozens of Lambdas across multiple services, each needing dev, test, and prod configs. Design a strategy to manage these configurations that minimizes duplication and supports safe rollouts.
  2. 2Discuss how you would handle secret rotation (e.g., DB passwords) across environments for Lambdas, ensuring no downtime and auditability.
  3. 3A Lambda reads its config from SSM Parameter Store and you notice increased latency in prod. What architectural changes could you make to mitigate the impact while preserving per‑environment isolation?

8+ years experience

  1. 1Our organization is moving from multiple independent CloudFormation stacks per environment to a single monorepo pipeline. How would you restructure Lambda environment management to support this migration while keeping dev and prod isolated?
  2. 2Different teams need to share common Lambda code but have distinct environment configurations. Propose a cross‑team governance model and tooling to enforce consistent environment handling.
  3. 3What long‑term risks arise from embedding environment‑specific values in Lambda code, and how would you evolve the architecture to eliminate those risks across all services?

Follow-up Questions

  • How would you verify that the correct variables are loaded before a production deployment?
  • What process would you follow to rotate a secret used by Lambdas without causing downtime?
  • Can you give an example where using aliases for environment separation could lead to confusion?
Share

Share via WhatsApp, X, Facebook, LinkedIn or copy link. Open Graph preview enabled.