Consider an AWS Lambda function configured with environment variables. What happens if you update an environment variable value in the Lambda console while the function is running?
Think about how environment variables are loaded when a Lambda function starts.
Lambda loads environment variables when a function instance starts. Changing environment variables affects only new instances or new invocations after restart. Running instances keep using the old values.
You want to store sensitive data like API keys in Lambda environment variables. Which option best improves security?
Think about how AWS helps protect sensitive data in Lambda.
Encrypting environment variables with AWS KMS ensures secrets are protected at rest and decrypted only during function execution, improving security.
Given an environment variable named API_ENDPOINT, which code snippet correctly accesses its value inside a Node.js Lambda handler?
exports.handler = async (event) => {
// Access environment variable here
};Recall how environment variables are accessed in Node.js.
In Node.js, environment variables are accessed via process.env.VARIABLE_NAME. Both dot notation and bracket notation work, but dot notation is simpler and common.
You have multiple Lambda functions deployed in development, staging, and production. What is the best practice to manage environment variables for these environments?
Think about how to keep environment variables consistent and manageable across environments.
Using infrastructure as code (like CloudFormation or Terraform) to define environment variables per environment ensures consistency, version control, and easy updates.
AWS Lambda has a size limit for all environment variables combined. What is the result if you try to deploy a Lambda function with environment variables exceeding this limit?
Consider AWS Lambda deployment constraints and error handling.
AWS Lambda enforces a hard limit on total environment variable size. Deployments exceeding this limit fail with an error, preventing deployment.