A parks department wants small event-driven handlers that run only when invoked, without managing worker shapes or patching guest OS. Which OCI approach matches that model?

When a parks department wants small event-driven handlers that run only when invoked, without managing worker shapes or patching guest OS, OCI Functions is the matching model. You deploy a small code unit; the service provisions execution capacity on demand, runs the handler, and billing follows what executed. Operators do not size Compute shapes, patch a guest OS fleet, or keep idle workers warm merely so the handler exists—ideal for sporadic civic event hooks.

Provisioning a fixed pool of Compute instances and keeping them warm for every handler fails by concept because that is always-on infrastructure management, including patching and capacity planning, which the parks team explicitly wants to avoid. Creating an OKE Deployment with a minimum of three always-on replicas per handler fails because Kubernetes Deployments keep processes running continuously; you still operate a cluster and pay for idle replicas. Placing each handler on a dedicated Bare Metal host sized for peak load fails as extreme over-provisioning and operational burden for tiny event-driven units.

Exam caveat: Functions still need an application (subnets, config), IAM policies, and an image in OCIR—serverless removes shape babysitting, not identity or networking setup. Operational check: deploy a hello handler to a Functions application, invoke it once, confirm no dedicated Compute instance was created for that invoke, and review that idle time does not require a warm municipal VM pool.