Verbose debug logging is enabled in a shared config that currently ships in every package, including production. What should the team do for environment-specific configuration?
Select an answer to reveal the explanation.
Short Explanation
Production should not shout every internal thought by default. Keep debug noise for non-prod configs and ship quiet, safe defaults to citizens' environments. Turning logging off entirely—or logging secrets—swings the pendulum the wrong way.
Full Explanation
Developers prepare configuration for different stages with production-safe defaults. Verbose debug logging that ships enabled in every package, including production, should be turned off in production configs unless explicitly elevated under controlled change. Environment-specific config via AppConfig, environment variables, or staged parameter values protects municipal systems from cost, noise, and accidental data exposure while preserving debug capability in lower environments.
Shipping debug logging enabled everywhere so support never needs another deploy fails because production then constantly emits high-volume, higher-risk logs. Removing all logging from every environment fails conceptually as an overcorrection that destroys operability. Printing secrets at DEBUG level only in production fails by design—it concentrates credential leakage where blast radius is largest.
Exam caveat: ensure log level is not accidentally enabled by a shared default file baked into the artifact without per-stage overrides. Operational check: inspect production config for debug flags, generate traffic, confirm log volume and content are production-appropriate, and document a temporary elevate procedure with an expiry.