A county security review for a Foundry-based permitting assistant requires AI traffic to stay off the public internet between Azure resources. Which design choice should the platform team include?
Select an answer to reveal the explanation.
Short Explanation
Service endpoints still leave Foundry on a public address, so they won't keep your AI traffic off the public internet the way you'll need. The county wants Foundry and its buddy services reachable only over that private path, not the public internet. Wire private endpoints and private networking into the design up front so civic AI traffic stays inside the trusted Azure fabric.
Full Explanation
Private endpoints place Microsoft Foundry and related Azure AI PaaS resources on private IP addresses inside the county’s virtual network so permitting-assistant traffic never needs a public data path between Azure services. The design works because clients resolve and reach those endpoints over private networking and private DNS, which directly satisfies a security review that requires AI traffic to stay off the public internet while still allowing approved municipal workloads to call models, search, and supporting services. Network segmentation, NSGs, and identity controls remain complementary, but private endpoints are the architectural control that removes public exposure of the Foundry plane for civic permitting data.
Enabling service endpoints on the Foundry and related Azure AI resources fails by concept because service endpoints extend VNet identity to the service but leave the resources on public IP addresses with a publicly reachable endpoint; they do not place Foundry on private IPs inside the county’s virtual network, so AI traffic does not get the private-only path the review requires. Placing private endpoints on the Foundry SDK cache and evaluation reports fails by scope because it privatizes the wrong resources; the SDK cache is client-side content and evaluation reports are stored artifacts, not the live Foundry and related Azure AI endpoints, so permitting-assistant AI traffic can still cross the public internet. Peering the application VNet with the Foundry managed VNet and routing AI traffic over the private peering link fails because the Foundry managed VNet is Microsoft-managed and is not a customer-peered path for private PaaS access; without private endpoints and private DNS for the Foundry and related Azure AI resources, those AI endpoints remain publicly reachable and AI traffic can still cross the public internet.
Exam caveat: private endpoints alone are insufficient if public network access remains enabled, private DNS is misconfigured, or jump hosts and CI runners still call the public endpoint by habit. Operational check: confirm private endpoint approval state, private DNS zones for the AI resource types, denied public network access where required, and a smoke test that the permitting assistant reaches Foundry only from the designated VNet path with no successful public-route fallback.
Prefer to study offline? Printable PDF study book + test engine ($7.50, unofficial). These questions stay free here.