A monitoring tool flags an S3 bucket as public, and it contains customer data exports. What's your FIRST action?
Short answer
Public customer data is an active exposure, so remediate access first: enable Block Public Access and correct the bucket and IAM policy to stop ongoing leakage. Then pull access logs (S3 server access logs / CloudTrail data events) to assess what was actually reached, and trigger breach and notification processes per policy. Ticketing it for next sprint leaves regulated data exposed for days. Copying the data elsewhere creates a second copy but leaves the original bucket open. Renaming changes nothing about its permissions.
A public bucket of customer data is a live incident, not a backlog item. The interviewer is testing whether you instinctively stop the bleeding before you analyze it, and whether you understand the order: contain, then investigate, then notify.
Why locking down first is correct
Every minute the bucket stays public, more data can be enumerated and pulled by anyone — including automated scanners that constantly crawl for open buckets. Enabling Block Public Access and fixing the offending bucket policy or ACL closes the exposure in seconds and is reversible. Only after the leak is closed do you investigate scope: pull S3 server access logs and CloudTrail data events to see which objects were listed or downloaded and from where. That evidence drives the breach decision and any regulatory notification (for example, GDPR's 72-hour clock for personal data).
Why the other options are wrong
- Open a ticket for next sprint. This treats an active data exposure as routine maintenance. Regulated customer data would sit open for days while attackers and scrapers help themselves — a clear failure of judgment.
- Copy the data to a different bucket and leave the old one public. This does nothing to close the exposure; the original bucket is still readable by the world. You have now also created a second copy of sensitive data to secure.
- Rename the bucket. Permissions travel with the object and policy, not the name. A renamed-but-still-public bucket is exactly as exposed, and bucket names are global and discoverable anyway.
What interviewers look for
The hallmark of a strong answer is sequencing: contain, then assess, then notify — and naming the specific control (Block Public Access) plus the specific evidence (access logs / CloudTrail data events). Bonus points for mentioning that you would also hunt for other public buckets account-wide, since one misconfiguration usually signals a missing guardrail rather than a one-off mistake.
Likely follow-ups
- Which logs would tell you whether the data was actually downloaded, and what are their limits?
- At what point does this become a reportable breach under GDPR, and who decides?
- How would you prevent any bucket from becoming public account-wide?