An Ingress must terminate HTTPS for permits.example.gov using certificate files you already have. Which Secret approach fits Ingress TLS?
Select an answer to reveal the explanation.
Short Explanation
Ingress HTTPS wants a proper TLS Secret—cert and key as tls.crt and tls.key. Point spec.tls at that Secret for the host. Username/password Opaque Secrets and ConfigMaps aren't the Ingress TLS handshake material.
Full Explanation
An Ingress that must terminate HTTPS for permits.example.gov using certificate files you already have should use a TLS Secret (kubernetes.io/tls) with tls.crt and tls.key, then reference that Secret from the Ingress spec.tls section. That is the standard contract between municipal Ingress controllers and Kubernetes TLS Secrets for hostname termination.
Creating an Opaque Secret with keys username and password and attaching it under spec.tls fails the TLS Secret key contract. Storing the certificate only in a ConfigMap named tls and referencing it from imagePullSecrets confuses pull credentials, ConfigMaps, and Ingress TLS. Putting PEM files in annotations on the Ingress and claiming controllers always prefer annotations over Secrets is nonstandard and insecure compared with a TLS Secret reference.
Exam caveat: the Secret must be in the same namespace as the Ingress, and the certificate must match the hosts listed under spec.tls. Operational check: kubectl create secret tls ..., reference it in Ingress spec.tls for permits.example.gov, apply, and verify HTTPS handshake against the civic hostname. In CKAD scenarios involving q219, prefer verifying the live object with kubectl get and describe before changing cluster-wide settings.