SOA-C02 Practice Question: EBS snapshot restoration strategy for large…
An EC2 instance runs a database on a 2 TB EBS gp3 volume. After a corruption event, the team must restore from a snapshot. When they detach the corrupted volume, attach a new volume restored from the snapshot, and start the database, performance is 10 to 20 times lower than normal for the first two hours. What causes this behavior, and what feature eliminates it?
⚠ Common exam trap
It's easy for candidates to assume performance issues are due to volume type (gp3 vs io2) or size, rather than recognizing the fundamental lazy-load initialization behavior of EBS snapshots and the specific feature (FSR) designed to mitigate it.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Enable Fast Snapshot Restore (FSR) on the snapshot in the target Availability Zone before creating the replacement volume
When you create an EBS volume from a snapshot, the volume's data blocks are lazily loaded from Amazon S3 on first access. This causes high latency and low IOPS until all blocks are fetched. Fast Snapshot Restore (FSR) pre-initializes the volume in a specific Availability Zone, eliminating the need for lazy loading and providing full performance immediately.
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 Fast Snapshot Restore (FSR) on the snapshot in the target Availability Zone before creating the replacement volume
Why this is correct
FSR fully initializes the volume's block index immediately upon creation. The first I/O to any block is served from EBS at full throughput rather than waiting for lazy initialization from S3. For a 2 TB database volume where I/O latency determines restore time, FSR eliminates the 2-hour performance degradation period entirely.
- ✗
Use a Provisioned IOPS (io2) volume type instead of gp3 to get higher IOPS during initialization
Why it's wrong here
Provisioned IOPS affects the maximum IOPS ceiling of a volume, but lazy initialization still applies regardless of volume type. Until blocks are touched for the first time and loaded from S3, even an io2 volume will experience the same initialization latency per uninitialized block.
- ✗
Run a full dd or fio pre-warm pass over the volume after attaching it but before starting the database
Why it's wrong here
A sequential read pass (dd if=/dev/xvdf of=/dev/null) forces all blocks to be read from S3 and initialized in the EBS layer, which effectively pre-warms the volume. This is the manual alternative to FSR and adds hours of pre-warm time before the database can start — the downtime is traded for warm disk performance.
- ✗
Increase the EBS volume size to 4 TB when restoring from the snapshot to get double the throughput baseline
Why it's wrong here
Increasing the volume size from 2 TB to 4 TB does not increase the gp3 throughput baseline, because gp3 provisions a fixed baseline of 125 MiB/s and up to 1,000 MiB/s via independent IOPS/throughput settings, unlike gp2 where baseline throughput scales with volume size. Moreover, the key issue is lazy initialization: every block on the restored volume—regardless of size—is read from S3 on first access until initialized. A 4 TB volume has twice the uninitialized blocks to touch, so it can actually lengthen the initialization window if the database scans across the entire volume, and it doesn't address the root cause of slow first I/O.
Quick reference
AWS S3 Storage Class Comparison
| Storage Class | Min Duration | Retrieval | Use Case |
|---|---|---|---|
| S3 Standard | None | Immediate | Frequently accessed data |
| S3 Standard-IA | 30 days | Immediate | Infrequent access, rapid retrieval |
| S3 One Zone-IA | 30 days | Immediate | Non-critical infrequent data |
| S3 Intelligent-Tiering | None | Immediate–hours | Unknown or changing access patterns |
| S3 Glacier Instant | 90 days | Milliseconds | Archive with instant retrieval |
| S3 Glacier Flexible | 90 days | Minutes–hours | Archive, flexible retrieval |
| S3 Glacier Deep Archive | 180 days | Hours | Long-term compliance archive |
Go deeper
Related to this question
About these practice questions
Courseiva writes every SOA-C02 question from scratch — 1,169 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SOA-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SOA-C02 exam.