A civic portal Ingress must terminate HTTPS for host portal.city.example using an existing TLS certificate stored in the cluster. Where should the Ingress reference that material?
Select an answer to reveal the explanation.
Short Explanation
HTTPS on Ingress needs a named envelope for cert and key. The Ingress tls block lists the host and the Secret that stores those files. Stuffing certs into Service externalIPs or securityContext fields is the wrong shelf.
Full Explanation
A civic portal Ingress that must terminate HTTPS for host portal.city.example using an existing TLS certificate stored in the cluster should reference that material in the Ingress tls section, listing the host and the Secret name that holds the TLS certificate and key. Controllers read Ingress tls to load the Secret and serve HTTPS for the named host. That is the portable CKAD-level place to wire certificate material to hostname termination.
Pointing a Pod securityContext readOnlyRootFilesystem field at certificate files does not configure Ingress TLS. Putting base64 cert and key strings in Service externalIPs is invalid and unrelated. An annotation that sets kube-proxy mode to https without a Secret does not terminate Ingress TLS for the portal host.
Exam caveat: the TLS Secret is usually type kubernetes and must exist in the same namespace as the Ingress for typical controllers. Operational check: kubectl get secret <tls-secret> -n <ns>; set Ingress spec.tls with hosts and secretName; curl https://portal.city.example against the controller and verify the certificate; kubectl describe ingress for TLS section errors. Rotate Secrets under city PKI procedures without renaming hosts casually.