A fleet of CMS instances behind an Auto Scaling group must read and write a common content folder. Which storage service fits that shared file access pattern?
Select an answer to reveal the explanation.
Short Explanation
EFS is the shared city filing cabinet every CMS desk can open at once. Private EBS disks, glacier vaults, and throwaway instance store aren’t a common live content folder.
Full Explanation
A fleet of CMS instances in an Auto Scaling group that must read and write a common content folder should mount Amazon EFS. EFS provides a shared NFS file system that many EC2 instances can use concurrently, so every CMS desk sees the same live content directory as the group scales. That is the canonical shared-file pattern for multi-instance CMS content.
Separate Amazon EBS volumes that are never shared, with nightly rsync between random instances, fails by concept because EBS is single-attach for typical use and rsync is a brittle consistency hack—not a shared live folder. Amazon S3 Glacier Deep Archive as a POSIX mount for live CMS edits fails because Deep Archive is cold archival storage with restore delays, not a writable POSIX content root. Instance store volumes only, accepting content loss on every scale-in, fails because ephemeral disks discard CMS content when instances terminate.
Exam caveat: Shared POSIX content across an ASG → EFS (or FSx where Windows/SMB features require it). Non-shared EBS + rsync, Glacier, and instance store are wrong for live shared folders.
Operational check: Confirm all CMS instances mount the same EFS file system ID, security groups allow NFS, performance mode/throughput meet editorial load, and scale-in does not delete shared content. If editors still wait on nightly rsync between private EBS volumes, shared storage is not in place.