You’ve just restored a volume from a snapshot and attached it to an EC2 Instance. This Instance hosts an application that is going to make use of the new EBS volume. You noticed some initial I/O latency when the application was first launched. How can you ensure that subsequent volumes created from the same snapshot don’t face the similar issue?

Answer options:

A.Ensure that the volume being created is of the volume type Provisioned IOPS.
B.Ensure that the volume being created is of the volume type General Purpose SSD.C.Ensure that the volume is created in the same availability zone as the snapshot.
D.Ensure that all blocks on the volume are accessed at least once.

Correct Answer: D
The AWS Documentation mentions the following.
New EBS volumes receive their maximum performance when available and do not require initialization (formerly known as pre-warming). However, storage blocks on volumes restored from snapshots must be initialized (pulled down from Amazon S3 and written to the volume) before you can access the block. This preliminary action takes time and can cause a significant increase in the latency of an I/O operation the first time each block is accessed. For most applications, amortizing this cost over the lifetime of the volume is acceptable. Performance is restored after the data is accessed once.
You can avoid this performance hit in a production environment by reading from all of the blocks on your volume before using it. This process is called initialization. For a new volume created from a snapshot, you should read all the blocks with data before using the volume.
Options A and B are incorrect because this does not depend on the underlying volume type.
Option C is incorrect since they need to anyway be in the same availability zone.
For more information on initializing volumes, please refer to the below URL-
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-initialize.html