A county database password must be supplied to Pods as mounted files rather than plain ConfigMap data. Which Kubernetes object type is intended for that confidential material?
Select an answer to reveal the explanation.
Short Explanation
Treat passwords like sealed envelopes, not sticky notes on the fridge. Secrets are the envelope object—still base64 in etcd by default, but the right type versus a ConfigMap.
Full Explanation
A county database password that must be supplied to Pods as mounted files rather than plain ConfigMap data belongs in a Secret. Secrets are the Kubernetes API object type intended for confidential material such as passwords, tokens, and TLS keys. Although etcd stores Secret data base64-encoded by default (not strong encryption by itself), the Secret object is still the correct configuration type for mounting credentials as files into municipal database client Pods, keeping passwords out of ConfigMaps and out of container image layers.
LimitRange only constrains default and min/max resource requests and limits in a Namespace; it does not store confidential database passwords. ResourceQuota only caps aggregate Namespace resource usage; it is unrelated to credential injection. A PodDisruptionBudget only limits voluntary disruptions of Pod sets during drains and evictions; it is not a secret store.
Exam caveat: prefer volume-mounted Secrets for files, avoid committing Secret YAML with live credentials to public git, and remember RBAC still controls who can read Secret objects. Operational check: create the Secret, mount it as a volume on the Pod/Deployment, confirm files appear at the expected path inside the container, and verify the county database connection works without ConfigMap plaintext passwords.