A city permits microservice must be reachable by other in-cluster clients only, not published on node or cloud load-balancer fronts. Which Service type fits?
Select an answer to reveal the explanation.
Short Explanation
ClusterIP is the internal desk phone number—great for coworkers in the building, not listed in the public directory. Other Pods dial the Service DNS; you don’t get a node port or cloud LB unless you ask for those types.
Full Explanation
When a city permits microservice must be reachable by other in-cluster clients only—not published on node ports or cloud load-balancer fronts—ClusterIP is the correct Service type. ClusterIP allocates a virtual IP reachable inside the cluster and registers DNS for in-cluster callers, without opening a NodePort on every node or requesting an external load balancer. It is the internal desk phone number: great for coworkers in the building, not listed in the public directory. Other Pods dial the Service DNS name; citizens on the internet do not get a direct front door from this object alone.
NodePort publishes the Service on each node’s IP at a high port, which is exactly the broader exposure the requirement wants to avoid for an internal permits API. ExternalName creates a DNS CNAME-style alias to an external hostname rather than providing an in-cluster ClusterIP proxy to Pods. LoadBalancer asks the cloud provider to provision an external address, which publishes the service beyond the cluster by design.
Exam caveat: ClusterIP is the default Service type when type is omitted; still be explicit in YAML for clarity on exams. ClusterIP alone is not encryption or authentication—pair with NetworkPolicy and app auth as needed. Operational check: kubectl get svc and confirm TYPE is ClusterIP with no NODEPORT; from a debug Pod, curl http://permits-api.<ns>.svc.cluster.local:<port> successfully; from outside the cluster without Ingress/NodePort/LB, confirm the API is not directly reachable. Record the internal-only choice in the municipal architecture notes.