A reverse-proxy sidecar must read a TLS certificate and key as files under /certs. Which consumption pattern fits?
Select an answer to reveal the explanation.
Short Explanation
TLS material likes being files on disk, not one giant env string. Mount the Secret as a volume and the keys show up as files under /certs. That's the usual pattern for cert and key paths.
Full Explanation
A reverse-proxy sidecar that must read a TLS certificate and key as files under /certs should mount the TLS Secret as a volume so each Secret key appears as a file in /certs. Volume projection of kubernetes.crt and tls.key is the natural fit for proxies and ingress sidecars in municipal edge Pods that expect filesystem paths.
Exporting certificate material only as ConfigMap keys named tls.crt and tls.key misuses ConfigMaps for private key material. Passing both PEM blobs through a single environment variable separated by commas is brittle, size-limited in practice, and awkward for file-oriented servers. Storing the key pair in Pod annotations and copying them with a postStart mkdir hook is insecure and nonstandard compared with a Secret volume mount.
Exam caveat: default mode on Secret volumes is relatively restrictive, but still treat node access carefully; prefer TLS Secret type for cert pairs. Operational check: create the TLS Secret, mount it at /certs, exec ls /certs, confirm tls.crt and tls.key exist, and validate the sidecar serves HTTPS. In CKAD scenarios involving q213, prefer verifying the live object with kubectl get and describe before changing cluster-wide settings. Keep municipal change tickets linked to the exact manifest diff so operators can audit why q213 was adjusted.