A city permitting portal bakes stage-specific API base URLs into the built Lambda zip, so every environment change forces a full rebuild. What should the developers do?
Select an answer to reveal the explanation.
Short Explanation
Think of the zip like a sealed lunchbox—same sandwich, different sticky notes for each cafeteria. Bake the code once, then inject API URLs with env vars, AppConfig, or Parameter Store so you are not rebuilding for every stage. Editing live zips or shipping four Git artifacts is how civic deploys turn into spaghetti.
Full Explanation
Deployable artifacts for a city permitting portal should stay environment-agnostic. Stage-specific API base URLs belong in configuration injected at deploy or runtime—Lambda environment variables, AWS AppConfig, Systems Manager Parameter Store, or Secrets Manager—while the packaged zip remains immutable across stages. That pattern lets one reviewed artifact promote from sandbox to production without rebaking URLs for every municipal environment change, which is the Domain 3 packaging expectation.
Hard-coding a single production URL and routing all stages through production API Gateway fails because lower environments then depend on live production endpoints and risk unintended writes. Committing a separate zip per environment into Git fails conceptually by multiplying binaries and baking configuration into versioned artifacts. Editing the deployed zip directly in the Lambda console after each promote fails because it breaks reproducibility and auditability of releases.
Exam caveat: configuration injection still needs per-stage values managed carefully so test does not silently point at production secrets or URLs. Operational check: promote one artifact digest through test and prod, confirm only env/config differs, and verify no stage URL strings remain hardcoded in the bundle.