A contractor tries to add API server authorized IP ranges to an AKS cluster that is already private. What should the security engineer explain?
Select an answer to reveal the explanation.
Short Explanation
Private cluster or authorized IP ranges—pick a lane. Stacking authorized ranges on an already-private API server isn’t a thing; those ranges only fence a public control plane.
Full Explanation
API server authorized IP ranges apply to a public AKS API server. They cannot be stacked onto a cluster that is already private as a second “public IP filter on Private Link clients.” The security engineer explains that the canal team must choose one isolation model: private cluster (no public API endpoint) or public API with authorized IP ranges—not both as layered duplicates of the same idea.
Claiming authorized ranges must always be layered on private clusters to filter Private Link clients by public IP fails by concept: private-cluster clients are not gated that way, and the features are mutually exclusive in normal AKS design. Saying private clusters ignore authorized ranges at create time but silently enable them after a node-image upgrade invents behavior that is not the exam model. Saying authorized ranges replace private clusters and should be added before disabling the public FQDN reverses the decision: authorized ranges assume a public API; disabling the public endpoint is the private-cluster path.
Exam caveat: if the requirement is “no public API IP at all,” choose private cluster; if the requirement is “public FQDN but only from known CIDRs,” choose authorized IP ranges. Operational check: for a private cluster, attempt to set authorized IP ranges and confirm the portal/CLI rejects or documents incompatibility; document which isolation model the tugboat cluster actually uses.