Resilience and Recovery
Exam objective 3.4: Explain the importance of resilience and recovery in security architecture. This objective covers how organizations keep running when things break and how they recover when something breaks badly: recovery sites and their environmental placement; platform diversity; redundancy (load balancing, clustering, autoscaling, high availability, multicloud, and power); storage; backup retention, immutability, scope, and restoration testing; failover, simulation, and parallel processing tests; disaster recovery, business continuity, and capacity planning; and the recovery metrics RTO, RPO, MTTR, and MTBF.
This is an "explain" objective. Expect questions that describe a business requirement—"must be back online within four hours," "can lose no more than 15 minutes of data," "ransomware must not be able to delete the backups"—and ask you to pick the site type, backup strategy, redundancy technique, or metric that fits. Know the trade-offs, especially cost versus recovery speed, because the cheapest option that meets the requirement is usually the right answer.
Resilience Versus Recovery
Resilience is the ability of a system or organization to continue operating, perhaps in a degraded state, when components fail or are attacked. Redundant power supplies, clustered servers, and load-balanced web farms build resilience: a failure happens, and users barely notice.
Recovery is the ability to restore normal operations after a disruption that resilience could not absorb— a ransomware outbreak, a flooded data center, or a corrupted database. Backups, recovery sites, and disaster recovery plans support recovery.
Both serve the availability leg of the CIA triad (Chapter 1), and both protect integrity: a clean backup is how you undo unauthorized changes. Security architects care because attackers target availability directly—ransomware operators hunt for and delete backups before encrypting production, and denial-of-service attacks exhaust capacity.
Recovery Metrics
The metrics drive every other decision in this chapter. They come out of the business impact analysis (BIA) (Chapter 23).
Recovery Time Objective (RTO)
The recovery time objective (RTO) is the maximum acceptable length of time a system or process can be down before the outage causes unacceptable harm. RTO drives the choice of recovery site, level of redundancy, and investment in automation.
RTO is set shorter than the maximum tolerable downtime (MTD), the absolute longest the business can survive without the function.
Recovery Point Objective (RPO)
The recovery point objective (RPO) is the maximum acceptable amount of data loss, measured as time. An RPO of one hour means the business can tolerate losing up to one hour of data, so backups or replication must capture changes at least every hour. An RPO of zero (no data loss) requires synchronous replication.
RPO drives backup frequency and replication design. RTO looks forward from the disaster (how long until we are back?), while RPO looks backward (how much recent work is lost?).
Figure 13.1: RPO measures data loss back to the last good backup, while RTO measures downtime forward to restoration, and both must fit within the MTD
Mean Time to Repair (MTTR)
Mean time to repair (MTTR) is the average time required to repair a failed component or system and return it to service. It measures maintainability. If MTTR for a storage array is six hours, a single array cannot support a two-hour RTO; redundancy must cover the repair window.
Mean Time Between Failures (MTBF)
Mean time between failures (MTBF) is the average operating time between failures of a repairable component. It measures reliability. A drive model with a higher MTBF fails less often. MTBF is a statistical average across a population of devices, not a guarantee for any single device. A related term, mean time to failure (MTTF), is used for components that are replaced rather than repaired. Availability can be estimated as:
- Availability = MTBF / (MTBF + MTTR)
- Example: MTBF = 9,990 hours, MTTR = 10 hours
- Availability = 9,990 / 10,000 = 0.999 = 99.9% ("three nines")
- Metric Question it answers Drives Better when
RTO How long can we be down? Site type, redundancy, automation Shorter (costs more)
RPO How much data can we lose? Backup frequency, replication Shorter (costs more)
MTTR How long does a repair take? Spares, support contracts, staffing Lower MTBF How often does it fail? Hardware selection, redundancy Higher
Memory aid
RTO = Out of service how long (time). RPO = Point in the past you roll back to (data). For the means: MTBF is "Between Failures" (bigger is better); MTTR is "To Repair" (smaller is better).
Exam tip
If a question says "the business can tolerate losing no more than 30 minutes of transactions," it is describing RPO. If it says "the service must be restored within 30 minutes," it is describing RTO. Read carefully: the numbers may be identical while the metric differs.
Recovery Sites
A recovery site is a location where an organization can resume operations if its primary site becomes unusable. Readiness determines recovery speed and cost.
Hot Site
A hot site is a fully equipped, operational duplicate of the primary site with current or near-current replicated data. Operations can switch within minutes to hours. Hot sites support the shortest RTOs and RPOs but are the most expensive—effectively a second data center that sits mostly idle.
Warm Site
A warm site has power, cooling, network connectivity, and some or all of the necessary hardware, but systems are not fully configured and data is not current. Recovery requires installing or configuring software and restoring data from backups, typically taking hours to days. A warm site balances cost and recovery speed and is the most common choice for systems with moderate RTOs.
Cold Site
A cold site provides space, power, cooling, and perhaps basic network connectivity—but little or no equipment and no data. The organization must procure or ship hardware, install systems, and restore data. Recovery takes days to weeks. Cold sites are the cheapest option and suit functions with long RTOs.
Cloud and Other Options
Disaster recovery as a service (DRaaS) replicates virtual machines to a cloud provider and brings them up on demand, giving near-hot recovery at much lower cost because compute is paid for only when used. Other options include mobile sites (equipped trailers) and reciprocal agreements with another organization to share facilities, which are cheap but hard to enforce.
Site Equipment Data Recovery time Cost
Hot Fully installed and running Current (replicated)
Minutes to hours Highest
Warm Some or all hardware, partially configured Restored from backup
Hours to days Moderate
Cold Space, power, cooling only None Days to weeks Lowest
Cloud DRaaS
Provisioned on demand Replicated Minutes to hours Pay as used
Exam tip
Exam questions usually give you an RTO and a budget constraint. Choose the least expensive site that still meets the RTO. "Must resume within one hour" means hot site (or cloud DR). "Can be down for a week, minimal budget" means cold site. "Within a day or two, moderate cost" means warm site.
Environmental Considerations
The objective lists environmental factors alongside site types. A recovery site that shares the primary site's risks is no recovery site at all. Environmental considerations include:
- Geographic dispersion: the site should be far enough away that one regional event—hurricane, earthquake, wildfire, flood, or grid failure—cannot affect both sites. There is no universal distance rule; a site 10 miles away may share a floodplain, while escaping a hurricane's path may take hundreds of miles.
- Natural hazard profile: avoid floodplains, fault zones, and storm surge areas, or compensate with raised floors and seismic bracing.
- Utility independence: different power grids and different telecommunication carriers and fiber paths.
- Facility environmental controls: HVAC and humidity control, fire suppression (such as clean-agent systems), and leak detection.
- Accessibility and staffing: staff must be able to reach the site during a disaster, or it must be operable remotely.
- Legal and data sovereignty: a recovery site in another country may violate data residency requirements (Chapter 12).
- Latency: greater distance increases latency, which limits synchronous replication (typically practical only within roughly 100 km or less) and therefore affects achievable RPO.
Platform Diversity
Platform diversity reduces the chance that a single flaw, bad update, or vendor outage takes down everything at once. It is the resilience counterpart of defense in depth (Chapter 1).
Vendor Platform Diversity
Using more than one vendor for the same function means a vendor-specific vulnerability, supply chain compromise, or faulty update does not disable every instance—for example, different firewall vendors at different boundaries, a secondary DNS provider, or two ISPs. The 2024 incident in which a faulty endpoint security update crashed millions of Windows systems worldwide showed the risk of monoculture.
Hardware Diversity
Hardware diversity avoids dependence on a single model, batch, or manufacturer. Drives from one batch can fail around the same time, and a firmware bug in one switch model affects every switch of that model. Mixing models and suppliers reduces correlated failures and supply shortages.
Virtualization Diversity
Virtualization diversity applies the same reasoning to hypervisors and container platforms, where an escape vulnerability or management-plane outage affects every workload. Spreading critical workloads across platforms limits the blast radius. Virtualization also aids resilience directly through live migration, snapshots, and fast restarts on different hardware.
Common trap
Diversity has costs: more skills to maintain, more patches to track, more configurations to secure, and more complex integration. Too much diversity can reduce security if teams cannot manage every platform well. Expect the exam to treat diversity as a trade-off, applied to the most critical functions.
Redundancy
Redundancy means having extra components so that a failure of one does not stop the service. The goal is to eliminate single points of failure (SPOFs)—any component whose failure alone would cause an outage.
High Availability
High availability (HA) describes a system designed to remain operational for a very high percentage of time, usually expressed in "nines." HA combines redundancy, automatic failover, and monitoring so that component failures cause little or no interruption.
- Availability Approximate downtime per year
- 99% ("two nines") 3.65 days
- 99.9% ("three nines") 8.77 hours
- 99.99% ("four nines") 52.6 minutes
- 99.999% ("five nines") 5.26 minutes
Each additional nine typically costs significantly more. HA is usually specified in service-level agreements (Chapter 24).
Load Balancing
A load balancer distributes incoming requests across multiple servers. It improves performance by spreading work and improves availability by health-checking servers and sending traffic only to healthy ones. If one web server fails, the load balancer stops sending it requests and users continue on the others.
Load balancers use scheduling methods such as round robin, weighted round robin, and least connections, and can keep a user on one server (persistence). Two common arrangements are:
- Active/active: all nodes serve traffic simultaneously. Capacity is used efficiently, but if one node fails, the survivors must absorb its load.
- Active/passive: one node serves traffic while another waits to take over. Failover capacity is guaranteed, but the standby sits idle.
Load balancers are deployed in pairs so they do not become a SPOF themselves.
Clustering
A cluster is a group of servers that work together and appear as a single system. Clustering differs from simple load balancing in that cluster nodes share state or storage and coordinate with each other. In a failover cluster, if the active node fails, a passive node takes over its workload—including its IP address and access to shared storage—automatically. Clusters use a heartbeat to monitor each other and a quorum mechanism to prevent "split-brain," where two nodes both believe they are active and corrupt shared data.
Technique What it does Shared state? Typical use
Load balancing
Distributes requests across independent servers
Usually not Web front ends, APIs
Clustering Nodes coordinate; one takes over for another Yes (storage or state)
Databases, file servers, critical apps
Autoscaling Adds or removes instances based on demand Usually not Cloud workloads with variable load
Autoscaling
Autoscaling automatically adds compute instances (scaling out) when demand rises and removes them (scaling in) when demand falls, based on metrics such as CPU utilization, request rate, or queue length. It is native to cloud platforms and container orchestrators.
Autoscaling absorbs load spikes and, with health checks, replaces failed instances automatically. Attackers can exploit it to run up costs, so autoscaling groups need maximum limits and DDoS protection. Autoscaling is usually horizontal (more instances), in contrast to vertical scaling (a bigger machine).
Multicloud Systems
A multicloud strategy uses services from two or more cloud providers. For resilience, it protects against a provider-wide outage, a regional failure, or a contractual or business failure of one provider, and it reduces vendor lock-in. It is the cloud form of vendor platform diversity.
The trade-offs are substantial: different identity models, networking, APIs, and tooling increase complexity and misconfiguration risk, and egress charges add cost. Many organizations get much of the benefit from multiple regions or availability zones within one provider and reserve multicloud for the most critical services or backup copies.
Power Redundancy
Power is the most fundamental dependency in any facility. The objective lists four power components.
- Uninterruptible power supply (UPS): a battery-based device that provides immediate, short-term power when utility power fails, smoothing the transition to a generator or allowing a graceful shutdown. Runtime is typically minutes. UPSs also condition power against sags and brownouts.
- Redundant power supply (RPS): a server, switch, or storage array with two or more internal power supplies, ideally connected to separate circuits fed by separate power distribution units (PDUs) and UPSs. If one supply or circuit fails, the device keeps running.
- Generator: an engine-driven source (diesel, natural gas, or propane) that supplies power for hours or days during an extended outage. Generators take seconds to start and stabilize, which is why a UPS bridges the gap. An automatic transfer switch (ATS) switches the load to the generator. Generators need fuel contracts and regular load testing.
- Surge protector: a device that protects equipment from voltage spikes and surges (for example, from lightning or grid switching) by diverting excess voltage. Surge protectors do not supply power during an outage.
Figure 13.2: A redundant power path in which the UPS carries the load until the generator starts and the ATS transfers to it, with each power supply on its own UPS
Component Protects against Duration Supplies power during outage?
Surge protector Spikes and surges Instantaneous No
UPS Short outages, sags, brownouts Minutes Yes, briefly
Generator Extended outages Hours to days (fuel dependent)
Yes, after startup
Redundant power supply
Failure of one PSU or circuit Continuous Yes, via the other PSU
The exam distinguishes these by duration. "Bridge the gap until the generator starts" or "allow a graceful shutdown" means UPS. "Keep the data center running for three days during a regional outage" means generator. "Protect against a lightning strike" means surge protector. "Server stays up when one power supply fails" means redundant power supply.
Storage Resilience
Storage holds the data that everything else depends on, so it gets its own place in the objective. RAID (redundant array of independent disks) combines multiple drives to provide fault tolerance, performance, or both:
RAID level Method Minimum drives
Fault tolerance
RAID 0 Striping 2 None (any drive failure loses the array)
- RAID 1 Mirroring 2 One drive
- RAID 5 Striping with distributed parity 3 One drive
- RAID 6 Striping with double distributed parity 4 Two drives
- RAID 10 (1+0) Mirrored sets, striped 4 One per mirrored pair
RAID protects against drive failure, not against deletion, corruption, malware, or site loss. If ransomware encrypts files, RAID faithfully stores the encrypted copies on every drive. RAID is not a backup. Other storage resilience techniques include:
- Multipath I/O and redundant controllers and host bus adapters, so that a single cable or controller failure does not cut off a storage area network (SAN).
- Replication, which copies data to another array, site, or region. Synchronous replication writes to both locations before acknowledging the write, achieving an RPO near zero but requiring low latency (short distances). Asynchronous replication acknowledges locally and copies afterward, allowing long distances but accepting some data loss (RPO of seconds to minutes).
- Snapshots, point-in-time images of a volume or VM that allow fast rollback. Snapshots usually depend on the original storage, so they are not a substitute for independent backups.
- Cloud storage redundancy, such as zone- or geo-redundant storage classes.
Replication copies mistakes and malware as quickly as it copies good data. If a database is corrupted or encrypted, synchronous replication corrupts the replica within milliseconds. Replication improves availability; only versioned, isolated backups protect against logical corruption and ransomware.
Backups
Backups are the last line of defense for data. The objective lists four concepts—retention, immutability, scope, and restoration testing—and the exam also expects you to know backup types and the 3-2-1 rule.
Scope
Backup scope defines what is backed up and how: which systems and data (servers, endpoints, SaaS data, cloud configuration, identity systems), whether backups are image-level (fast full restoration) or file-level (granular restores), and the backup type:
- Type What it copies Archive bit Backup speed Restore requires
- Full Everything Cleared Slowest The full backup only
- Increment
- al
Changes since the last backup of any type
Cleared Fastest Last full plus every incremental since
Differential Changes since the last full backup
Not cleared
Moderate, grows daily
Last full plus the latest differential
Figure 13.3: Restoring Thursday from incremental backups needs the full plus every incremental, while differential backups need only the full plus the latest differential
Continuous data protection (CDP) captures every change for very low RPOs.
Memory aid
Incremental = Inexpensive to back up, Irritating to restore (many sets). Differential = Double set to restore (full plus one differential).
A common guideline is the 3-2-1 rule: keep at least three copies of data, on two different types of media or storage, with one copy off-site. Modern variants such as 3-2-1-1-0 add one copy that is offline or immutable and zero errors on verified restores.
Scope must include what is needed to use the backup, especially encryption keys stored separately; a backup whose key lived only on the encrypted server is useless.
Retention
Backup retention defines how long each backup is kept and how many versions are maintained. Retention must satisfy the RPO, recovery needs, and legal requirements (Chapter 12 covers data retention schedules and legal holds). A common scheme is grandfather-father-son (GFS): daily backups (sons) kept for a week or two, weekly backups (fathers) kept for a month or more, and monthly or yearly backups (grandfathers) kept long term.
Retention matters for security because attackers often dwell for weeks before detonating ransomware. If you keep seven days of backups and the compromise began twelve days ago, every backup may contain the attacker's foothold. Longer retention provides clean restore points from before the intrusion, at a cost in storage.
Immutability
An immutable backup cannot be modified or deleted—even by an administrator—until its retention period expires. Immutability is implemented with write once, read many (WORM) storage, object lock features in cloud storage (for example, compliance-mode object locks that even the account root cannot override), immutable backup repositories, and offline or air-gapped media such as tapes removed from the library.
Immutability is the primary defense against ransomware operators who compromise backup consoles and delete or encrypt backups before launching the main attack. It also supports legal and regulatory requirements for records that must not be altered.
A manufacturing company is hit by ransomware. The attackers had obtained domain administrator credentials, logged into the backup server, deleted all restore points on the disk repository, and then encrypted production servers. However, the company also copied nightly backups to a cloud object storage bucket with a 30-day compliance-mode object lock, managed under a separate account with its own MFA-protected credentials. The attackers could see the bucket but could not delete or overwrite the locked objects. The company restored its ERP system from the previous night's immutable copy and declined to pay the ransom.
Restoration Testing
A backup that has never been restored is a hope, not a control. Restoration testing verifies that backups are complete, uncorrupted, and restorable within the RTO. Testing should include:
- Regular automated verification of backup integrity (checksums, test mounts).
- Periodic full restores of representative systems to an isolated environment, timed against the RTO.
- Verifying that restored applications actually work, including dependencies such as authentication and DNS.
- Scanning restore points for malware before restoring them into production after an incident. Testing often reveals missing data, lost keys, undocumented dependencies, and restore times far longer than assumed.
Testing Resilience and Recovery
Plans that are not tested fail when they are needed. The objective lists three testing approaches; tabletop exercises are covered under incident response in Chapter 20 and complement these.
Failover Testing
A failover test deliberately causes a component, system, or site to fail (or switches traffic away from it) to confirm that redundant systems take over as designed. Examples include pulling a power supply, shutting down a cluster node, disabling a primary internet link, or switching production to a hot site. Afterward, failback to the primary should be tested too, because failing back is often harder than failing over.
Failover tests produce real evidence but carry real risk, so they belong in maintenance windows, approved through change management (Chapter 2).
Simulation
A simulation exercises the recovery process against a realistic scenario without actually disrupting production. Participants perform the steps they would take—activating the plan, communicating, bringing systems up in an isolated environment—while facilitators inject events ("the finance backup is unreadable"). Simulations validate procedures, roles, and communication with less risk than a full failover.
Parallel Processing
A parallel processing test brings the recovery systems online and runs them alongside the production systems, processing the same real transactions or workloads, then compares the results. Production remains the authoritative system, so there is no disruption to users, but the test proves that the recovery environment can actually handle the workload and produce correct output. Parallel tests are more expensive and complex than simulations because they require the alternate environment to be fully operational, but they are safer than a full interruption (cutover) test, in which production is actually shut down and operations move to the recovery site.
- Test Production impact Realism Cost and effort
- Tabletop (Chapter 20) None Low; discussion only Low
- Simulation None Moderate Moderate
- Parallel processing None; both run High High
Failover / full interruption Yes; production switches Highest High, with risk
Exam tip
Key phrases: "both the primary and the recovery site process the same transactions" means parallel processing. "Production is shut down and operations move to the DR site" means a full interruption or failover test. "A scenario is walked through with injected events, without touching production" means simulation or tabletop.
Disaster Recovery
Disaster recovery (DR) is the set of policies, plans, and procedures for restoring IT systems, data, and infrastructure after a disruptive event. DR is technology-focused and is one part of the broader business continuity effort. A disaster recovery plan (DRP) (Chapter 22) typically includes:
- Systems covered, with their RTOs and RPOs.
- Recovery priority order, so that dependencies such as identity services, DNS, and networking come up before the applications that need them.
- Who can declare a disaster, plus roles and contact lists.
- Step-by-step recovery runbooks, communication plans, and procedures for returning to the primary site.
DR plans for cyber events differ from those for natural disasters. After ransomware, you cannot simply restore and reconnect: you must identify a clean restore point, rebuild compromised identity systems, reset credentials, and ensure the attacker's access is gone before bringing systems back. This is why DR planning and incident response (Chapter 20) must be coordinated.
Business Continuity
Business continuity (BC) is the broader capability to keep essential business functions running during and after a disruption, including but not limited to IT. A business continuity plan (BCP) covers people, facilities, processes, suppliers, and communications as well as technology. Continuity of operations planning (COOP) is the equivalent term used by U.S. government agencies.
Business continuity planning typically follows these steps:
- 1. Conduct a business impact analysis to identify critical business functions, their dependencies, the impact of disruption over time, and their MTD, RTO, and RPO.
- 2. Identify risks and threats to those functions.
- 3. Develop recovery strategies, including alternate sites, alternate suppliers, manual workarounds, and remote work arrangements.
- 4. Document the plan and assign roles.
- 5. Train staff, test the plan, and maintain it as the business changes.
It also includes succession planning and manual workarounds such as paper forms when a system is down.
Aspect Business continuity Disaster recovery
Focus Keeping critical business functions running Restoring IT systems and data Scope People, processes, facilities, suppliers, technology Technology and infrastructure Timing During and after disruption After disruption
Relationship The umbrella A component of BC
Note
On the exam, if the scenario is about keeping the business functioning—staff working from another location, paper-based procedures, alternate suppliers—think business continuity. If it is about restoring servers, applications, and data, think disaster recovery.
Capacity Planning
Capacity planning ensures that the organization has enough resources to meet current and expected demand, both in normal operations and during a disruption. Resilience fails if the recovery environment cannot handle the load, if surviving nodes in an active/active cluster are overwhelmed when one fails, or if there are not enough trained people to execute the recovery. Capacity planning covers three areas:
- People: enough trained staff, cross-trained so no individual is a single point of failure, with runbooks that reduce dependence on specific people.
- Technology: sufficient compute, storage, and licensing. In an active/active pair, each node must carry the full load alone, so each should normally run well under 50 percent. DR environments must be sized for the production workload.
- Infrastructure: power, cooling, space, and bandwidth at both sites. A replication link too small for the day's changes cannot meet the RPO.
Capacity planning uses utilization trends, growth forecasts, and failure modeling, and also prepares for surges such as seasonal peaks or a sudden shift to remote work.
Real-world scenario
An online retailer runs two web servers in an active/active configuration, each averaging 70 percent CPU utilization during the holiday season. When one server fails a hardware check on Black Friday, the load balancer correctly moves all traffic to the survivor, which immediately saturates and begins timing out. The redundancy worked; the capacity planning did not. The fix is to add a third node or enable autoscaling so that the remaining capacity after any single failure still exceeds peak demand (an "N+1" design).
Chapter Summary
- Resilience keeps services running through failures; recovery restores them after disruptions resilience cannot absorb.
- RTO is maximum acceptable downtime; RPO is maximum acceptable data loss measured in time; MTTR is average repair time (lower is better); MTBF is average time between failures (higher is better). Availability is approximately MTBF / (MTBF + MTTR).
- Hot sites are fully operational with current data (fastest, most expensive); warm sites have partial equipment and need data restored; cold sites offer only space and power (slowest, cheapest). Environmental factors such as geographic dispersion and natural hazards determine placement.
- Platform diversity across vendors, hardware, and virtualization prevents a single flaw or bad update from affecting everything, at a cost in complexity.
- Redundancy removes single points of failure: load balancing distributes requests, clustering provides coordinated failover with shared state, autoscaling adjusts capacity automatically, high availability targets "nines," and multicloud guards against provider outages.
- Power resilience uses surge protectors (spikes), UPS (short outages and bridging), generators (extended outages), and redundant power supplies (component failure).
- Storage resilience uses RAID, multipathing, replication (synchronous for near-zero RPO, asynchronous for distance), and snapshots—but RAID and replication are not backups.
- Backups need appropriate scope (full, incremental, differential; keys and configurations included), retention long enough to predate an intrusion, immutability to resist ransomware, and regular restoration testing. Follow the 3-2-1 rule.
- Testing includes failover (actually switching), simulation (realistic exercise without disruption), and parallel processing (recovery systems run alongside production).
- Disaster recovery restores IT; business continuity keeps the whole business running; capacity planning ensures enough people, technology, and infrastructure to operate normally and during failures.
Key Terms
Resilience; recovery; business impact analysis; recovery time objective (RTO); recovery point objective (RPO); maximum tolerable downtime (MTD); mean time to repair (MTTR); mean time between failures (MTBF); mean time to failure (MTTF); hot site; warm site; cold site; disaster recovery as a service (DRaaS); geographic dispersion; platform diversity; vendor diversity; single point of failure; high availability; load balancing; active/active; active/passive; persistence; clustering; heartbeat; quorum; autoscaling; horizontal scaling; vertical scaling; multicloud; availability zone; uninterruptible power supply (UPS); redundant power supply (RPS); generator; automatic transfer switch; surge protector; RAID; multipath I/O; synchronous replication; asynchronous replication; snapshot; full backup; incremental backup; differential backup; continuous data protection; 3-2-1 rule; backup retention; grandfather-father-son; immutable backup; WORM; air gap; restoration testing; failover; failback; simulation; parallel processing; full interruption test; disaster recovery plan; business continuity plan; COOP; capacity planning; N+1.
Review Questions
- 1. A company's BIA states that the customer portal must be restored within two hours of an outage and that the business can tolerate losing no more than five minutes of transactions. Which metrics are described, respectively?
- A. RPO; RTO
- B. RTO; RPO
- C. MTTR; MTBF
- D. MTBF; MTTR
- 2. A small nonprofit can tolerate up to two weeks of downtime for its back-office systems after a disaster and has a very limited budget. Which recovery site option is MOST appropriate?
- A. Hot site
- B. Warm site
- C. Cold site
- D. Active/active multicloud deployment
- 3. Attackers who compromised domain administrator credentials deleted all backups on an organization's backup server before deploying ransomware. Which backup characteristic would have MOST directly prevented this?
- A. Incremental backup type
- B. Immutability
- C. Synchronous replication
- D. RAID 6
- 4. A data center manager needs to keep servers running during the 10 to 15 seconds it takes for the backup generator to start and stabilize after a utility outage. Which component addresses this need?
- A. Surge protector
- B. Redundant power supply
- C. UPS
- D. Automatic transfer switch
- 5. An organization runs its recovery environment alongside production for a week, feeding both the same live transactions and comparing outputs, while production remains the system of record. Which type of test is this?
- A. Tabletop exercise
- B. Parallel processing
- C. Full interruption
- D. Failover
- 6. A security architect notices that every firewall, VPN concentrator, and endpoint agent in the company comes from a single vendor, and that one faulty update could disable all of them. Which resilience concept addresses this concern?
- A. Capacity planning
- B. Platform diversity
- C. Clustering
- D. Backup scope
- 7. A storage array is configured with RAID 5. An administrator claims that the organization no longer needs backups for the data on it. Why is this claim incorrect?
- A. RAID 5 does not tolerate any drive failures.
- B. RAID 5 does not protect against deletion, corruption, or ransomware.
- C. RAID 5 requires synchronous replication to function.
- D. RAID 5 can only be used with tape backups.
- 8. A company performs a full backup every Sunday and a backup every weeknight that copies only the data changed since the previous night's backup. The server fails on Thursday morning. Which backups are needed to restore it?
- A. Sunday's full backup only
- B. Sunday's full backup and Wednesday's backup only
- C. Sunday's full backup and the Monday, Tuesday, and Wednesday backups
- D. Wednesday's backup only
- 9. Two web servers behind a load balancer each run at 75 percent utilization during peak hours. One fails, and the remaining server becomes unresponsive. Which activity was MOST likely inadequate?
- A. Restoration testing
- B. Capacity planning
- C. Data retention
- D. Geographic dispersion
- 10. Which of the following BEST describe the relationship between business continuity and disaster recovery? (Select TWO.)
- A. Disaster recovery focuses on restoring IT systems and data.
- B. Business continuity is a subset of disaster recovery.
- C. Business continuity addresses people, processes, facilities, and suppliers as well as technology.
- D. Disaster recovery plans do not need to define recovery priorities.
- E. Business continuity applies only to natural disasters.
- 11. A component has an MTBF of 4,990 hours and an MTTR of 10 hours. What is its approximate availability?
- A. 98.0%
- B. 99.0%
- C. 99.8%
- D. 99.99%
- 12. A financial firm requires near-zero data loss for its trading database and also wants protection from a regional disaster. Which design choices BEST meet these requirements? (Select TWO.)
- A. Synchronous replication to a nearby secondary data center
- B. Weekly full backups stored on-site
- C. Asynchronous replication or immutable backups to a distant region
- D. RAID 0 on the primary database server
- E. A cold site in the same city
Answers and Explanations
- 1. B. The two-hour restoration requirement is the recovery time objective (how long the system can be down), and the five-minute data loss tolerance is the recovery point objective (how much data can be lost). MTTR and MTBF describe repair time and reliability of components, not business tolerances.
- 2. C. A cold site provides space and power at the lowest cost, which fits a two-week tolerance and a limited budget. Hot and warm sites cost more than necessary for this RTO, and an active/active multicloud deployment is far more expensive and complex.
- 3. B. Immutable backups cannot be modified or deleted, even by administrators, until their retention period expires, which defeats attackers who target backups. The backup type (incremental) does not prevent deletion. Synchronous replication would replicate the damage. RAID 6 protects against drive failure, not deliberate deletion.
- 4. C. A UPS provides immediate battery power to bridge the gap until the generator takes the load. A surge protector only blocks spikes. A redundant power supply protects against the failure of one PSU, not the loss of utility power. An automatic transfer switch switches the load to the generator but does not supply power during the startup gap.
- 5. B. Running the recovery environment alongside production on the same workload, without disrupting production, is a parallel processing test. A tabletop is discussion-only. A full interruption test shuts down production. A failover test actually switches service to the redundant system.
- 6. B. Platform diversity—specifically vendor diversity—ensures that a single vendor flaw or bad update does not disable every control at once. Capacity planning concerns having enough resources, clustering provides failover among nodes, and backup scope concerns what is backed up.
- 7. B. RAID provides fault tolerance against drive failure only. Deleted files, corrupted data, and ransomware-encrypted files are written to the array like any other data. RAID 5 tolerates one drive failure, does not require replication, and has no relationship to tape.
- 8. C. Backups that copy changes since the previous backup of any type are incremental, so restoration requires the last full backup plus every incremental since then: Monday, Tuesday, and Wednesday. Option B describes a differential strategy.
- 9. B. In an active/active design, each node must be able to carry the full load if the other fails. At 75 percent each, the combined load (150 percent of one server) exceeds a single server's capacity. This is a capacity planning failure. Restoration testing, retention, and geographic dispersion do not address load after a node failure.
- 10. A, C. Disaster recovery focuses on restoring technology, and business continuity is the broader effort covering people, processes, facilities, suppliers, and technology. Disaster recovery is a component of business continuity, not the other way around. DR plans must define recovery priorities, and business continuity applies to all kinds of disruptions, including cyberattacks.
- 11. C. Availability = MTBF / (MTBF + MTTR) = 4,990 / 5,000 = 0.998, or 99.8 percent. The other values do not match the formula.
- 12. A, C. Synchronous replication to a nearby site achieves near-zero RPO, because writes complete at both locations before acknowledgement. Because synchronous replication is limited by distance, protection from a regional disaster requires an additional copy in a distant region via asynchronous replication or immutable backups. Weekly on-site backups give a poor RPO and no regional protection, RAID 0 has no fault tolerance, and a cold site in the same city shares regional risk and recovers slowly.
- P A R T 4
- Part 4: Security Operations
- Domain 4.0 — 27% of the exam
This part covers the day-to-day work of defending an organization, the largest domain on the exam. It begins with the mitigating controls that harden and protect the environment, then moves through asset management, vulnerability
management, alerting and monitoring, identity and access management,
automation and AI-assisted operations, incident response, and the data sources and artifacts that support a security investigation. Expect many scenario-based and performance-based questions from this domain.