A compost-lab Azure Functions app was created without a linked storage account, and triggers never coordinate correctly. Which required application setting must the developer supply for host internal state?
Select an answer to reveal the explanation.
Short Explanation
The Functions host keeps its choreography notes in storage—leases, triggers, internal state. AzureWebJobsStorage is that required mailbox. Without it, the compost-lab app cannot keep triggers in sync. This is host plumbing, not a Queue messaging design essay.
Full Explanation
The compost-lab Azure Functions app was created without a linked storage account, and triggers never coordinate correctly because the host lacks its required internal storage. Supply AzureWebJobsStorage pointing at a general-purpose storage account the Functions host can use. That setting backs host operations such as timer leases, trigger coordination, and other internal state. Without a reachable AzureWebJobsStorage value, reliable trigger behavior breaks even if your function code looks correct.
Setting WEBSITE_RUN_FROM_PACKAGE to a random GUID with no storage backend does not provide host coordination storage; run-from-package concerns how content is mounted for deployment, not trigger leases. Leaving FUNCTIONS_WORKER_RUNTIME blank so the host “auto-detects every language” breaks language worker selection and still does not replace AzureWebJobsStorage. Replacing AzureWebJobsDashboard with a Cosmos DB connection as the only storage confuses optional legacy dashboard settings and application data stores with the mandatory host storage account contract.
Exam caveat: AzureWebJobsStorage is host plumbing—treat it as function-app configuration, not as your Domain 5 messaging architecture just because it uses a storage account. Operational check: set AzureWebJobsStorage to a valid connection string or identity-based reference, restart the function app, and confirm previously failing triggers (for example timer or queue coordination) begin executing consistently.