A city needs object storage for a public media vault, block storage for a CAD database, and a shared file system for engineering lifts. Which combination matches those access patterns?
Select an answer to reveal the explanation.
Short Explanation
Match the shelf to the stuff: S3 for the media museum, EBS disks under the CAD database chair, and EFS as the shared hallway cabinet for engineering. Mixing those up is like filing blueprints in a glacier locker and streaming photos from a database volume.
Full Explanation
Match storage to access pattern for the municipal stack: Amazon S3 for the public media vault (object storage with HTTP/API access), Amazon EBS volumes attached to the CAD database host (block storage for low-latency database disks), and Amazon EFS for shared engineering lifts (NFS file storage many instances can mount). That combination is the classic S3 / EBS / EFS triad aligned to object, block, and shared file needs.
Using EBS for the media vault, S3 for the CAD database, and instance store for shared engineering lifts fails by concept: EBS is not the natural public media object store, S3 is not a block device for a relational CAD database, and instance store is ephemeral and not a shared multi-instance file system. EFS for the relational CAD database, FSx only for anonymous Internet media, and local disks for shared lifts misassigns file storage to OLTP databases and local disks to shared lifts. Glacier Deep Archive for live CAD writes, EBS io2 for citizen photo streaming, and S3 for NFS mounts fails because Deep Archive is for rarely retrieved cold data, EBS is not a global photo CDN, and S3 is not an NFS mount for engineering shares (EFS/FSx fill that role).
Exam caveat: Memorize the mapping—S3 object, EBS block attached to EC2, EFS/FSx shared file. Distractors deliberately swap those roles; read the access pattern in the stem before picking services.
Operational check: Confirm media objects are addressed via S3 APIs/URLs, the CAD database’s data directory sits on appropriately provisioned EBS, and engineering hosts show a common EFS mount with concurrent read/write. If engineers still rsync local disks or databases point at S3 paths as block devices, the mapping is wrong.