11. Configuration & Secrets

Load config predictably across environments; never hard‑code secrets; support safe overrides.

Question: What configuration precedence should a production Go service follow?

Answer: Defaults → config file (optional) → environment variables → command‑line flags. Keep secrets out of code and repo.

Explanation: This precedence enables safe overrides across environments and CI/CD. It aligns with 12‑factor principles and reduces accidental secret exposure.

Question: How do you load configuration idiomatically?

Answer: Keep a plain Config struct, parse flags with flag, read env with os.LookupEnv, and optionally layer tools like envconfig/viper.

Explanation: Using stdlib first keeps dependencies minimal and behavior explicit; higher‑level libraries can add convenience without lock‑in.

Question: How should application secrets be managed?

Answer: Use a secret manager (Vault, AWS Secrets Manager, GCP Secret Manager, Azure Key Vault) or SOPS. Enforce rotation, least privilege, and never log secret values.

Explanation: Centralized secret management prevents hard‑coding and enables auditability, rotation, and scoped access.

Question: How do you validate configuration and support hot reload?

Answer: Validate with explicit checks (required fields, ranges). For hot reload, watch files/env (e.g., fsnotify) and swap immutable config snapshots atomically.

Explanation: Keep config read-only after construction for thread safety. Use feature flags (e.g., config, flags, or a service) to safely roll out changes.