A city wants foundation-model routing changes that legal can approve without redeploying Lambdas every time. Which approach best supports controlled change management?
Select an answer to reveal the explanation.
Short Explanation
Legal shouldn't need a Lambda redeploy to bless a model swap. Put routing in external config—AppConfig-style—so approved changes land without touching application code every time.
Full Explanation
A city that wants foundation-model routing changes legal can approve without redeploying Lambdas every time should externalize model selection configuration—for example AppConfig-driven routing—so approved changes apply without code redeploys. Model IDs and route rules live in governed configuration; Lambda code reads the current config at runtime. Legal and change-advisory workflows approve a config diff, not a new function build, which matches municipal change management for sensitive GenAI routing.
Baking model IDs into Lambda source and requiring a full redeploy for every routing tweak couples governance speed to the software release train and discourages timely model swaps. Asking developers to edit production environment variables by hand during lunch with no approvals is uncontrolled change and fails audit expectations. Hiding the model ID inside client-side JavaScript where legal cannot review it places a governance-critical setting outside server-side review and exposes it to clients.
Exam caveat: AppConfig (or equivalent externalized config) is a common AWS pattern for operational parameters that must change under approval without redeploying compute.
Operational check: move model routing to AppConfig (or parameter store with a defined approval path), prove a model ID change reaches invokes without a Lambda redeploy, and retain who-approved-what logs for legal.