Deployment & Infra
Secrets at deploy: free-recall review
Retrieval beats re-reading. For each prompt, say or write a full answer from memory before you open the model answer — the effort of recall is what makes the threat model stick.
Reconstruct the unit’s core mechanisms — image hygiene, the base64 trap, etcd at rest, env-vs-file injection, sealed secrets for GitOps, and dynamic rotation — without looking back at the lesson.
- 01Why must a secret never enter at build time, and why does deleting it in a later Dockerfile layer not help?
- 02A colleague says 'our Kubernetes Secrets are safe because the values are base64-encoded.' Correct them precisely and name the real protections.
- 03What does enabling etcd encryption at rest actually protect, and what is the trap many teams hit right after turning it on?
- 04Why do many teams inject secrets as mounted files rather than environment variables, and what does that buy them?
- 05A GitOps team must commit something so Argo CD can apply it. Compare a base64 Secret, a ConfigMap, and a Sealed Secret for this.
- 06Outline the secrets-handling ladder a senior applies, safest-first, and explain why dynamic short-lived credentials sit at the strong end.
If you could reconstruct each answer from memory, you hold the unit’s spine: the secret enters at deploy or runtime and never in the image; base64 is encoding, not encryption; etcd needs encryption at rest configured and existing Secrets rewritten; file mounts shrink leak surface and rotate in place where env vars leak and freeze; Sealed Secrets make a committable GitOps artifact; and dynamic short-lived credentials make a stolen secret expire before it is useful.