Finance must move funds across multiple appropriation accounts in one ACID transaction with multi-row SQL updates. Which data store choice fits best for the application?
Select an answer to reveal the explanation.
Short Explanation
When several account rows must succeed or fail together, you want a real SQL transaction—Aurora or RDS—not a hope that a single PutItem covers the whole ledger.
Full Explanation
Multi-row appropriation moves that must commit or roll back together are a relational ACID problem. Amazon Aurora or Amazon RDS gives the finance application SQL transactions across related account rows so funds cannot partially post—exactly what municipal appropriation integrity requires when several accounts must stay consistent in one business transaction.
A single DynamoDB PutItem without transactions does not provide multi-row ACID by default; DynamoDB transactions exist but the distractor’s claim that NoSQL always provides multi-row ACID is false, and the stem’s multi-row SQL updates point to a relational engine. S3 strong read-after-write for CSV files is object storage consistency, not multi-row transactional updates across appropriation accounts. ElastiCache Redis lists are an in-memory cache/structure store, not a durable system of record for financial appropriations.
Exam caveat: DynamoDB TransactWriteItems can cover limited multi-item ACID, but when the requirement is explicitly multi-row SQL updates and relational accounting semantics, Aurora/RDS is the intended fit. Operational check: run a transfer that updates two appropriation rows inside one transaction, kill the connection mid-commit in a test, and verify neither row shows a partial balance change.