A township must place three workloads: a relational permitting database, a CMS that needs a shared POSIX file tree for web nodes, and long-term backups plus media archives. Which storage-type mapping is correct?
Select an answer to reveal the explanation.
Short Explanation
Match the tool to the job like matching keys to locks: databases want block, shared CMS trees want file, and backups/media love object. That trio—block, file, object—keeps each workload on the storage shape it expects. Stuffing a DB into pure object, parking CMS on Glacier, or one multi-attach volume for everything fights the access patterns.
Full Explanation
High-performing storage architecture maps each workload to the storage type that matches its access pattern. A relational permitting database needs low-latency random I/O on block storage such as Amazon EBS; a CMS that shares a POSIX file tree across web nodes needs file storage such as Amazon EFS or FSx; and long-term backups plus media archives belong on object storage such as Amazon S3. That block-plus-file-plus-object mapping is the correct township design and a core Task 3.1 teaching point for municipal systems. Placing the database on object storage, the CMS only on block volumes, and backups on a single local instance store fails because databases generally need block semantics, CMS shared trees need a shared file system rather than per-node block alone, and instance store is ephemeral—unsuitable as the backup system of record. Putting the database on file storage only, the CMS on Glacier, and backups on hot gp3 attached to every node fails conceptually: file storage is not the usual primary home for a relational engine, Glacier is too cold for active CMS content, and attaching hot backup volumes everywhere confuses backup durability with always-on local disks. Hosting all three workloads on one multi-attach io2 volume fails because one shared block volume cannot correctly serve relational DB, shared CMS file semantics, and durable archive patterns at once and creates a brittle single point of design failure. Exam caveat: “block vs file vs object” is the first filter; within each type you still choose performance modes, Multi-AZ options, and lifecycle classes for the civic SLO. Operational check: document which municipal system lands on EBS, EFS/FSx, and S3, verify the CMS mounts a shared file system from multiple web nodes, and confirm backups and media land in S3 with retention policies rather than on ephemeral disks.