A township uses one OpenAPI definition for its business-license API across environments, but each stage must call a different backend. How should that be deployed?
Select an answer to reveal the explanation.
Short Explanation
One blueprint, three job sites—different lumber suppliers on each lot. Keep the OpenAPI contract shared, then point each API Gateway stage at its own backend. Three drifting specs or everyone hitting prod is how towns get surprises.
Full Explanation
A township that uses one OpenAPI definition for its business-license API across environments should deploy the same OpenAPI definition to API Gateway stages for dev, test, and prod while binding stage-specific backend configuration. Shared contracts with stage-specific integrations keep municipal clients consistent while pointing each stage at the right Lambda aliases or HTTP backends. That is the intended multi-stage API design pattern.
Maintaining three unrelated OpenAPI files that intentionally diverge so stages never share a contract fails because clients then face incompatible APIs per environment. Publishing only a prod stage and having developers call production Lambdas during local work fails conceptually by risking production during development. Skipping API Gateway stages and hard-coding one execute-api URL into every municipal client fails by removing environment routing flexibility.
Exam caveat: stage variables or integrations must be reviewed so test never silently calls production backends through a mis-set variable. Operational check: deploy the shared OpenAPI to all stages, verify each stage's integration URI, and run contract tests per stage against the correct backend.