Feature flags and non-secret DynamoDB table names for a grants Lambda should change per stage without rebuilding the deployment package each time. Where should that configuration live?
Select an answer to reveal the explanation.
Short Explanation
Think of env vars as the sticky notes on the function's desk—swap the stage without reprinting the whole manual. Table names and feature flags belong there; real secrets still go in Secrets Manager. Hard-coding in source, passwords in Git, or baking flags into layers makes every config tweak a rebuild.
Full Explanation
Feature flags and non-secret DynamoDB table names for a grants Lambda should change per stage without rebuilding the deployment package each time—use Lambda environment variables for per-stage non-secret config while keeping secrets in Secrets Manager. Environment variables let IaC inject table names and flags per sandbox/test/prod stack while the same artifact rolls forward. Secrets stay out of env dumps and build logs.
Hard-coding table names and flags in source and cutting a new zip for every stage couples config to code and slows promotion. Committing plaintext database passwords next to flags in Git is a critical secret-handling failure. Baking stage-specific values into a Lambda layer forces layer version churn for ordinary config edits and blurs the line between shared code and environment config.
Exam caveat: environment variables are not for passwords, API keys, or connection strings that need rotation/audit. Use Secrets Manager or SSM Parameter Store SecureString for secrets, and consider AWS AppConfig for complex feature-flag operations when appropriate.
Operational check: parameterize table names/flags via env in SAM/CDK per stage; reference secrets by ARN at runtime; promote the same package across stages; and scan repos for hard-coded stage values or passwords.