An internal embedding service on AKS must accept calls only from approved municipal namespaces. Which control should the platform team apply?
Select an answer to reveal the explanation.
Short Explanation
NetworkPolicy is the badge reader on the embedding service hallway—only approved municipal namespaces get through, not a public front door with no locks.
Full Explanation
A Kubernetes NetworkPolicy on AKS restricts east-west traffic so only approved municipal namespaces can call the internal embedding service. That control enforces namespace boundaries at the network level, reducing accidental exposure and lateral movement inside the cluster. For an internal embedding API that must not be cluster-wide or Internet-open, NetworkPolicy is the appropriate platform control among the options.
Exposing the embedding service on a public LoadBalancer with no network restrictions fails by concept because it publishes an internal service externally without least privilege. Granting every pod hostNetwork access fails because hostNetwork bypasses normal pod network isolation and widens blast radius rather than limiting callers. Disabling the CNI plugin fails because CNI is required for cluster networking; removing it does not create a safe allow-list of namespaces and breaks foundational connectivity.
Exam caveat: NetworkPolicy requires a supporting CNI/policy engine (for example Azure network policies or an equivalent). Policies are deny/allow rules for pod traffic—DNS and system namespaces often need careful exceptions. NetworkPolicy complements but does not replace authentication on the embedding API itself.
Operational check: Apply a NetworkPolicy that allows ingress to the embedding service only from approved namespaces, test allowed clients succeed, test pods in other namespaces time out or are denied, and confirm no public LoadBalancer was attached. Review policy in CI for municipal cluster changes.