A maple-coop intern created eight separate Function apps for eight tiny related HTTP routes and now manages eight hosting identities. What should the developer recommend instead?
Select an answer to reveal the explanation.
Short Explanation
A function app is the apartment building; each function is a doorbell. Related maple-coop routes belong in one app with eight functions—not eight entire apps and eight bills. One trigger per function still holds.
Full Explanation
The maple-coop intern created eight Function apps for eight tiny related HTTP routes, multiplying hosting identities and settings. Related functions should live in one function app, with each function as its own triggered entry point. A function app is the hosting unit that shares runtime, application settings, and identity; each function remains a separate executable with exactly one trigger. Consolidating related HTTP routes into one app cuts operational overhead while preserving clear function boundaries.
Keeping one Function app per HTTP route forever for “strongest isolation” over-isolates tiny related endpoints and creates eight identities, eight setting surfaces, and eight deploy pipelines without exam-relevant benefit. Moving every route into a single Azure Logic App workflow instead of Functions abandons the Functions configure skill for a different product. Replacing all HTTP functions with AKS pods behind one Ingress controller escalates to Kubernetes operations outside the AZ-204 Functions hosting answer for this scenario.
Exam caveat: one trigger per function still applies inside a shared app—do not merge eight unrelated triggers into one function just to reduce app count. Operational check: create or refactor to a single function app with eight HTTP-triggered functions, confirm one shared host identity/settings set, and verify each route invokes only its own function.