The tugboat-scheduler AKS API server is on a public IP and appears on Internet scanners. How should the security engineer isolate the control plane?
Select an answer to reveal the explanation.
Short Explanation
If scanners can see the tugboat API server, it’s still on the public pier. Flip the cluster to private so the control plane lives on a private link inside the VNet—no public API IP.
Full Explanation
An AKS private cluster removes the public endpoint from the tugboat-scheduler API server so the control plane is reached over a private connection from the virtual network (private link/private DNS patterns as designed for private clusters). Internet scanners then no longer see a public API IP, which is the isolation goal when the API currently appears on public reconnaissance.
Attaching only a node NSG that denies inbound traffic while leaving the API server public fails by concept: node NSGs do not privatize the managed control-plane endpoint that scanners hit. Publishing the API through a custom Private Link service that the cluster “authors as a load-balancer product for every consumer” misstates how AKS private clusters work—you enable the private cluster feature rather than hand-building a generic PLS product for kubectl. Keeping the API public and only using Bastion on a jump VM fails because the API FQDN/IP remains Internet-reachable; Bastion helps manage VMs, it does not privatize the AKS control plane by itself.
Exam caveat: private clusters change how operators reach kubectl (VPN, ExpressRoute, peered hub jump box, or similar private path)—plan connectivity before flipping private. Operational check: after enabling private cluster, confirm there is no public API server IP, resolve the private FQDN from inside the VNet, and verify kubectl works only from the private path.