Configuration and Validation
Configuration and Validation
This domain tests how configuration is injected and how Kubernetes validates it: ConfigMaps, Secrets, environment variables, volumes, probes, resource requests and limits, and dry-run validation. The exam favors real failure signatures over theory.
ConfigMaps and Secrets
ConfigMaps and Secrets are namespaced API objects. Inject them as environment variables (valueFrom, envFrom) or volumes. A missing key referenced by valueFrom keeps a Pod in CreateContainerConfigError; an optional key avoids that. Secrets are base64-encoded by default, not encrypted at rest unless encryption configuration is enabled. Mounted Secret and ConfigMap volumes update eventually, but environment variables do not.
Validation and probes
Use kubectl apply --dry-run=server to run admission and schema validation without persisting. kubectl diff previews changes. Liveness probes restart containers; readiness probes remove Pods from Service endpoints; startup probes protect slow-starting apps from liveness restarts. Resource requests drive scheduling; limits enforce CPU throttling and memory OOM kills.
Worked example
A Pod is in CrashLoopBackOff. kubectl describe pod shows the container started, then exited; kubectl logs --previous shows the app cannot read DB_HOST. The Deployment uses envFrom on a ConfigMap that lacks DB_HOST. Add the key or fix the reference. If the container never starts, look for CreateContainerConfigError instead. Reasoning: distinguish start-time configuration failures from runtime crashes by container state and events.
Traps
A Secret in envFrom with an invalid key name is skipped unless you set a prefix. Requests without limits can starve a node; limits without requests cause scheduling surprises. A liveness probe that is too aggressive causes restart loops.