A city radio-archive Function needs a Blob Storage API that the available input binding does not expose. A teammate insists every Blob call must go through a binding. What is the correct guidance?

Azure Functions bindings are optional conveniences that reduce boilerplate when they expose the APIs you need. Official guidance allows developers to create service SDK clients inside a Function when a required Blob Storage capability is missing from the available input or output binding surface. For the city radio-archive scenario, instantiating a Blob SDK client in code is valid and often necessary for advanced operations bindings do not cover, while still keeping the Function host and trigger model.

Claiming bindings are mandatory and that any direct SDK call fails host validation is false: the host does not reject Functions that use SDKs, and many production apps mix bindings with clients. Replacing the Function with an Azure VM that mounts the storage account as a file share abandons the serverless Functions compute model and solves a different operational problem (IaaS file access) rather than clarifying binding policy. Restricting Blob SDK usage to Durable Functions orchestrations invents a rule that does not exist; both regular and Durable Functions may use SDKs when bindings are insufficient.

Exam caveat: even when you use the SDK, prefer managed identity or app settings for credentials—never hard-code account keys in source—and understand that mixing binding-managed and SDK-managed connections can confuse which identity is used. Operational check: confirm the Function app’s identity or connection string can perform the specific Blob API you call (for example list, lease, or set metadata), then exercise that code path in a staging slot and verify Application Insights dependency telemetry shows successful Blob calls without binding misconfiguration errors.