Study notes · 8% of the exam

ConfigMaps, Secrets and Configuration

Know how ConfigMaps and Secrets reach containers, when changes propagate, and what actually protects Secret values.

Key points

1
ConfigMaps and Secrets are namespaced, capped at 1 MiB, and can be consumed as env vars (env, envFrom) or as volume files (one file per key).
2
Env vars are fixed at container start. Whole-volume mounts update eventually via the kubelet sync; subPath mounts never update.
3
Trigger rollouts on config change with versioned names (Kustomize name hashing), a checksum annotation, or kubectl rollout restart.
4
Base64 is encoding, not encryption. Protect Secrets with RBAC on get/list/watch, by limiting who can create Pods, and with encryption at rest (prefer KMS v2).
5
immutable: true freezes data, can't be undone, and lets kubelets stop watching, which reduces API server load at scale.
6
The Downward API exposes Pod fields (metadata.name, status.podIP) and resource limits; label and annotation maps only through volumes.
7
Bound ServiceAccount tokens are projected, expiring and audience-bound; reload the token file instead of caching it.

Granting list on Secrets "just for names" exposes every value.
With identity listed first in an EncryptionConfiguration, new Secrets are stored unencrypted.
In JSON manifests, defaultMode must be decimal: 256 means 0400, while 400 means 0620.

Ten questions, with the answer and explanation after each one.