A county Lambda in production writes DEBUG logs with infinite CloudWatch Logs retention, driving cost and widening exposure of sensitive permit fields. What should the developer change?
Select an answer to reveal the explanation.
Short Explanation
Infinite DEBUG in prod is like leaving every hallway light on with the doors unlocked—pricey and leaky. Turn the volume down to what operators need and put a retention clock on the log group. You still keep enough history without forever storing sensitive permit chatter.
Full Explanation
A county Lambda in production that writes DEBUG logs with infinite CloudWatch Logs retention drives cost and widens exposure of sensitive permit fields. The developer should raise the production log level (for example to INFO/WARN) and set a finite retention period appropriate to classification and environment. Production verbosity and forever retention are a common cost-and-compliance footgun for municipal workloads.
Keeping DEBUG forever in production and only encrypting the log group with a CMK still retains excessive sensitive detail and cost.
Mirroring every DEBUG line into DynamoDB with no TTL multiplies storage cost and exposure.
Deleting the log group after each deploy so retention settings never matter destroys continuity needed for incidents spanning releases.
Exam caveat: Log level and retention are both in-scope operational configuration for developers instrumenting Lambda.
Operational check: Set production LOG_LEVEL to INFO, configure retention (for example 30/90 days per policy), verify DEBUG no longer floods, scan for sensitive fields, and document retention in the county's logging standard. Keep the civic/municipal context in mind: permit fields often include personal data; infinite DEBUG retention expands breach blast radius.