Both environment variables and the AWS Systems Manager (SSM) Parameter Store can be used to manage configuration values for Lambda functions. However, they serve different purposes and have distinct capabilities when it comes to security, scalability, and best practices.
Key-value pairs set directly in the Lambda configuration
Available at runtime via process.env in Node.js or os.environ in Python
Supports encryption using AWS KMS for sensitive data
Limited to 4 KB in total size per function
Ideal for non-sensitive, short-lived, environment-specific settings
Centralized service for managing configuration data and secrets
Supports both plain-text and encrypted (SecureString) parameters
Accessible via AWS SDK (e.g., Boto3, AWS SDK for JS)
Allows versioning, auditing, and fine-grained access control
Better suited for storing shared, sensitive, or dynamic values
How would you store a database connection string for a Lambda function that needs to be changed without redeploying the code?
If you set an environment variable in the Lambda console and also a parameter in SSM with the same name, which one does the function see at runtime?
What happens if you try to reference an SSM SecureString parameter directly as an environment variable without using the Lambda console integration?
You notice that after rotating a secret in Parameter Store, your Lambda still uses the old value. Walk me through how you would debug this issue.
When deciding between using Lambda environment variables versus SSM Parameter Store for configuration, what trade‑offs do you consider regarding security, versioning, and deployment speed?
Suppose you need to pass a large JSON config to a Lambda, but environment variables have size limits. How would you handle this using SSM?
Design a pattern for managing per‑environment (dev, staging, prod) configuration for hundreds of Lambdas using SSM Parameter Store. How would you handle naming, permissions, and rollout without downtime?
At scale, fetching parameters from SSM on each invocation can add latency. Explain how you would mitigate this while keeping secrets secure.
If a compliance audit requires all secrets to be encrypted with a customer‑managed CMK, how does that affect your choice between environment variables and SSM, and what changes would you make to the Lambda deployment pipeline?
Your organization is migrating legacy Lambdas that currently embed credentials in environment variables to a centralized Parameter Store approach. Outline a migration strategy that minimizes risk, ensures auditability, and supports multiple teams.
Consider a multi‑region, multi‑account architecture where the same Lambda code runs everywhere but needs region‑specific config. How would you design the configuration management using SSM and environment variables to balance consistency and flexibility?
From a long‑term operational perspective, what governance processes would you put in place to manage lifecycle (creation, rotation, deprecation) of parameters versus environment variables across dozens of services?