# Guided Exercise: ConfigMap, Secret, Env Var, or Volume?

Paper-and-thinking exercise before the Labs.

## The scenario

Your application needs four pieces of configuration:

1. A log level (`debug`/`info`/`warn`) that ops sometimes needs to flip without redeploying.
2. A database password.
3. A large JSON config file the application reads from a specific path at startup.
4. A feature flag read once at container startup via an environment variable, per the
   application's existing code.

## Your task

For each, decide: ConfigMap or Secret, and env var or volume mount — then justify each choice.

## A worked answer to check yourself against

1. **ConfigMap, env var.** Not sensitive; the application likely already reads it as an env var
   (a common convention), and env vars are simple to change and trigger a rolling restart with.
2. **Secret, either — but env var is common here too**, since most applications expect
   credentials via environment variables by convention. The KEY decision is Secret (sensitive),
   not the delivery mechanism.
3. **ConfigMap, volume mount.** The application expects a FILE at a path, not an environment
   variable — volume mount is the only mechanism that presents a ConfigMap as an actual file.
4. **ConfigMap (assuming not sensitive) or Secret (if it is), env var** — the application's
   EXISTING code dictates this; you don't get to choose a mechanism the application wasn't
   written to read.

## Self-check

If you chose "volume mount" for #4 or "env var" for #3, revisit the lesson — the deciding
factor here isn't which mechanism seems more "correct" in the abstract, it's what the
application actually expects. Getting this backwards means the application simply won't find
its configuration at all.

## Instructor Notes

**Facilitation:** Emphasize that #4's answer depends entirely on EXISTING application
behavior — a good moment to note that platform engineers frequently have to adapt Kubernetes
config delivery to match an application's assumptions, not the reverse.

**Approximate timing:** 8-10 minutes live with discussion; 8 minutes self-paced.

**Optional extension:** ask what would happen if a ConfigMap consumed as a volume mount is
UPDATED after the Pod is already running — a good bridge to the real (if not hands-on-tested
here) behavior that mounted ConfigMap files update automatically after a short delay, while
env-var-injected values do NOT update without a Pod restart.