A credit-union .NET Azure Function must run so the host and the app do not share one process. Which create/configure choice should the developer select?
Select an answer to reveal the explanation.
Short Explanation
Isolated worker means the .NET app lives in its own process—host in one room, app in another. That is the create-time choice for current .NET isolates. Durable hubs orchestrate workflows; they are not a substitute for picking isolated versus in-process.
Full Explanation
The credit-union .NET Azure Function must run so the host and the app do not share one process. Select the isolated worker model at create/configure time so function code runs out-of-process from the Functions host. Isolated worker enables current .NET versions, clearer dependency isolation, and the process boundary the requirement states. In-process shares the host process; isolated deliberately separates them.
Choosing the in-process worker model exclusively, sharing the host process forever, is the opposite of the stated requirement and follows the older model Microsoft has been moving away from for new .NET work. Selecting a Durable Functions task hub instead of choosing any worker model confuses orchestration storage/configuration with the worker process model—Durable can run on either model but does not itself create out-of-process isolation. Renaming Logic Apps Standard workflows as Functions for process isolation is a category error; Logic Apps is a different product and renaming does not yield a .NET isolated Functions worker.
Exam caveat: isolated and in-process differ in startup, middleware, and binding registration patterns—templates and packages must match the model you selected. Operational check: create or migrate the credit-union app as .NET isolated, confirm the worker process model in project/settings, deploy, and verify function execution occurs in the isolated worker process rather than in-process host sharing.