An Ingress in namespace permits references backend Service permit-ui, but that Service only exists in namespace libraries. Typical CKAD-style Ingress backends fail. What should the developer do?
Select an answer to reveal the explanation.
Short Explanation
Ordinary Ingress backends look next door in the same namespace. If permit-ui lives in libraries, move the Ingress there too—or use an explicit platform feature for cross-namespace, not a made-up ClusterIngress kind.
Full Explanation
Typical CKAD-style Ingress backends reference Services in the same namespace as the Ingress. If an Ingress in namespace permits references backend Service permit-ui, but that Service only exists in namespace libraries, the backend lookup fails under ordinary Ingress semantics. The developer should colocate the Ingress with the backend Service in the same namespace (or use a supported cross-namespace mechanism if the platform explicitly provides one). Ordinary serviceName references are same-namespace.
Renaming the Ingress kind to ClusterIngress is not a standard core Kubernetes fix for cross-namespace backends. Setting hostNetwork: true on the Ingress object does not cross namespaces for Service resolution. Storing the remote Service YAML inside a Secret and mounting it on the controller only does not create a portable cross-namespace backend reference for application developers on CKAD tasks.
Exam caveat: keep Ingress, Service, and Deployment together in the app namespace unless Gateway API or platform-specific cross-namespace features are documented. Operational check: move or recreate the Ingress in libraries, or create permit-ui in permits; verify with kubectl get svc in the Ingress namespace; retest routing. City GitOps layouts should colocate Ingress+Service+Deployment per application namespace to avoid this failure mode.