A water-utility team needs every Oracle Function in one application to read the same Object Storage bucket name without rebuilding images when the name changes. Where should that value live?
Select an answer to reveal the explanation.
Short Explanation
Treat config like a sticky note on the office door, not paint mixed into the wall. Application or function key-value config arrives as environment variables so bucket names and connect strings change without a new image build.
Full Explanation
Shared operational values such as an Object Storage bucket name belong in Oracle Functions custom configuration: key-value pairs on the application (or on an individual function). Those values are delivered to the runtime as environment variables so the water-utility handlers read one source of truth. Application-level config covers every function in the app; keep the combined configuration size within the documented 4 KB limit.
Hardcoding the bucket name inside the Docker image forces a rebuild and redeploy for every environment rename, which breaks the “change without rebuild” requirement. Baking the value only as a Dockerfile ENV at build time has the same rigidity. Kubernetes ConfigMaps attached to a Functions control plane are not how OCI Functions exposes configuration to handlers—do not import OKE config primitives as if they were Functions settings.
Exam caveat: application and function configuration share the same size budget; oversized secrets or many keys can exhaust the 4 KB ceiling. Operational check: set the bucket name as application config, redeploy or refresh so handlers see the environment variable, change the value in the console or CLI without rebuilding the image, and confirm each function in the application resolves the new bucket on the next invoke.