ConfigMap vs Secret

WHAT THIS TESTS Understanding the intended separation between ordinary configuration and sensitive material, and the real (limited) security guarantees of Secrets.

A GOOD ANSWER COVERS Both ConfigMaps and Secrets externalize configuration from container images so the same image runs across environments. A ConfigMap is for non-sensitive data: log levels, feature flags, service URLs, and other tunables. A Secret is for sensitive data: database passwords, API tokens, TLS certificates and keys. The practical differences are that Secret values are base64-encoded in the object (which is encoding for binary-safety, not encryption), and that Kubernetes treats Secrets more carefully: you can enable encryption at rest in etcd, restrict access with RBAC, and the kubelet can mount them via tmpfs rather than writing to node disk. The decision rule is simple: if leaking the value would be a security incident, use a Secret; otherwise use a ConfigMap.

COMMON WRONG ANSWERS Claiming base64 makes Secrets encrypted; it is trivially reversible. Storing passwords in ConfigMaps. Assuming encryption at rest is on by default, when it must be configured.

LIKELY FOLLOW-UPS How do you actually secure Secrets? Enable encryption at rest, lock down RBAC, and consider an external secrets manager. How are both consumed? As environment variables or mounted files. What about immutability? Both support an immutable flag to reduce API load.

ONE CONCRETE EXAMPLE An app reads its log level and an upstream URL from a ConfigMap, and its database password and TLS key from a Secret. The Secret is base64-encoded in YAML, RBAC limits who can read it, and the cluster has encryption at rest enabled so the value is not stored in plaintext in etcd, while the ConfigMap needs none of that protection.