A developer is building a Lambda function that reads from an Amazon DynamoDB table. The table name is currently hard-coded in the function, but the table name may change in the future. The developer wants to avoid modifying the Lambda code when the table name changes. Which solution is the MOST efficient?

Defining the DynamoDB table name as an environment variable is the most efficient solution. Lambda environment variables are designed for exactly this purpose: storing configuration settings that can change without requiring code modification. The function can easily access these variables using standard language features (e.g., process.env.TABLENAME in Node.js, os.environ['TABLENAME'] in Python). Storing the table name in /tmp is incorrect because /tmp is ephemeral storage and its contents are not guaranteed to persist across invocations, nor is it a standard way to pass configuration. Placing it in a Lambda layer would require updating and deploying the layer every time the table name changes, which is less efficient than updating an environment variable. Declaring a global variable inside the Lambda function code still hard-codes the value within the deployment package, requiring a code update and redeployment if the table name changes.