A civic tech team wants to iterate on a function on a workstation and later deploy the same unit to OCI Functions with one toolchain. What workflow does OCI document?
Select an answer to reveal the explanation.
Short Explanation
Practice in the garage, then drive the same car onto the highway: local Fn init/invoke, then switch the CLI context to OCI for deploy. One toolchain, two stages.
Full Explanation
The documented civic-tech workflow for iterating on a function is to install Fn Project locally to initialize and invoke, then point the same CLI at an OCI context to deploy. Local Fn gives fast feedback on the handler unit; the Oracle provider context retargets build, push, and register steps at OCI Functions and OCIR. One toolchain, two stages—garage practice then highway deploy—without rewriting the unit for a different framework.
Rewriting the handler in Terraform locals before any OCI deploy is allowed fails by concept because Terraform may manage surrounding infrastructure, but it is not the required packaging path that replaces Fn init/invoke for the function unit itself. Building only on OKE nodes with a claim that local Fn installs are unsupported fails because OCI documents local Fn development as a first-class path into Functions. Using Docker Compose exclusively and claiming the fn CLI cannot target OCI fails because the CLI with an Oracle context is exactly how deploy to OCI Functions is documented.
Exam caveat: local success does not guarantee OCI success—memory, timeout, IAM, subnet gateways, and registry auth must still be correct in the OCI context. Operational check: fn init and invoke locally, create/select an OCI context with compartment and registry prefix, fn deploy --app …, then fn invoke against the cloud application for the same civic handler.