On a cloud Kubernetes cluster, a public parks website should get a provider-provisioned external address in front of its Service. Which type requests that?
Select an answer to reveal the explanation.
Short Explanation
LoadBalancer is the “please give me a cloud front door” Service type. On a supported provider, the cloud controller hangs an external LB (and usually an address) on that Service. ClusterIP and headless won’t summon that managed front end by themselves.
Full Explanation
On a cloud Kubernetes cluster, a public parks website that should get a provider-provisioned external address in front of its Service needs type LoadBalancer. LoadBalancer is the “please give me a cloud front door” Service type. On a supported provider, the cloud controller reconciles the Service and provisions an external load balancer (and usually an address) for that Service, which is what public parks traffic needs at the Kubernetes Service layer.
ClusterIP with an annotation does not always allocate a public DNS CNAME by itself in a portable way—ClusterIP remains internal. A headless Service does not cause the cloud controller to publish a global anycast IP for ordinary HTTP apps. NodePort without cloud integration publishes high ports on nodes but does not automatically create a managed cloud load balancer the way LoadBalancer does.
Exam caveat: LoadBalancer behavior is provider-specific; in bare-metal labs it may pend without MetalLB or equivalent. Operational check: kubectl get svc parks-web -w and wait for EXTERNAL-IP; curl the address on the Service port; confirm TYPE is LoadBalancer. For production municipal sites, teams often still place an Ingress/controller or edge proxy in front for host-based HTTP routing and TLS—but when the question asks which Service type requests a provider LB, the answer is LoadBalancer.