A city finance cloud team wants to restore a damaged ledger database, validate it thoroughly, then switch users over only after checks pass. Which recovery approach fits?
Select an answer to reveal the explanation.
Short Explanation
Think of rebuilding the kitchen in the garage, tasting the soup there, then moving dinner over. Parallel restore lets you validate before users land on it.
Full Explanation
Parallel recovery restores into a separate environment so operators can validate integrity and function before cutover, reducing the chance that a bad restore becomes the new production ledger. For city finance, restoring a damaged ledger database aside, checking balances and application behavior, then switching users only after checks pass protects payroll, vendor payments, and public financial trust.
Immediately overwriting production in place without a validation stage skips the safeguard the scenario requires and can compound corruption. Purging all backups and recreating empty schemas from memory destroys recovery options. Lowering RPO by skipping restore testing confuses objectives and removes quality gates during an incident.
Exam caveat: parallel (side-by-side) recovery trades extra storage/compute and slightly longer procedures for validation safety; in-place favors speed. Exam questions often cue "validate then cut over" to signal parallel recovery.
Operational check: provision an isolated restore target with adequate networking to finance apps, restore the ledger backup, run reconciliation scripts and smoke tests, then execute a documented cutover (connection string/DNS) with a go/no-go checkpoint. Retain the pre-cutover production copy until finance signs acceptance.