A city’s open-data single-page app in the browser must call an OCI API Gateway deployment. Developers need the gateway to answer CORS preflight and attach the configured CORS headers on actual responses. How should CORS be implemented?
Select an answer to reveal the explanation.
Short Explanation
Browsers ask permission before a page on one origin may call another—CORS is that permission slip. On OCI API Gateway you attach a CORS request policy (globally or per route) so the gateway answers preflight and stamps the headers you configure. It is not a Function you write and not an OKE Ingress annotation drill.
Full Explanation
Browser-based single-page apps calling a different origin must satisfy CORS. On OCI API Gateway, CORS is implemented as a request policy on the deployment or on selected routes. You configure allowed origins, methods, headers, credentials, and max-age. The gateway answers preflight (OPTIONS) and attaches the configured CORS headers on actual responses so the city’s open-data SPA can call the deployment safely from the browser. That keeps cross-origin policy centralized with the rest of the API’s edge configuration instead of burying it in every back end.
Writing a Function solely to invent Access-Control headers and registering it as the only back end misplaces CORS into application code and prevents normal route back ends from serving the API. Adding Ingress annotations on an OKE Service and pointing the SPA at a cluster IP abandons the gateway path the question asks about and is an OKE concern, not API Gateway CORS. Relying on a usage-plan client token alone fails because metering tokens do not satisfy browser same-origin rules or emit CORS headers.
Exam caveat: CORS is not authentication. Even with a correct CORS policy, the deployment still needs a separate authentication and authorization story for the open-data API.
Operational check: from the SPA’s origin, confirm preflight returns the configured allow headers, a real GET or POST includes those headers, and a disallowed origin is rejected—then verify authenticated routes still enforce their auth policy independently of CORS.