A compost-yard Function’s queue binding currently embeds the storage account key directly in function.json. What change correctly supplies the connection?

Function bindings resolve storage credentials through application settings. For a compost-yard queue binding, set the binding’s connection property to the name of an app setting—commonly AzureWebJobsStorage or a custom setting—whose value is the storage connection string or identity-backed connection configuration. The binding metadata then references the setting name rather than embedding secrets in function.json or attributes, which is the supported and secure connection model on AZ-204.

Pasting the account key into the binding’s queueName property fails conceptually: queueName identifies the queue, not the credential store, so secrets remain misplaced and the connection model is unused. Moving the key into the HTTP route template so callers supply it exposes credentials to every caller and confuses routing with authentication. Committing the key to a public GitHub gist and referencing that URL maximizes exposure and still does not satisfy how Functions bindings resolve connections at runtime.

Exam caveat: the connection property must be the setting name, not the raw connection string itself; pasting the full string into connection often breaks resolution and still risks secret leakage in deployment artifacts. Operational check: remove any key from function.json, set AzureWebJobsStorage (or your custom setting) in the Function app configuration, restart or refresh settings, enqueue a test message, and confirm the function processes it while Key Vault or app settings—not source control—hold the secret.