Legacy Haven University

High availability (HA) keeps a service reachable when a node, a path, or a site fails. CompTIA Security+ (SY0-701) tests that idea under Domain 3.0 Security Architecture (18% of the exam): 3.1 lists HA as an architecture concept, 3.2 lists the load balancer, and 3.4 asks you to explain HA as load balancing vs. clustering, then place that design next to site type, capacity, testing, backups, and power.

Study the named bullets on the CompTIA Security+ (SY0-701) path in the 2026 Security+ hub.

What “available” means on this exam

The CIA triad is Confidentiality, Integrity, and Availability. Availability is the property that authorized users can use the system when they need it. Cree’s hub states the same job in operational language: architects keep availability by deploying redundant infrastructure, load balancers, and failover clustering against denial-of-service and hardware loss.

High availability is the architecture that makes that property hold during a single failure. It is not a backup. A backup restores data after loss. HA keeps the service running while a component dies.

Objective 3.1 pairs HA with design considerations you must be able to trade off: availability, resilience, cost, responsiveness, scalability, ease of deployment, risk transference, ease of recovery, patch availability, inability to patch, power, and compute.

Those are exam words. Use them.

Load balancing vs. clustering

Objective 3.4 prints one contrast: load balancing vs. clustering. That is the comparison the item writers can score.

Clustering groups two or more hosts so they present one service. Members share the workload or stand ready to take it. The client talks to the cluster identity, not to a single box. When one member fails, remaining members continue the service. Cree’s hub describes the same pattern as clustering compute resources so the architecture survives hardware failure.

Load balancing sits in front of separate servers and spreads requests across them. Objective 3.2 names the load balancer as a network appliance next to jump servers, proxies, and IPS/IDS. The backend servers do not have to know about each other. The balancer decides who gets the next request.

Remember the difference in one line:

• Clustering: members act as one service.
• Load balancing: an appliance distributes work to members that stay independent.

You can run both. A cluster can sit behind a load balancer. The exam still wants you to tell the two mechanisms apart.

Cree’s hub also writes “Layer 4 / Layer 7 load balancers.” Official 3.2 lists Layer 4 / Layer 7 under firewall types, not as load-balancer sub-bullets. Treat OSI-layer load-balancer detail as teaching language, not as a printed SY0-701 sub-objective.

Active-Active and Active-Passive are not SY0-701 bullets

The calendar title uses two cluster modes:

• Active-Active: every member takes live traffic at the same time.
• Active-Passive: one member takes live traffic; the other waits and takes over on failure.

CompTIA prints those mode names on Server+ clustering objectives, not on SY0-701. On Security+, do not treat the mode names as official vocabulary. If a scenario describes both nodes serving users, you are looking at concurrent capacity. If a scenario describes a standby that becomes live after a failure, you are looking at failover. Map the behavior to clustering and high availability, then stop. Do not invent product commands, heartbeat ports, or quorum math. Those facts are not in the SY0-701 list.

Do not confuse 3.2 “Active vs. passive” with cluster modes

Objective 3.2 lists device attribute: Active vs. passive and Inline vs. tap/monitor. That pair describes how a security appliance sits on the wire. An active, inline device can block. A passive tap/monitor device watches a copy of traffic. It is not a statement about cluster membership.

If a question says “active vs. passive” next to IDS/IPS or tap/monitor, answer the appliance attribute. If a question says clustering or load balancing, answer 3.4 HA.

Failure modes that decide what users see

HA only works if you know what the device does when it dies. Objective 3.2 names two failure modes:

• Fail-open: the device lets traffic through after it fails. Users keep working. Inspection stops.
• Fail-closed: the device blocks traffic after it fails. Users lose the path. Unauthorized traffic does not pass an uncontrolled gap.

A load balancer or cluster member that fail-closes can protect a sensitive zone and still take the service down. A path that fail-opens keeps availability and drops a control. The exam wants that trade visible. Availability is one CIA letter. It is not a free pass to leave a control off.

Sites, power, and capacity keep the cluster honest

A two-node cluster in one rack is not a site strategy. Objective 3.4 places HA next to site considerations: hot, warm, cold, and geographic dispersion. A hot site is already running and can take the load quickly. A warm site is partly ready. A cold site is space and power with little or no live stack. Geographic dispersion puts copies far enough apart that one flood, one grid event, or one building loss does not kill every node.

The same objective names the rest of the support stack:

• Platform diversity and multi-cloud systems so one vendor or one cloud control plane is not the only path.
• Continuity of operations so the business function survives the outage, not only the VM.
• Capacity planning across people, technology, and infrastructure. A cluster with no spare compute is a single point of failure with extra cables.
• Power: generators and uninterruptible power supply (UPS).
• Backups: onsite/offsite, frequency, encryption, snapshots. HA does not replace a recoverable copy. Cree’s hub treats snapshots and isolated or air-gapped cold copies as the rebuild path after ransomware. That is recovery language, not live HA.

Testing is how you prove failover

Objective 3.4 lists the tests: tabletop, failover, simulation, and parallel processing. A design that nobody fails over is a drawing. Failover testing moves the live service to the standby path and checks that clients still reach it. Parallel processing runs the alternate path at the same time as production so you can compare results before you cut over. Tabletop walks the people through the runbook without touching production.

If you cannot describe the test, you cannot claim the architecture is resilient.

How this maps to SY0-701

Use this list when you review. Do not add product names the document does not print.

Official lists are not exhaustive. CompTIA says other examples can appear. That sentence does not give you license to treat Active-Active as a printed 3.4 bullet.

Work the official contrast first: load balancing vs. clustering, then site type, capacity, power, backups, and a failover test. When you want the domain map in one place, use the Security+ SY0-701 guide.