The acronym appendix at the back of the SY0-701 objectives lists more than three hundred entries. People often suggest memorizing it, and every study group has someone printing it out. That advice misreads what the exam does with acronyms.
SY0-701 rarely tests what an acronym means. Instead, it gives you a short scenario and four options, two of which are acronyms from the same area, and asks which one fits the scenario. Knowing that RPO expands to recovery point objective doesn't help much on that question. Understanding that RPO measures lost data while RTO measures lost time gets you the answer in about four seconds.
So, the useful way to study is by cluster rather than alphabetically. A cluster is a small group of acronyms sitting close enough together that a question writer can build a believable wrong answer out of one of them. How many are there? Maybe fifteen in the whole exam. Here are five of the most common ones, with the objective each sits under, so you can read the source material.
The four recovery numbers
Objective 5.2 covers all four under business impact analysis; RPO and RTO also appear in 3.4 with resilience and recovery. Two of them are business targets. The other two are post-event observations. That split is the whole cluster. Learn it and the four stop blurring.
RPO looks backward. How much data can you afford to lose? That makes it about backup frequency. RTO looks forward. How long can you afford to be down? Which is a claim about recovery capability, not about backups. MTTR is the average repair time. MTBF is the time between failures.
The stem usually gives it away. Read it twice. A sentence about hourly snapshots points at RPO, and one about a four-hour outage window points at RTO. If the sentence describes something that already happened rather than a business decision, you are in MTTR and MTBF territory.
Federation, and why one of these is not authentication
Objective 4.6 puts SAML, OAuth and OIDC on one line with Kerberos, LDAP and RADIUS. The trap is that people learn the first three as single sign-on protocols and then mix them up under pressure. All three are very commonly confused.
SAML and OIDC both carry identity. They answer who this person is. OAuth on its own does something else. It answers what an application is allowed to reach (authorization), and it was built to let an app touch your data without handing over your password. OIDC sits on top of OAuth 2.0 and adds the identity layer that OAuth left out.
So, a stem describing a third-party app getting limited access to an account points at OAuth, even when the word login appears somewhere in the sentence. A browser redirected to a corporate identity provider, coming back with an assertion? SAML.
The agreement alphabet
Objective 5.3 covers third-party risk, and this might be the least loved cluster; it feels like paperwork rather than security. It is also the one where every option in the question is a real document and only one of them fits the sentence you were given. Read the sentence, not the options.
An SLA carries numbers: uptime and response time, with a penalty for missing the number. An MOU only records that two parties intend to work together, and it is generally not built to be enforced. An MSA sets the terms of a long relationship, while the SOW underneath it says what this particular job is and when it is due. An NDA is about confidentiality and nothing else. A BPA governs a partnership where both parties carry real risk if it goes wrong.
Severity is not priority
CVSS, EPSS and KEV all sit in 4.3. CVSS rates how bad a vulnerability would be if exploited. EPSS estimates how likely exploitation is. KEV is a catalog of vulnerabilities already being exploited in the wild.
Any question that gives you a patch queue and asks what to fix first checks whether you spotted that a severity score alone doesn't set the order. A high CVSS on something nobody is exploiting can wait. A medium that appears on the KEV list goes first.
Four ways to test code
Also in 4.3. This is the cleanest cluster of the five. SAST reads source without running it. DAST attacks the running application and sees nothing of the source. IAST instruments the running application to see both. SCA ignores your code entirely and looks at what it depends on.
The discriminator is almost always in the first clause of the stem. Third-party library with a known vulnerability? That is SCA. No source available means DAST, and a scan that runs before the build has been deployed anywhere is SAST.
How to actually drill this
Reviewing a cluster by reading it is the trap. That is the whole warning. A comparison table feels productive, and what it trains is recognition, an easier skill than the one being tested.
The version that works is slower and more annoying. For each pair in a cluster, write one sentence that only one of the two can answer. Then cover the labels and read your own sentences back. If you wrote a sentence that both acronyms could satisfy, you found the exact gap the question writer is going to aim at, and you found it at your desk instead of in the testing center.
A last word on that appendix. Treat it as a scope boundary; some entries appear only once, in one sub-bullet of one objective. The clusters are where the questions live, and the fastest way to find the rest is to read CompTIA's published exam objectives and look for lines where three or four related acronyms are grouped together. If you would rather practice this the way the exam asks it, there is a free performance-based question here that needs no account. Full disclosure: I built that one.
Top comments (0)