The canal authority wants the AKS API server projected into the cluster virtual network so hub firewall and custom DNS see that traffic, not only a private-link endpoint in a managed network. Which isolation pattern should the security engineer choose?
Select an answer to reveal the explanation.
Short Explanation
They want the API server living in their VNet so the hub firewall and DNS actually see it—that’s API Server VNet Integration, not just “authorized IPs on a public API.”
Full Explanation
API Server VNet Integration is the isolation pattern when the canal authority wants control-plane traffic integrated with the cluster virtual network so hub firewall inspection and custom DNS actually see that path—not merely a private-link endpoint living only in a Microsoft-managed network. That capability projects API-server connectivity into the customer VNet design the hub team already operates.
Using authorized IP ranges on a public API and mirroring them on hub Firewall DNAT fails by concept: authorized ranges still leave a public API model and DNAT mirroring does not equal VNet-integrated control-plane placement. Switching the data plane from Azure CNI to kubenet solely to put the API server in the firewall path confuses pod networking with API-server networking; CNI choice does not implement API Server VNet Integration. Authoring a NetworkPolicy that “redirects API-server packets through an Istio gateway in the hub” fails because NetworkPolicy does not relocate the managed API server into the hub inspection path.
Exam caveat: private cluster and API Server VNet Integration address related but distinct “how does the control plane attach to my network” designs—read the requirement for firewall/DNS visibility in the cluster VNet rather than only “no public IP.” Operational check: after enabling the integration pattern, verify API-server traffic is visible to hub firewall/DNS as designed and that kubectl still succeeds from approved private paths.