To troubleshoot a performance problem, an engineer shares a snapshot of a production volume that holds customer data with an external consultant's cloud account. Why is this a significant threat to volume storage?
Select an answer to reveal the explanation.
Short Explanation
Handing someone a snapshot is like handing them a photocopy of your entire filing cabinet. Once they restore it in their own account, your access controls don't follow it. That's why snapshot sharing gets treated as data export, not a quick troubleshooting favor.
Full Explanation
A volume snapshot is a point-in-time copy of an entire block storage volume. When it is shared with another account, that account can create a new volume from it, attach the volume to its own virtual machine and read every file, database page and remnant the original contained. The company's access controls, monitoring and logging do not extend into the recipient's tenant, so the data has effectively left organizational control. That makes snapshot and copy exposure a recognized threat to volume storage, and sharing should require approval, minimization and contractual protection, or a sanitized data set instead. Snapshots do not lock the source volume; production continues writing while the copy is taken. Snapshots contain the full block data, not only metadata, which is why they are useful for backup and restore and why they are dangerous to share. Sharing does not re-encrypt the snapshot with the recipient's key and remove the owner's ability to decrypt; if anything, customer-managed key encryption can limit what the recipient can do, which is a useful mitigation. Exam caveat: the same threat applies to machine images that contain data or embedded secrets. Operational check: inventory snapshots shared outside the tenant and alert on any new cross-account sharing.