City payroll must be usable again within 8 hours after an outage. Losing one hour of payroll data is a separate limit. Which target is the 8-hour figure?
Select an answer to reveal the explanation.
Short Explanation
How long you can stand to be closed is a different promise from how much work you can stand to redo. You must have payroll usable again within 8 hours, so that figure is the recovery time objective. The one hour of data you can lose is the other target, and an average time between failures or a lease timer does not rename the outage limit.
Full Explanation
The recovery time objective is the maximum time a service may stay unavailable before it must be usable again. Payroll that has to be back within 8 hours has an 8-hour recovery time objective. The clock starts at the outage and ends when the service is restored to the agreed level. The recovery point objective is the maximum amount of data loss, measured as how far back the last good copy may be. Losing one hour of payroll data is that separate limit. Swapping the names is the usual trap, and the question asks for the 8-hour figure, which is time to restore, not data loss. Mean time between failures is an average of how long a component runs before it fails. A long figure means failures are rare. It is not a business deadline for returning payroll to service after one of those failures. A DHCP lease time controls how long a client keeps an address assignment. It has nothing to do with restoring an application, and changing the lease would not make payroll recoverable in 8 hours. Exam caveat: meeting the recovery time does not mean the data loss target was met. A restore that finishes in 3 hours from a day-old copy would satisfy this 8-hour recovery time and miss the one-hour recovery point. Operational check: time a payroll restore drill from the declared start until users can work, and record that duration against 8 hours separately from how much data the restored copy was missing.