A goldenrod-bank org has App Service, Functions, and a partner HTTPS API to expose. How should they structure API Management?
Select an answer to reveal the explanation.
Short Explanation
One APIM instance is a shared gateway—App Service, Functions, and the partner API can all be separate APIs on the same instance.
Full Explanation
A single API Management instance is a shared gateway and control plane. The goldenrod-bank org should publish App Service, Functions, and the partner HTTPS API as multiple APIs (and products as needed) on one instance rather than spinning up one APIM instance per backend. That keeps subscriptions, policies, products, certificates, and the developer portal centralized and far cheaper to operate for a typical city API program.
One instance per backend multiplies cost, certificate renewal, portal sprawl, and operational overhead without a hard requirement to isolate gateways. Using only Front Door and never creating APIs inside APIM skips the product, policy, and developer-portal surface the team needs for an API program. Hosting each OpenAPI file in Blob Storage documents contracts for humans but does not provide a managed gateway, throttling, or subscription keys.
Exam caveat: “multiple backends” does not mean “multiple APIM instances”—APIs are the unit of packaging inside one service unless isolation, tenancy, or compliance rules explicitly force separate gateways.
Operational check: on one APIM instance, add three APIs pointed at the three backends, place them in appropriate products, publish those products, and verify the developer portal lists the App Service, Functions, and partner APIs together under the goldenrod-bank program.