CompTIA Server+ common mistakes
CompTIA Server+ · Understand the traps and how to avoid them.
Picking a RAID level by matching a keyword in the stem ("performance" → RAID 5, "redundancy" → RAID 1) instead of computing usable capacity, fault tolerance, and rebuild behaviour for the stated drive count.
Candidates memorize a one-line definition per level and never practise the arithmetic, so any question that changes drive count, drive size, or adds a hot spare breaks the pattern match.
What to do instead
Before answering, write down usable capacity = (drives − parity drives) × drive size, tolerable failures, and read/write penalty for RAID 0/1/5/6/10. Drill five scenarios with 4, 6, and 8 drives plus a hot spare until the calculation is automatic.
Recommending a maintenance window or server shutdown to replace a fan, a drive in a redundant array, or one of two power supplies, and conversely assuming RAM or a CPU can be swapped on a live server.
The phrase "replace the failed component" triggers a generic shutdown answer, because the candidate never separated hot-swap from cold-swap components during study.
What to do instead
Memorize the hot-swap list (drive bays in a backplane, redundant PSUs, chassis fans, some PCIe cards) versus the cold-swap list (CPU, memory modules, motherboard, non-redundant PSU). When a stem names a component, classify it first, then choose the procedure.
Describing DHCP scopes, exclusions, and reservations as interchangeable, and choosing the wrong DNS record type (A when a reverse lookup is asked for, CNAME when a mail server is being pointed at, TXT when a hostname needs resolving).
These services appear in almost every scenario, so candidates skim the objectives believing they already know them, and the distinctions blur under time pressure.
What to do instead
Build a two-column table before exam day: DHCP (scope = pool, exclusion = addresses inside the pool never handed out, reservation = permanent lease bound to a MAC, lease = duration) and DNS (A/AAAA = forward, PTR = reverse, CNAME = alias, MX = mail, TXT = policy/verification, SRV = service location). Read the stem for the word "reservation", "reverse", or "alias" before looking at options.
Assigning every available vCPU and all RAM to guest VMs and treating thin provisioning as free capacity, then answering capacity questions as if overcommitment has no consequence.
Candidates reason about each VM in isolation rather than about the host as a shared pool, so they never consider contention, swapping, or datastore exhaustion.
What to do instead
Before answering, total the vCPU-to-pCPU ratio and committed RAM versus physical RAM, and state out loud what happens when all guests peak at once. Treat thin provisioning as a promise that must still be backed by real datastore space, and prefer N+1 headroom answers over fully subscribed hosts.
Treating a NAS share and a SAN LUN as equivalent, for example placing a transactional database on an SMB/NFS share or describing iSCSI as a file-level protocol.
Both are "network storage", so candidates collapse them into one concept and miss the block-versus-file distinction that the question is actually testing.
What to do instead
Anchor the distinction: NAS = file-level (SMB/NFS), presents shares, the client's own file system handles the data; SAN = block-level (iSCSI, Fibre Channel), presents LUNs formatted by the server. Match the workload: databases and hypervisor datastores want block storage; shared documents and home directories want file storage.
Swapping RTO and RPO in scenario questions, for example answering that a 15-minute RPO means the server must be back online within 15 minutes.
Both are two-to-three letter acronyms introduced in the same objective, and candidates learn the definitions without attaching them to the business consequence each one measures.
What to do instead
Fix the mapping by consequence: RPO = how much DATA you can afford to lose, so it drives backup frequency; RTO = how long you can afford to be DOWN, so it drives restore speed and redundancy. Read the stem for "data lost" or "downtime" and label it before choosing.
Restoring only the most recent incremental backup, or choosing the last differential instead of the full plus the last differential, when asked which media are required to recover a server.
Candidates treat all backups as independent snapshots and forget that incremental and differential sets form a dependency chain back to the last full backup.
What to do instead
Draw the chain on scratch paper: full + last differential, or full + every incremental since the last full in sequence. Verify by asking whether the proposed restore reproduces the state at the target time, and remember the trade-off - differentials restore faster, incrementals back up faster.
Answering "encrypt the data" when the requirement is to verify integrity, or "hash the password and decrypt it later" when describing credential storage, and using symmetric encryption for key exchange.
All three primitives are introduced together as "cryptography", so candidates reach for the word that sounds most protective rather than the property the stem actually names.
What to do instead
Map requirement to primitive: confidentiality → encryption (symmetric for bulk data, asymmetric for key exchange and signatures); integrity and tamper detection → hashing; authenticity and non-repudiation → digital signature. And remember hashes are one-way: passwords are salted, hashed, and compared, never decrypted.
Jumping straight to a fix option in troubleshooting scenarios without establishing whether the problem has been identified, a theory formed and tested, or a solution verified and documented.
Options that sound like decisive action feel like the "right" answer, and candidates do not recognize that CompTIA is testing the order of the methodology rather than the repair itself.
What to do instead
Scan the stem for the stage it describes, then pick the answer that is the next step, not the final one. Recite the order: identify the problem and gather information → establish a theory → test the theory → plan and implement → verify full functionality → document. If the stem says "after replacing the part", the answer is verification and documentation, not another repair.
Diagnosing a connectivity complaint as a network outage when the user can reach a server by IP address but not by hostname, or when only one subnet is affected, and skipping logs and performance counters that would separate the causes.
The symptom "can't reach the server" is accepted at face value, so candidates never slice the problem into name resolution, routing, duplicate addressing, or service failure.
What to do instead
Apply a fast triage checklist: ping by IP (reachability) versus ping by name (DNS), check for a duplicate-IP or DHCP conflict when only one host is affected, check the default gateway when only one subnet is affected, and read event logs and counters before theorizing. Choose the answer that matches the layer the evidence isolates.