An application has a 15-minute RTO and uses database, middleware, and web VMs. Database must be available before middleware, and middleware before web. Which recovery plan orchestration best aligns the failover with the RTO?
Select an answer to reveal the explanation.
Short Explanation
Think of a recovery plan like a fire drill: you don't just yell go and hope everything lines up. If the database isn't ready, starting the web tier first only makes the outage longer, so you sequence failover by dependency and criticality. The trap is confusing RPO with RTO - snapshots tighten how much data you lose, not how fast the app comes back.
Full Explanation
Recovery plan orchestration aligns with an RTO by arranging failover actions so the minimum necessary services become available in the shortest defensible sequence. For a three-tier application, the database tier is usually the dependency root; starting it first lets the application and presentation tiers come up without retry loops or failed health checks. A plan that respects dependency order and criticality reduces wasted startup time and makes the 15-minute target testable. A single simultaneous failover step may look fast, but it ignores prerequisite services and can overload startup resources, leaving dependent VMs unable to connect or register successfully. An approval gate after replication checks is useful for controlled failover, yet it inserts human decision time into the critical path, which directly extends recovery time rather than shortening it. Increasing snapshot frequency affects how much recent data can be recovered, so it improves the recovery point objective, not the time required to bring replicated VMs online during failover. Exam caveat: RTO questions ask what makes the service usable sooner, while RPO questions ask how much data is lost. Operational check: run a controlled failover test, record the time from plan start to application health check, and remove any step that delays the first critical tier without adding assurance.