A county runs RDS for both production tax systems and short-lived developer sandboxes. How should Multi-AZ be applied to control database cost without harming production RTO?
Select an answer to reveal the explanation.
Short Explanation
Pay for the spare parachute on the plane that carries taxpayers, not on the weekend sandbox glider. Single-AZ for nonprod, Multi-AZ where RTO earns its keep.
Full Explanation
County tax systems that citizens and clerks depend on need recovery time objectives that justify Multi-AZ RDS: a synchronous standby in another Availability Zone supports automatic failover when the primary AZ fails. That HA capability roughly doubles instance cost relative to Single-AZ, so it should be applied where RTO and citizen impact warrant the spend—production tax, collections, and related OLTP. Short-lived developer sandboxes rarely need that failover posture; Single-AZ RDS for nonproduction keeps license-adjacent instance hours and standby cost out of lab environments without harming production RTO.
Enabling Multi-AZ on every sandbox while disabling it in production inverts risk by concept: you spend HA dollars where outages are tolerable and remove HA where taxpayers notice. Replacing production Multi-AZ with Spot EC2 self-managed MySQL undermines managed failover guarantees and introduces interruption risk unsuitable for tax systems. Requiring Aurora Global Database cross-Region for every developer laptop database vastly over-provisions DR topology and cost for ephemeral sandboxes.
Exam caveat: "nonproduction" is not always Single-AZ—pre-prod environments that must rehearse failover or mirror production latency may still need Multi-AZ. The exam theme is aligning HA spend with RTO, not deleting HA everywhere to save money.
Operational check: inventory RDS instances by environment tag, confirm production tax clusters show MultiAZ=true, schedule sandbox stop/start where appropriate, compare monthly RDS instance charges before and after sandbox Single-AZ conversion, and run a controlled failover test in production maintenance windows to validate RTO assumptions remain intact.