Before promoting a citizen-portal Lambda to the shared test stage, developers must invoke it locally with a realistic API Gateway proxy event. Which approach best meets that need?
Select an answer to reveal the explanation.
Short Explanation
You would not debut a new bus route without a dry run—same idea here. SAM (or similar Lambda tooling) lets you fire a sample API Gateway proxy event at the function before it hits the shared stage. Skipping shape checks until production is how surprise 500s sneak into citizen portals.
Full Explanation
Before promoting a citizen-portal Lambda to the shared test stage, developers must invoke it locally with a realistic API Gateway proxy event—use AWS SAM or the Lambda tooling to invoke the function with a sample API Gateway proxy event payload in the local or SAM environment. Local invoke validates route keys, header casing, body encoding (including base64 flags), and authorizer context shape before the function competes for shared stage capacity. Catching event-shape bugs on a laptop is cheaper than debugging in a contested municipal test account during a release freeze.
Deploying straight to production and validating only with live homepage traffic endangers citizens and teaches nothing until impact is public. Replacing the handler with a hardcoded 200 and skipping event-shape testing abandons the stated goal. Opening the console metrics tab and assuming API Gateway events match CloudWatch defaults never exercises the handler code path.
Exam caveat: proxy integration event schemas differ across REST vs HTTP APIs—check in fixtures that match what you deploy. Local invoke does not replace stage integration tests, but it should gate obvious breaks before promotion.
Operational check: keep versioned sample API Gateway events in the repo; run local invoke in CI; assert statusCode and body; then promote to the shared test stage with integration checks.