DOP-C02 Security and Compliance Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Enable EBS encryption by default in the account.

  Why this is correct

  Enabling EBS encryption by default at the account level is a valid method because it automatically encrypts all new EBS volumes created in the account, using either the AWS managed key or a customer-managed KMS key. This setting is region-scoped and applies to volumes created from unencrypted snapshots when the snapshot is copied with encryption, but it does not retroactively encrypt existing unencrypted volumes. It is a control-plane safeguard that ensures any volume provisioned after enabling the setting is encrypted at rest without requiring per-volume configuration.

• ✗

  Use the AWS CLI to encrypt an existing volume in place.

  Why it's wrong here

  Using the AWS CLI to encrypt an existing volume in place is invalid because EBS does not support modifying the encryption attribute of an existing volume. The modify-volume API cannot change encryption state, and there is no CLI command to convert an unencrypted volume to encrypted directly. The only supported path is to create a new encrypted volume from an encrypted snapshot and migrate the data, meaning the original volume must be replaced rather than simply updated.

• ✓

  Encrypt the volume when creating it through the AWS Management Console.

  Why this is correct

  Encrypting the volume when creating it through the AWS Management Console is a valid method because the launch/creation wizard exposes an encryption option that sets the volume's encryption attribute at provisioning time. This allows you to explicitly choose either the default AWS managed key or a customer-managed KMS key for the new volume, regardless of whether account-level default encryption is enabled. The volume is fully encrypted at rest from the moment it exists, and any snapshots taken from it will also be encrypted.

• ✗

  Attach the volume to an EC2 instance and use OS-level encryption.

  Why it's wrong here

  Attaching the volume to an EC2 instance and using OS-level encryption is not a valid method to encrypt the EBS volume from AWS's perspective because it only protects data at the filesystem or application layer inside the guest OS, leaving the raw EBS blocks unencrypted. EBS encryption is a volume-level feature handled by the AWS infrastructure, and OS-level encryption does not cause AWS to mark the volume as encrypted, nor does it protect the volume when it is detached or snapshotted without the OS running. Compliance frameworks that require EBS encryption-at-rest will not accept OS-level encryption as equivalent, because the volume's underlying storage remains unencrypted in AWS's control plane.

• ✓

  Create an unencrypted snapshot of the volume, copy it with encryption, and create a new volume from the encrypted snapshot.

  Why this is correct

  Creating an unencrypted snapshot of the volume, copying it with encryption enabled, and then creating a new volume from the encrypted snapshot is a valid method to migrate an existing unencrypted volume to an encrypted one. During the snapshot copy operation, you can enable encryption and specify a KMS key, which produces an encrypted snapshot that can be used to provision a new encrypted volume. This process replaces the original volume and requires detaching or stopping the instance during migration, but it is the official way to apply EBS encryption to a volume that was originally created unencrypted.

Go deeper

Related to this question