A building-department API receives incomplete permit payloads that waste Function invocations. The team wants malformed requests rejected at the front door before any back end runs. Which API Gateway feature fits?
Select an answer to reveal the explanation.
Short Explanation
Validating at the gateway is like a clerk rejecting an incomplete permit form before it reaches the plan-reviewer—saving everyone’s time. A request validation policy checks schema and required parameters and fails junk at the front door instead of invoking a Function or HTTP back end. Validation shields the back end; it is not a substitute for proper testing.
Full Explanation
Incomplete permit payloads that still invoke Functions waste time and money. OCI API Gateway’s request validation policy checks required parameters and schema rules at the edge and fails malformed requests before any HTTP or Functions back end runs. For a building-department API, that is the clerk rejecting an incomplete form before plan review: junk never reaches the reviewer. Validation belongs with other request policies so the front door enforces the contract consistently.
Increasing Function timeout so invalid payloads fail more slowly inside the back end increases cost and latency without preventing the invocation. Publishing only as an OCI Queue and hoping producers self-validate moves the problem off the gateway and does not give the synchronous API a front-door schema check. Monitoring alarms on 5xx counts detect symptoms after failures; they do not validate requests or stop bad payloads from executing.
Exam caveat: gateway validation shields the back end from structural mistakes; it is not a substitute for thorough functional testing of permit business rules that only the back end can evaluate.
Operational check: submit a deliberately incomplete permit payload and a schema-valid one; confirm the invalid call is rejected at the gateway with no Function invocation metrics, while the valid call reaches the back end.