A public-works team enables encryption on an Amazon EBS volume attached to an EC2 instance that holds GIS files. Which encryption category does that control primarily represent?
Select an answer to reveal the explanation.
Short Explanation
An encrypted EBS volume is like locking the filing cabinet bolted into the truck — the GIS files sitting on that disk are protected at rest. That is not the same as TLS on the network or Shield soaking up floods. Backups and certificates are separate conversations.
Full Explanation
Encryption at rest for data stored on an Amazon EBS volume protects GIS or other municipal files while they sit on disk — like locking the filing cabinet bolted into the truck. That control category is not the same as TLS protecting packets in transit, and it does not replace IAM policies that decide who may attach, snapshot, or share volumes containing civic geospatial data. When a question focuses on data stored on the EBS volume, at-rest encryption is the correct framing. Distractors that rebrand volume encryption as solely in-transit protection, that claim EBS encryption removes all need for identity controls, or that treat snapshot governance as optional forever fail conceptually. Exam caveat: at-rest encryption mitigates certain media-exposure and lost-disk classes of risk, but an authorized principal with permission can still read plaintext through service APIs; pair encryption with least privilege and careful KMS key policy design. Operational check: enable EBS encryption by default where policy requires, use customer managed KMS keys when governance demands, verify snapshots and AMI workflows preserve encryption expectations, restrict snapshot sharing outside the organization, and inventory unencrypted volumes on fleets that store sensitive civic geospatial layers.