A school district wants TLS for an Ingress hostname using a certificate already in a Kubernetes Secret. Where is that Secret referenced in the classic Ingress API?
Select an answer to reveal the explanation.
Short Explanation
Look at the Ingress TLS block—that is where secretName lives for the cert. Point the hosts there and let the controller terminate TLS with that Secret.
Full Explanation
In the classic Ingress API used by school-district portals, TLS material is referenced from the Ingress spec.tls section via secretName for the listed hosts. Controllers read that block to terminate HTTPS on the shared entrypoint, presenting the certificate in the Secret for matching hostnames. Keeping keys in a kubernetes Secret and wiring them through spec.tls is the standard, supportable pattern for municipal HTTPS at the edge.
The CNI ConfigMap is not a global tls.secretName control plane for Ingress certificates—CNI configures pod networking, not edge TLS. Labels on IngressClass (including fictional keys like kubernetes.io/tls-secret) do not replace the Ingress TLS section. Setting each backend Pod’s hostname field to equal the Secret name does not attach certificates to Ingress listeners or SNI configuration.
Exam caveat: the Secret normally must live in the same namespace as the Ingress, with tls.crt and tls.key data. Hosts listed under spec.tls should align with rule hosts. Without a TLS block, an Ingress remains HTTP-only even if a Secret exists unused elsewhere.
Operational check: create the TLS Secret, add a spec.tls entry with the district hosts and secretName, wait for the Ingress controller to reload, then verify HTTPS with curl or openssl against the published entrypoint and confirm the presented certificate matches.