EBS volumes that back a computer-aided dispatch (CAD) database must be encrypted at rest, and the account should prefer encryption by default for new volumes. Which design best enforces encrypted block storage for that sensitive workload?

Computer-aided dispatch databases backed by EBS must run on encrypted volumes, and the account should prefer encryption by default for new volumes so operators cannot casually launch unencrypted disks. Enabling EBS encryption by default for the account/Region, launching the CAD database on encrypted EBS volumes, and reinforcing with IAM permissions or service control guardrails where needed ensures block storage for this sensitive workload arrives already locked. Snapshots of encrypted volumes remain encrypted, supporting safer backup handling for dispatch data.

Using unencrypted gp3 volumes and copying database files hourly to an unencrypted public S3 bucket fails encryption at rest and confidentiality of CAD data. Disabling volume encryption because of a mistaken belief that encrypted EBS cannot be snapshotted fails both fact and policy—encrypted volumes can be snapshotted (with encryption preserved). Relying on security group descriptions that include the word encrypted without enabling EBS encryption fails because SG text is not a cryptographic control.

Exam caveat: encryption by default applies to newly created volumes in that Region; existing unencrypted volumes need a snapshot-copy-to-encrypted or migration plan, and cross-account share patterns require attention to CMK policies. Operational check: enable encryption by default, launch a replacement CAD volume without specifying encryption explicitly and confirm it is encrypted, attempt to create an unencrypted volume where guardrails deny it, and verify snapshots show encrypted=true.