A developer pastes a municipal cloud access key into a public Git repository. What should the team treat as the primary incident?
Select an answer to reveal the explanation.
Short Explanation
A secret in a public repo is already out in the wild—rotate it now, assume someone else saw it, and check what that key touched. Don't start with VLAN or NAT distractions.
Full Explanation
A developer pasting a municipal cloud access key into a public Git repository should be treated as a leaked-credentials incident requiring immediate key rotation and exposure assessment. Public exposure of long-lived keys is an urgent civic compromise path even before confirmed abuse. A failed blue-green deployment of the permitting UI is a release issue, not the primary incident described. An undersized NAT gateway during tax season is capacity, not credential leakage. A VLAN mismatch on a hybrid ESXi host is a network isolation problem unrelated to the public key paste. Exam caveat: rotate first—assume the key is burned once public; then search audit logs for use outside expected municipal automation. Operational check: disable/delete the exposed access key immediately, issue a replacement with least privilege if still needed, scan Git history and purge where feasible, review CloudTrail-equivalent logs for abuse, and mandate secret scanning in civic repositories. In municipal cloud operations, record the chosen control and the rejected alternatives in the change or incident ticket so future on-call staff understand which failure modes were avoided for city services. Re-validate after the next maintenance window that the same decision still holds under current provider limits, identity bindings, and application versions used by the civic platform team.