A company has an Amazon EC2 instance that supports a production system. The EC2 instance is backed by an Amazon Elastic Block Store (Amazon EBS) volume. The EBS volume's drive has filled to 100%…

Question

Options

• AModify the EBS volume by adding additional drive space. Log on to the EC2 instance. Use the file
• BCreate a snapshot of the existing EBS volume. When the snapshot is complete, create an EBS
• CCreate a new EBS volume of a larger size in the same Availability Zone as the EC2 instance.
• DStop the EC2 instance. Change the EC2 instance to a larger instance size that includes additional

• A
  78% (29)
• B
  8% (3)
• C
  11% (4)
• D
  3% (1)

Explanation

Option A is correct because AWS supports live EBS volume modification - you can increase the size of an EBS volume while the EC2 instance is still running, meaning zero downtime. Once the volume is resized, you log in and use OS-level tools (resize2fs for ext4, xfs_growfs for XFS) to extend the filesystem, resolving the error immediately without interrupting the production workload.

Why the others are wrong:

• B requires waiting for a snapshot to complete (potentially hours for large volumes) before creating the new volume - adding significant delay.
• C creates a new volume but doesn't automatically migrate data or mount it; extra manual steps (format, copy data, remount) add time and complexity.
• D requires stopping the instance (causing downtime), and changing instance size doesn't directly fix the EBS volume capacity issue.

Memory tip: Think "Elastic" in EBS - just like elastic, you can stretch it while it's in use. Resizing EBS = no stop required, just resize + extend filesystem. Snapshot-first approaches are for creating new volumes, not the fastest fix for a full disk.

No community discussion yet for this question.