A cloud tenant's storage buckets were copied out over a weekend. The attacker used a valid access key that a developer had committed to a public code repository, and the on-premises firewall, IPS, and VPN logged nothing unusual. What does this incident illustrate?
Select an answer to reveal the explanation.
Short Explanation
Think of handing a stranger your house key — the alarm on the front window never fires because they just walked in the door. A leaked cloud API key works the same way: every call is authenticated and legitimate-looking, so your on-prem perimeter never sees it. Don't blame the IPS; the traffic never went near it.
Full Explanation
Cloud control planes and storage services are reached directly over the internet through authenticated APIs. Whoever holds a valid access key can call those APIs from anywhere, and the provider treats the requests as legitimate because they are correctly signed. A key committed to a public repository is quickly harvested by automated scanners, and the resulting activity never traverses the organization's own firewall, IPS, or VPN, which is why those logs are clean. The defenses that matter are identity-centric: secret scanning in repositories, short-lived credentials, least-privilege policies, key rotation, and anomaly detection on cloud audit logs. An outdated IPS signature is irrelevant because no exploit was used and the traffic did not pass through the on-premises inspection path. A hypervisor escape is a multitenant isolation failure involving code execution in a neighboring workload, while this attacker simply authenticated as the tenant. A DNS hijack would redirect the developer's own connections, not hand an outsider access to the buckets. Exam caveat: under shared responsibility the customer always owns identities and access keys. Operational check: revoke and rotate the key, review cloud audit logs for every call made with it, and enable secret scanning on all repositories.