An engineer launches an EC2 instance using the AWS CLI's run-instances command, attaching one additional (non-root) EBS data volume in the same launch request, without explicitly setting DeleteOnTermination on that volume. Later, when the instance is terminated, what happens to that additional volume by default?
- It is preserved, because non-root volumes are never deleted automatically
- Its deletion behavior always matches whatever was chosen for the root volume
- It is preserved only if it was created from a snapshot
- It is deleted, because the CLI's default DeleteOnTermination behavior for a data volume attached at launch differs from the console's default
Why D? And why not the others?
Correct answer: D. It is deleted, because the CLI's default DeleteOnTermination behavior for a data volume attached at launch differs from the console's default
AWS documents different default DeleteOnTermination behavior for a non-root data volume depending on how it is attached at launch: attaching it through the console defaults to preserving the volume (DeleteOnTermination false), while attaching the same kind of volume at launch through the CLI or API defaults to deleting it (DeleteOnTermination true) unless the block device mapping explicitly overrides that value. So an engineer who launches via the CLI and does not set the attribute ends up with the volume deleted on termination, which surprises people who assume the console's more forgiving default applies everywhere. The claim that non-root volumes are never deleted automatically ignores this CLI default entirely. Root and data volume DeleteOnTermination settings are independent attributes, so a data volume's behavior does not automatically mirror whatever was chosen for the root volume. There is no rule tying deletion behavior to whether a volume originated from a snapshot; only the attach method and explicit configuration matter.
Source: AWS EC2 documentation: Preserve data when an instance is terminated — default deletion behavior for EBS volumes