A sudden configuration change in production broke the city's utility billing API. What software-security control would best support investigation and accountability?
Select an answer to reveal the explanation.
Short Explanation
When billing breaks at 2 a.m., "someone changed something" is not an answer citizens will love. Logged, auditable production changes tell you what moved, who moved it, and when. That trail is how you fix it and keep it from happening again.
Full Explanation
Immutable logging and auditing of production code and configuration changes provide the evidence trail needed when a sudden change breaks a utility billing API. Investigators need trustworthy records of what changed, by whom, when, and from which pipeline or console. Immutable or append-only logs resist tampering by the same privileged actors who can alter production, supporting accountability, rollback decisions, and after-action learning for civic billing continuity.
Verbal hallway approvals with no written record leave no reconstructible history. When billing fails at scale, undocumented approvals cannot support forensics or compliance inquiries.
Shared root passwords rotated only when staff resign destroy individual accountability and often linger far too long; shared credentials also complicate attributing a harmful configuration change.
Turning off change tickets forever to restore service faster removes the process metadata that links intent, risk review, and implementation. Emergency paths should be exceptional and documented, not a permanent ticketless culture.
Exam caveat: logging/auditing of production changes is a software-security and operations control for integrity and accountability—not optional bureaucracy. Operational check: send config and deploy events to a write-once or tightly controlled SIEM, alert on production changes outside change windows, require unique identities (no shared root), and rehearse billing API rollback using the audit trail as the source of truth.