Built to Survive: High Availability, Backups, and Power, the Half of Security+ Domain 3 Nobody Studies
Chris Rees
25+ years in IT · Pluralsight author, 4.6/5 across 2,000+ ratings
Confidentiality gets the headlines and integrity gets the cryptography, but the outage is what gets the CEO's attention. Objective 3.4 of Security+ is the availability objective, and it is the one candidates skim because it feels like operations rather than security. The exam disagrees. Resilience questions are built from a small set of design choices and a smaller set of numbers, and once you can see the trade-off in each one, they are among the most predictable on the test.
Availability is a design property
You cannot patch your way to availability. It comes from deciding, in advance, what happens when a component fails, and the outline organizes those decisions into a handful of themes: redundancy, site and platform diversity, backups, power, capacity, and testing. Each theme is a trade between cost and how long the business is down.
The two numbers that frame every decision are borrowed from continuity planning: the recovery time objective, how quickly service must be back, and the recovery point objective, how much data you can afford to lose. Every control in this objective is a way of buying a shorter one of those.
Redundancy: no single point of failure
High availability starts with the question "what happens if this fails?" asked about every component. Load balancing spreads requests across several servers and stops sending to one that fails. Clustering goes further: nodes share state, so a failed node's work continues rather than restarts. The distinction the exam draws is that a load balancer distributes independent requests, while a cluster presents several nodes as one system.
Active-active versus active-passive is the pattern to know cold. Active-active runs everything live and shares the load, which gives you capacity as well as tolerance, at the cost of every node needing to handle the full load alone if the other fails. Active-passive keeps a standby idle, which is cheaper and simpler but wastes the standby's capacity and introduces a failover delay. A stem that says the service cannot tolerate even a brief interruption wants active-active. One that emphasizes cost wants active-passive.
Redundancy also applies at the network layer (dual links, dual switches, dual providers), and the exam likes multipath and NIC teaming as the terms for a server that survives the loss of one cable.
Site and platform diversity
Two identical systems in one building share a flood. The outline lists geographic dispersion as the answer: sites far enough apart not to share a disaster, connected well enough to fail over between. The hot, warm and cold site vocabulary lives here too, and the trade is the same as everything else in this objective: a hot site costs the most and recovers fastest.
Two subtler ideas carry marks. Platform diversity means not running everything on one vendor's operating system, hypervisor or hardware, so a single vulnerability or a single bad update cannot take down the whole estate. Multi-cloud is the same idea applied to providers. And continuity of operations (COOP) is the plan for keeping the business functioning, including the manual workarounds, while the technology is recovered. A COOP question is about the business, not the servers.
Backups: the full, incremental, differential trade
This is the most reliably tested part of the objective, and it is entirely a trade between how much you store each day and how many steps a restore takes.
| Strategy | Backs up | Daily storage | Restore needs | Choose when |
|---|---|---|---|---|
| Full | everything | largest | the latest full only | restore speed matters more than anything |
| Differential | changes since the last full | grows each day | last full plus latest differential | a balance of both |
| Incremental | changes since the last backup of any kind | smallest | last full plus every incremental since | storage and backup window are the constraint |
The stem tells you which to pick by naming the constraint. "The backup window is too short" or "storage costs are the concern" wants incremental. "Restores must be as fast as possible" wants full or differential. And a question that describes a restore failing because one of the sets in the chain was corrupted is describing the specific weakness of incremental backups: every link has to be good.
Beyond the big three, the outline lists snapshots (a point-in-time image of a volume or virtual machine, fast to take and fast to revert, but stored alongside the thing they protect), replication (a continuous copy to another system, which gives a near-zero RPO but faithfully replicates a deletion or an encryption), and journaling (a log of every change, which allows recovery to any point rather than to the last backup). The exam's favorite trap is replication offered as a backup: it is not, because whatever destroys the primary reaches the replica seconds later. And every copy needs encryption, because a backup is the most concentrated copy of your data that exists.
Onsite versus offsite is the last dimension: onsite copies restore fastest and share the building's disasters, offsite copies survive the building and take longer to retrieve. The answer the exam likes is both, with frequency set by the RPO.
Power
Servers do not care about elegance; they care about electrons. An UPS carries the load for minutes: long enough to ride through a flicker or shut down cleanly. A generator carries it for as long as there is fuel, but takes seconds to start, which is exactly the gap the UPS exists to cover. The two are a sequence, not alternatives, and a question that offers a generator as the answer to a five-second power dip is testing whether you know that.
Dual power supplies in a server and dual feeds into the building extend the same "no single point of failure" logic to the utility. Everything above the power layer is irrelevant if the power layer fails.
Capacity planning: the question hiding in a story
The outline lists capacity planning under three headings: people, technology, and infrastructure. Candidates expect the infrastructure question (do we have enough disk, bandwidth and compute for growth?) and get caught by the people one. A stem describing a security team that cannot cover a second shift, or a single administrator who holds every credential, is a capacity planning problem: the organization does not have the human capacity to sustain the control. The answer is usually cross-training, documentation or an additional hire, not a new tool.
Traps the exam sets, and RAID is one of them
A few resilience facts are tested precisely because intuition gets them wrong.
RAID is not a backup. Redundant disks protect against a disk failing, and nothing else. A deleted file is deleted on every disk in the array at the same instant, and ransomware encrypts the mirror as happily as the original. RAID is a high availability control for storage; the backup is what protects the data. A question offering RAID as the answer to "how do we recover from an accidental deletion" is a trap.
A snapshot on the same storage as the data is not off-site protection. It is a fast undo. If the array fails, the snapshots fail with it.
Replication propagates mistakes at the speed of the link. It is the right answer for a near-zero RPO against hardware failure, and the wrong answer for protection against corruption, deletion or encryption, all of which it faithfully copies. The exam's phrasing is usually a question about which control would have protected against a specific event, and replication only protects against the loss of the primary system.
Geographic dispersion has to be far enough. Two data centers on the same floodplain are one data center for continuity purposes. The scenario will describe two sites that both went dark in the same regional event.
The generator needs fuel and a test. A generator that has never been load-tested is a hypothesis with a diesel tank. Regular testing under load is listed under the same objective for that reason.
Testing what you built
None of it counts until it has been exercised. The outline names tabletop exercises, failover tests, simulations and parallel processing, in roughly ascending order of risk and realism. The rule is the same one the continuity planners use: start with the least disruptive test, and never run a live failover without the approval of the people who will answer for the outage if it goes wrong.
Key takeaways
- Availability is designed, not patched. Every control in 3.4 buys a shorter RTO or RPO at a price.
- Active-active shares load and tolerates instantly; active-passive is cheaper with a failover gap. Load balancers distribute, clusters share state.
- Full restores fastest, incremental stores least, differential sits between. The constraint in the stem picks the strategy; a broken incremental chain is the classic failure.
- Replication is not a backup and snapshots live with the data they protect. Encrypt every copy and keep one offsite.
- UPS covers seconds to minutes, generators cover hours, and they run in sequence. Capacity planning includes people, not just disks.
Resilience and recovery is objective 3.4 of Security+ Domain 3, Security Architecture, and it is the availability counterpart to the data protection methods and network design the same domain covers. Work all 26 Domain 3 topics with our Security+ Domain 3 study guide.
#SecurityPlus #SY0701 #Resilience #HighAvailability #Backups #DisasterRecovery #BusinessContinuity #LoadBalancing #CompTIA #CyberSecurity
Master Security Architecture
Data protection is one module of four in Security+ Domain 3. Study all 26 topics (architecture models, enterprise infrastructure, data protection, and resilience) with our objective-mapped guide.
Get the Domain 3 guideKeep reading
SPF, DKIM, DMARC, and Friends: The Enterprise Security Capabilities Security+ Expects You to Configure
Objective 4.5 is where Security+ stops asking what a control is and starts asking where it goes. Email authentication drawn as one flow (SPF checks the sender, DKIM signs the message, DMARC decides what happens), web and DNS filtering, DLP and what it can actually see, EDR versus XDR, NAC posture checks, file integrity monitoring, and the placement map that answers every scenario in the objective.
Read Security+ deep divesOn-Prem to Serverless: Architecture Models, the Line That Moves, and the Twelve Considerations Security+ Scores Them By
Objective 3.1 reads like a glossary, but the exam never asks for a definition. It describes a workload, names a constraint, and asks which model fits or which risk you accepted. Every model as one decision about how much of the stack you control: the responsibility line from on-prem to SaaS, IaC, serverless and microservices, air gap versus VLAN versus SDN, hypervisor versus kernel, the devices you cannot patch, and the twelve considerations that turn a stem into a rubric.
Read Security+ deep divesRansomware, Rootkits, and Logic Bombs: Malware Types and the Indicators Security+ Expects You to Spot
Objective 2.4 is the longest list in Security+ and the one that turns into the most scenario questions. Malware classified by how it spreads and what it does, the attack families beyond malware, and the nine indicators of malicious activity, from impossible travel to missing logs, that tell you which attack a stem is describing before you read the answers.
ReadEnjoyed this? Get the AI security news that matters.
Join The AI Security Brief for the top AI security news, plus what's important to the C-suite. Free, straight to your inbox.
No spam. Unsubscribe anytime.