A city CMS needs a shared POSIX file system that multiple web instances across Availability Zones can use, and content must survive loss of one AZ. Which file storage approach fits?
Select an answer to reveal the explanation.
Short Explanation
Regional EFS is the shared filing cabinet with drawers in more than one building. Web nodes across AZs mount the same tree, and one AZ outage does not erase the cabinet. One EBS NFS export is still one building’s cabinet.
Full Explanation
A city CMS that needs a shared POSIX file system across web instances in multiple Availability Zones, with content surviving loss of one AZ, should use Amazon EFS in Regional (Multi-AZ) mode. Regional EFS presents a shared file tree that NFSv4 clients in different AZs can mount concurrently, and the service is designed so AZ impairment does not erase the filesystem the way a single-AZ NAS export would. That matches municipal CMS media and templates that every web node must see consistently.
A single EBS volume attached to one writer instance and NFS-exported from that host fails because the exporter host and the single volume attachment remain single points of failure and typically lack true Multi-AZ file service semantics. Instance store volumes rsynced nightly between AZs fail on both durability timing and consistency: nightly sync implies stale or missing content after an AZ loss during the day. Local ext4 disks on each instance with no shared mount fail the shared-POSIX requirement entirely and recreate divergent CMS state per node.
Exam caveat: EFS One Zone storage classes do not meet a Multi-AZ survival requirement—specify Regional EFS when AZ loss must not destroy the share. Operational check: mount the same EFS ID from web instances in two AZs, verify read/write consistency, simulate AZ loss of one mount target path, and confirm CMS content remains available from the surviving AZ.