A SysOps administrator has launched a large general purpose Amazon EC2 instance to regularly process large data files. The instance has an attached 1 TB General Purpose SSD (gp2) Amazon Elastic Block

Question

Options

• AChange the instance type to a large, burstable, general purpose instance.
• BChange the instance type to an extra large general purpose instance.
• CIncrease the EBS volume to a 2 TB General Purpose SSD (gp2) volume.
• DMove the data that resides on the EBS volume to the instance store.

• B
  11% (2)
• C
  84% (16)
• D
  5% (1)

Explanation

Option C is correct because gp2 EBS volumes provision exactly 3 IOPS per GB of storage, meaning a 1 TB volume delivers a 3,000 IOPS baseline - precisely what CloudWatch is showing as a consistent ceiling. Doubling to 2 TB raises the baseline to 6,000 IOPS, relieving the bottleneck while keeping data on persistent EBS storage (ensuring integrity).

Option A is wrong because burstable (T-series) instances are designed for variable, intermittent workloads, not sustained heavy I/O - they would reduce reliability for consistent processing jobs.

Option B is wrong because the instance size doesn't determine EBS IOPS; the volume is already EBS-optimized, so changing the instance type doesn't address the storage bottleneck.

Option D is wrong because instance store is ephemeral - data is wiped every time the instance is stopped, which the admin does nightly. This directly violates the data integrity requirement.

Memory tip: Burn in the gp2 formula - "3 IOPS per GB". Whenever you see CloudWatch hitting a round number like 3,000 on a 1 TB volume, that's a dead giveaway the volume is at its IOPS ceiling, and the fix is to scale the volume size up.

No community discussion yet for this question.