Don't Bake It In
A cardinal rule of containerization (and the 12-Factor App methodology) is: never hardcode configuration into your container image. If you bake a database URL or API key into the image, you must rebuild and redeploy the entire image just to change a single setting. Worse, you might accidentally ship secrets into a public container registry.
Kubernetes provides two objects to separate configuration from code:
ConfigMap: Stores non-sensitive configuration data as key-value pairs or entire config files. Examples: database hostnames, feature flag values, log levels, config file contents.
Secret: Stores sensitive data like passwords, API tokens, and TLS certificates. Values are stored base64-encoded (not encrypted) in the Kubernetes API. This is a common point of confusion: base64 is an encoding scheme, not encryption — a value like cGFzc3dvcmQxMjM= is just password123 run through a reversible encoding, decodable by anyone with access to the Secret object in seconds, not a cryptographic protection.
Critical security note: Secrets are not encrypted at rest in etcd by default. To actually protect secrets, cluster administrators must enable Encryption at Rest for the etcd datastore, or use an external secrets management system like HashiCorp Vault or AWS Secrets Manager integrated via a CSI driver or operator.
Interviewers frequently ask: "Are Kubernetes Secrets actually secure?" The correct answer is nuanced: Secrets provide access control (RBAC can restrict who can read them) and are base64-encoded, but they are not encrypted by default. True security requires enabling etcd encryption at rest and restricting RBAC access to Secret objects. In high-security environments, teams use external secret stores (Vault, AWS Secrets Manager) and sync them into the cluster using tools like the External Secrets Operator, so the actual secret values never live in etcd at all.