An internet-facing Amazon API Gateway stage must not remain open to anonymous callers. Which approach best secures application access at the API layer?
Select an answer to reveal the explanation.
Short Explanation
An open API stage is a front door with no lock. Cognito authorizers or IAM auth on API Gateway make callers prove who they are before methods run. Polite User-Agents, weekly URL billboards, or turning off HTTPS are not authorization.
Full Explanation
An internet-facing Amazon API Gateway stage must not remain open to anonymous callers; require Amazon Cognito authorizers or AWS IAM authentication on methods or stages instead of leaving authorization set to NONE. Authenticating callers at the API layer protects municipal backend integrations from unauthenticated internet invocation and pairs cleanly with citizen Cognito pools or signed IAM/SigV4 clients for partner systems.
Setting authorization to NONE and relying on a polite User-Agent fails because clients control headers and bots ignore etiquette. Publishing the invoke URL on a billboard and rotating it weekly fails conceptually: URL obscurity is not authentication, and leaked or guessed URLs remain callable. Disabling HTTPS on the custom domain so tokens “cannot be intercepted inside TLS” fails because clearing TLS exposes tokens and citizen data on the wire and does not authorize callers.
Exam caveat: method-level NONE on even one sensitive route can undermine an otherwise locked stage; also distinguish resource policies (who can invoke the API network-wise) from authorizers (who the caller is). Operational check: set Cognito or IAM authorizers on all public methods, attempt anonymous invokes and confirm 401/403, verify legitimate citizen or partner tokens succeed, and monitor 4XX spikes for probing.