A water utility billing portal must call the generative service from its existing web application. Which integration approach fits Foundry?
Select an answer to reveal the explanation.
Short Explanation
The billing portal already talks to city systems—teach it to talk to Foundry the same way, with SDK connectors. That's the clean path for generative calls from a municipal app. You shouldn't invoke the management plane API for each live customer reply; that's for managing resources, not for requesting live completions.
Full Explanation
Integrating Foundry SDK connectors so the billing portal can call the generative service is the integration approach that fits the water utility's existing web application. Municipal portals already authenticate to city backends with managed identities, API management, and key vault secrets; Foundry SDKs and connectors provide the supported pattern to obtain credentials, invoke deployments, and handle request or streaming options from that portal rather than inventing ad hoc HTTP clients or shipping model artifacts to browsers.
Invoking the Foundry management plane API so the billing portal can request live completions uses the control plane as a serving path; the management plane API is designed to create and manage resources, not to answer real-time user questions, so it cannot provide the managed, auditable invocation for live completions that SDK connectors provide. Linking the billing portal to a Foundry model catalog listing so it can generate live responses confuses model discovery with live inference; a catalog listing only describes available models, not a deployed request/response endpoint, so it cannot return timely answers to portal users. Routing billing portal prompts through a Foundry hub workspace so it can produce live answers puts an organizational workspace in place of the generative service itself; a hub workspace organizes projects and assets but is not a serving endpoint and does not provide the authenticated, auditable invocation the portal needs.
Exam caveat: Foundry generative services are consumed from applications via SDK connectors built for live request/response calls—not by repurposing a management plane API call, a model catalog listing, or a hub workspace as the integration path. Operational check: from the billing portal's server-side path, authenticate with the managed identity or vaulted secret, invoke the Foundry SDK connector for each live customer query, and confirm the portal is not instead calling the management plane API for completions, linking to a model catalog listing, or routing through a hub workspace in place of the generative service.
Prefer to study offline? Printable PDF study book + test engine ($7.50, unofficial). These questions stay free here.