A cluster runs two Ingress controllers. The developer must ensure the civic Ingress is handled by the controller associated with class nginx. Which field selects that controller?
Select an answer to reveal the explanation.
Short Explanation
When two postal carriers work the same city, you stamp which one delivers. ingressClassName points the Ingress at the IngressClass for that controller. Putting the app in the controller’s namespace is not how class selection works.
Full Explanation
When a cluster runs two Ingress controllers, ensuring a civic Ingress is handled by the controller associated with class nginx is done by setting spec.ingressClassName to nginx (matching the desired IngressClass). ingressClassName binds an Ingress object to a particular controller implementation via the IngressClass resource. In multi-controller municipal clusters, set this field explicitly so the wrong controller does not ignore or mishandle the object.
spec.serviceName on the Ingress set to nginx is not the class selection field. Forcing metadata.namespace to ingress-nginx regardless of where the app lives places the Ingress in the controller namespace and is the wrong ownership model for app-scoped Ingresses. spec.defaultBackend.service.name set to the controller Pod name does not select which controller implements the Ingress rules.
Exam caveat: older annotation kubernetes.io/ingress.class appears in legacy material—prefer ingressClassName on modern exams and clusters. Operational check: kubectl get ingressclass; set ingressClassName: nginx on the civic Ingress; confirm the nginx controller picks up the object (logs/status) and that ADDRESS populates as expected. Standardize ingressClassName in city templates so application teams never omit the field in shared clusters.