Transit mounts a TLS key pair into a gateway Pod from cluster-managed confidential data. Which approach matches common CKA practice?
Select an answer to reveal the explanation.
Short Explanation
TLS keys are vault material—Secrets mounted as files hand the gateway the cert and key on disk without baking them into the image. A public ConfigMap is the wrong mailbox for private keys.
Full Explanation
Transit mounting a TLS key pair into a gateway Pod from cluster-managed confidential data should mount a Secret as a volume so certificate and key files appear in the Pod filesystem. That pattern is common CKA practice: store tls.crt/tls.key (or custom keys) in a Secret, volume-mount them into the gateway container, and point the process at those paths. It keeps private key material out of container images and out of public ConfigMaps while fitting the Deployment/Pod volume model used for municipal edge gateways.
Storing the private key only in a public ConfigMap checked into an open Git repo treats confidential material as non-secret configuration and is an anti-pattern. Encoding the key in a Service annotation that kube-proxy turns into TLS files invents a mechanism kube-proxy does not provide for certificate distribution. Putting certificate material exclusively in a PriorityClass name string is nonsensical—PriorityClass only carries scheduling priority metadata.
Exam caveat: Secrets are still readable to authorized API clients and are base64 in etcd by default; production transit platforms often add encryption at rest and external secret stores, but the object type and volume mount remain the exam-relevant pattern. Operational check: create the TLS Secret, mount it on the gateway Pod, confirm files exist with expected modes, and validate TLS handshakes for the transit gateway.