A transit agency needs a long-running HTTP fare API with custom sidecars and readiness probes, plus a worker that keeps a Streaming cursor open. Where should those processes run?
Select an answer to reveal the explanation.
Short Explanation
A desk that must stay staffed all day with extra tools on the side belongs in the always-open OKE shop. Functions can be called from that world; they do not replace a long-running Deployment.
Full Explanation
Long-running HTTP fare APIs that need custom sidecars and readiness probes, plus workers that keep a Streaming cursor open, belong on OKE. Kubernetes Deployments support always-on listeners, probe-driven readiness, sidecar patterns, and durable consumer loops. Oracle Functions are complementary targets you may call from that world; they are not a drop-in replacement Deployment for continuous HTTP services or cursor-holding consumers.
Running everything only as Oracle Functions with maximum timeout still cannot recreate custom sidecars, Kubernetes readiness semantics, or indefinite cursor ownership—timeout merely bounds a single invoke. Stock-response routes on API Gateway return fixed gateway content and provide no compute back end for a real fare API. Fn Project HTTP triggers declared in func.yaml are not how OCI Functions exposes HTTP on Oracle Cloud; API Gateway or signed invoke are the OCI paths.
Exam caveat: choose compute by lifecycle—short event work on Functions, always-on and sidecar-rich services on OKE. Operational check: deploy the fare API as an OKE Deployment with probes and sidecars, run the Streaming consumer as a long-lived workload, optionally front the API with API Gateway HTTP back ends, and reserve Functions for short transit helpers rather than forcing them to replace the Deployment.