A housing authority must retain lease status change history for audits without building custom audit tables. Which specialized table feature should they implement?
Select an answer to reveal the explanation.
Short Explanation
Temporal tables are like a housing file that keeps yesterday’s lease status behind a glass door while today’s row sits on the desk—SQL tracks the history for you. The authority gets audit-ready lease timelines without inventing a homemade audit table.
Full Explanation
Housing authorities often must prove what lease status was true at a prior time for audits, hearings, and compliance reviews. System-versioned temporal tables keep a current table and an automatic history table, stamping row versions with period columns so point-in-time queries (FOR SYSTEM_TIME AS OF / BETWEEN) retrieve prior lease status without a hand-built audit framework. That automatic history is exactly what the scenario asks for when custom audit tables are out of scope. A filtered nonclustered index that keeps only the latest status improves selective reads of current rows; it does not retain historical versions. An external table to scanned PDF packets may help document storage, but PDFs are not queryable row history inside Azure SQL. A SEQUENCE only emits integers; it neither stores prior attribute values nor supports AS OF semantics for lease status. Caveat: temporal history grows with every update—plan retention, history table storage, and which columns actually change—so audits stay affordable. Also ensure application updates modify the current row rather than attempting manual writes into the history table. Operational check: update a lease status twice, then query FOR SYSTEM_TIME AS OF a timestamp between the two changes and confirm the intermediate status is returned from history while the current table shows the latest value.