Plan and manage an Azure AI solution 1.3 Manage, monitor, and secure AI systems
Security policy requires that a Foundry resource is unreachable from the public internet…
Study guide skill: Configure security, including managed identity, private networking, keyless credentials, and role policies
Question B1-008
Security policy requires that a Foundry resource is unreachable from the public internet, while applications in a peered virtual network can still use it. What should you configure?
Select one answer.
Answer: D
Inbound isolation for Foundry uses the public network access (PNA) setting plus Private Link. Setting PNA to Disabled with a private endpoint forces private access from the virtual network, and private DNS zones resolve the endpoint. API keys, NSGs on the resource, or customer-managed keys don't remove public reachability.
Deep dive
How it works
Foundry splits network isolation into inbound access (who can reach the resource) and outbound access (what the resource and its agents can reach). This question is about inbound access, which you control with the public network access (PNA) flag. That setting determines whether your project requires a private endpoint for access.
For inbound isolation, the docs give two choices: set public network access to Disabled with a private endpoint (private link) enabled, or set it to Selected networks to allow specific IP addresses and virtual networks. To make the resource unreachable from the public internet while still serving a virtual network, you choose Disabled and add a private endpoint:
- On the resource's Networking tab, select Disabled for public access.
- Select + Add private endpoint, pick the same region as your virtual network, and choose the virtual network and subnet.
- Configure DNS so names resolve to the private endpoint.
The DNS step matters. Clients that use the private endpoint keep the same connection string as clients of the public endpoint, and DNS resolution routes their connections over the private link. If your network uses a custom DNS server, clients must be able to resolve the resource's fully qualified domain name to the private endpoint IP address. To validate, resolve the Foundry endpoint from a VM connected to the virtual network and confirm it returns the private endpoint's IP address.
The other options, and when you'd use them
- Keep public network access Enabled and require API keys: The PNA flag, not the authentication method, decides whether a private endpoint is required. Keys authenticate callers, but with PNA still enabled the resource stays reachable over its public endpoint, which the policy forbids.
- Add a network security group to the Foundry resource: A network security group filters traffic between Azure resources in Azure virtual networks. It doesn't change the Foundry resource's public network access setting, so it can't take the resource off the internet.
- Enable customer-managed keys: CMK encryption applies to data at rest in the resource's associated storage accounts. It's about encryption, not network reachability.
Exam tip
"Unreachable from the internet but usable from a VNet" means PNA Disabled plus a private endpoint and private DNS. "Allow a few known IPs" means Selected networks.
References
Last reviewed: