A developer runs a DELETE statement without a WHERE clause on the primary database, and within seconds the rows are also gone from all three high-availability replicas. The manager asks why the replicas did not protect the data and how it can be recovered. Which response is correct?
Select an answer to reveal the explanation.
Short Explanation
Replication is a really fast photocopier, and it'll photocopy your mistakes just as fast as your good work. That's why replicas are for staying up, not for going back in time. When someone fat-fingers a DELETE, your way out is a backup and a point-in-time restore, not another replica.
Full Explanation
Replication exists to keep copies identical for availability: every committed change on the primary, whether intended or not, is applied to the replicas. A DELETE without a WHERE clause is a valid committed transaction, so it propagates like any other, and within seconds all replicas match the damaged primary. This is the core reason replication is not a backup. Recovery requires a copy of the data from before the mistake, normally a full backup plus transaction log backups restored to a point just before the delete, either into a separate database for copying the rows back or in place during an outage. Switching replicas to asynchronous mode changes only how quickly changes arrive; the delete has already been applied, and async lag is far too short and unpredictable to act as protection. Replicas do not filter statements by row count; they apply whatever the primary commits, so the idea that the delete ran separately on each replica is false. Failing over simply promotes a replica that already contains the same deletion, and replicas do not keep uncommitted copies of tables. Exam caveat: delayed replicas can help, but the exam answer for recovering deleted data is a backup or restore point. Operational check: restore to a separate database at a time just before the delete, verify row counts, then copy the rows back.