The same grant-scoring Lambda code needs higher memory and longer timeout in load-test than in production. How should configuration differ across environments?
Select an answer to reveal the explanation.
Short Explanation
Load-test is a dress rehearsal with different stage lights—memory and timeout can differ without forking the business logic. Put those knobs in IaC or env-specific stacks, not magic numbers baked into source.
Full Explanation
When the same grant-scoring Lambda code needs higher memory and longer timeout in load-test than in production, parameterize Lambda memory, timeout, and related settings per environment through IaC or environment-specific stacks instead of one-size hardcoding in code. Load-test stacks can raise memory and timeout to explore ceilings; production keeps tighter, cost-aware settings that match measured SLAs. The artifact stays identical while configuration differs by stage—exactly how municipal promotions should work across sandbox, test, and prod accounts.
Hardcoding production timeout inside the source and editing it by hand before every test run invites human error and unreviewed production values. Shipping one immutable concurrency value only in a git commit message is not configuration management. Forcing load-test and production to share identical undersized settings forever prevents meaningful performance testing or, conversely, forces production to pay for test-only headroom.
Exam caveat: parameterize carefully so production cannot accidentally inherit load-test’s huge reserved concurrency without review. Use distinct stacks or parameter files, and gate production applies with approvals. Code should read timeout-sensitive logic defensively but not embed stage numbers.
Operational check: define memory/timeout parameters in SAM/CDK per environment; deploy load-test with elevated values; keep production at profiled settings; diff stack parameters in review; and block merges that hardcode stage-specific limits in handler source.