Objective 3.4 looks like the easiest thing in Domain 3. Hot sites and cold sites. Load balancing. Clustering. Backups. Most people skim that list, decide it is vocabulary, and go spend the evening on cryptography instead.
Then a scenario shows up about a data center that just went dark, with four answer options that are all genuine resilience controls, and the vocabulary does nothing for you. The question was never asking what the words mean.
Domain 3 is 18 percent of SY0-701 and resilience is a real slice of it. What follows is the part that turns the objective from a memorization list into something you can reason through on the day.
Sort by what the control does to a failure
Every term in 3.4 answers one of three questions.
Does this keep me running while something breaks? High availability lives here. So do load balancing and clustering. Platform diversity and multi-cloud belong in the same pile.
Will it get me back after I am already down? Recovery sites and geographic dispersion. Backups too.
Can I keep serving people while I am still down? That is continuity of operations, and it is the bucket everybody forgets.
Read the stem, decide which of those three it is describing, then cross off every option sitting in the other two before you compare anything. On a lot of these questions that one step leaves you with two options instead of four.
Load balancing and clustering are not the same shape
Here is the pair that quietly costs people points. Both of them put several servers behind one workload, and both of them sound like more servers.
Load balancing puts one device out front. The load balancer takes incoming requests and distributes them across individual servers that are otherwise doing their own thing. The servers stay separate. Something in front of them is making a choice about traffic.
Clustering is servers configured to work together as one big server, and you can add and remove members while the cluster is running. There is no traffic cop out front. The systems themselves are the single logical thing.
So the tell is the noun the stem picks. If the scenario is about distributing requests or sessions, it wants load balancing. If it is about several machines presenting as one system, or about growing capacity without taking that system offline, it wants clustering.
The same warning covers platform diversity and multi-cloud. Platform diversity is running different operating systems for different purposes, so one OS-specific vulnerability cannot take everything at once. Multi-cloud is running application services across more than one provider, so one provider's outage is not automatically your outage. Both are diversity. One is diversity of software. The other is diversity of vendor.
Recovery sites get described, not named
Nobody writes a question that says which of these is a warm site. They write a paragraph about budget and downtime and let you work it out.
A hot site is an exact replica of your data center, synchronized and ready now. A cold site is an empty building, and you are moving staff and equipment in before anything runs. A warm site sits between them, with some equipment already there.
What makes the question work is that those labels are a cost curve. Hot costs the most to sit idle and the least when you actually need it. Cold is the reverse. So a stem leaning on a tight recovery window is pointing at hot, while limited budget plus an acceptable multi-day outage is pointing at cold. Neither one will use the word.
Geographic dispersion rides along with all of this and scores as its own point. Putting the recovery site a significant distance away is what stops the same storm or grid failure from taking both at once. A perfect hot site in the same industrial park as the primary is still one bad afternoon away from nothing.
The answer that looks too unserious to pick
Continuity of operations is the option people rule out on instinct.
It is the nontechnical fallback. The manual process. The paper form. A phone call to the customer. When three options are technical and the fourth is staff switching to paper order forms, the technical ones really do feel more like security answers.
They are not. Not once the scenario has already told you the systems are down. What that bucket describes is simply what the business does during an outage, and it is a legitimate answer whenever the stem cares about the business continuing rather than the system recovering. Read for which one the question is tracking, the servers or the customers.
How to drill this
For every term on the 3.4 list, answer two questions out loud. What failure does this survive? And what does it cost me on an ordinary day when nothing is failing?
The second question separates them, because that cost is what CompTIA builds the scenario around. Hot sites cost money continuously. Clustering costs complexity. Multi-cloud costs you a second set of everything to administer. Capacity planning sits on the same objective for the same reason, and it starts with people rather than hardware, which is the part that actually catches people out. You can scale servers in an afternoon. Trained staff do not scale in an afternoon.
Then take one pass over the testing methods, because they are cheap points. A tabletop exercise is the team walking through the recovery plan together around a table. A failover test means actually flipping over to the redundant configuration to see whether it takes the load. A simulation runs a scripted event, something like a phishing test or a password reset process. Parallel processing tends to be the one that throws people, and it refers to multiple processors or processes handling transactions at the same time.
If you want to know whether this domain is genuinely costing you points or you just feel shaky on it, the free diagnostic at secplusmastery.com/diagnostic breaks your result out by domain, and the architecture lessons and labs at secplusmastery.com work through the rest of Domain 3 the same way.
Resilience questions reward one habit over everything else. Decide what is failing before you decide what fixes it.
Top comments (0)