A city clerk RDS database needs solid baseline performance but does not require provisioned io2-level IOPS. Which storage choice best balances cost and capability?
Select an answer to reveal the explanation.
Short Explanation
Buy the tool that fits the job. gp3 covers most clerk workloads; io2 is the specialty wrench when metrics prove you need it.
Full Explanation
A city clerk RDS database that needs solid baseline performance without measured io2-level IOPS is a classic fit for Amazon RDS gp3 general-purpose SSD. gp3 provides predictable baseline SSD performance with the ability to provision additional IOPS and throughput independently of storage size when metrics demand it—so the city pays for capability it needs rather than defaulting to the most expensive storage tier. Automated backups, Multi-AZ options, and managed durability remain intact for clerk records such as licenses, minutes, and vital-event metadata.
Always choosing io2 Block Express for every municipal database regardless of measured need fails by concept: provisioned IOPS storage costs more when gp3 already meets latency and IOPS targets. Storing relational database files only in S3 Glacier Deep Archive fails as primary storage—Glacier is cold object storage with restore delays, not a block volume for RDS. Attaching instance store exclusively and disabling automated backups cuts durability inappropriate for clerk systems of record and abandons managed RDS storage benefits.
Exam caveat: gp3 is not universally "always cheaper and enough"—latency-sensitive, sustained high-IOPS workloads (heavy OLTP spikes) may still justify io2 after measurement. The exam point is right-sizing storage class to evidence, not prestige SKUs.
Operational check: review CloudWatch ReadIOPS, WriteIOPS, DiskQueueDepth, and read/write latency on the clerk instance, start on gp3 with baseline settings, raise provisioned IOPS/throughput only if queues and latency breach SLA, and compare RDS storage line items before approving an io2 migration.