API Gateway fronts a grant-application API. Invalid ZIP codes and missing required fields currently reach Lambda and clutter logs. Where should developers enforce request validation first?
Select an answer to reveal the explanation.
Short Explanation
Stop bad ZIP codes at the front desk — API Gateway — before they wander into Lambda and trash the log book. Request models and validators catch missing fields early. Business code should see clean input.
Full Explanation
API Gateway fronts a grant-application API, and invalid ZIP codes plus missing required fields currently reach Lambda and clutter logs. Developers should enforce request validation first at the API Gateway layer with request models or validators so malformed requests never invoke business code. Edge validation cheaply rejects contract violations, reduces Lambda cost and noise, and returns consistent 4xx responses before grant business rules run. That is the municipal “front desk checks the form is complete” control, leaving Lambda for eligibility logic.
Validating only inside CloudWatch Logs Insights after Lambda processed bad payloads is detective, not preventive—and still incurs invoke cost. Disabling API Gateway and exposing a Lambda function URL without checks removes the managed validation and throttling layer the stem implies you should use. A nightly batch that deletes invalid grants after storage accepts garbage into systems of record and creates cleanup risk around partial PII.
Exam caveat: Gateway validation covers schema/shape constraints; deeper business rules (duplicate grant IDs, eligibility) still belong in the application. Do not assume mapping templates replace authN/authZ.
Operational check: define JSON Schema/models for required fields and ZIP format; return clear 400s at Gateway; confirm Lambda metrics show fewer junk invokes; keep unit tests for business validation; and document which checks are edge versus domain so future fields land in the right layer.