BCCITB common mistakes
BCCITB · Understand the traps and how to avoid them.
When a question describes a failing component, the candidate replaces the most expensive or most visible part first (GPU, motherboard, PSU) instead of running a minimal, step-by-step isolation sequence such as POST/beep codes, reseating, swapping known-good parts, and removing variables one at a time.
Textbook troubleshooting steps are memorized as a list but never internalized as a workflow; under time pressure the candidate pattern-matches 'no display' to 'bad GPU' rather than to the diagnostic path that would actually discriminate between RAM, PSU, and video faults.
What to do instead
Practice writing a 5-step isolation plan for each common symptom (no POST, no display, random reboots, no boot device) and force yourself to state which single test eliminates which component before choosing a part. Learn the beep-code and LED patterns for at least one common vendor and the meaning of a POST card stop code.
The candidate treats RAM and storage as interchangeable when explaining symptoms, attributing slow boot, application crashes, or 'out of memory' errors to the wrong subsystem, and confusing volatile versus non-volatile storage in capacity and persistence questions.
Everyday language blurs 'memory' and 'storage', and candidates memorize capacity numbers (DDR4 vs NVMe) without mapping each to its role: RAM holds working data and loses it on power-off, storage retains data; insufficient RAM causes paging and slowdown, failing storage causes corruption and boot errors.
What to do instead
Build a two-column table of RAM versus SSD/HDD covering volatility, typical capacities, latency, failure symptoms, and upgrade path, and rehearse explaining three symptoms aloud with the correct subsystem named. Memorize that paging/swap activity and 'low memory' warnings point to RAM pressure, while SMART warnings, clicking, and 'boot device not found' point to storage.
The candidate answers subnetting and addressing questions by recalling example answers rather than computing, so they misidentify the network address, broadcast address, usable host range, or the number of hosts for a given CIDR prefix, and they confuse public versus private ranges.
Subnetting is a procedural skill that decays without practice; candidates memorize a few common masks (/24, /16) and then guess on /26, /27, or /30 questions, and they mix up the reserved private blocks (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) with other ranges.
What to do instead
Drill the powers-of-two table (2^1 through 2^12) and the block-size method until you can compute host counts and ranges in under a minute for any prefix from /24 to /30. Write out the binary of the last octet for ten random addresses and verify network/broadcast boundaries by hand; memorize the three private ranges and the 169.254.0.0/16 link-local block.
The candidate conflates the OSI/TCP-IP layers with the devices and protocols that operate at each layer, for example placing a switch at Layer 4, a router at Layer 2, or DNS and DHCP at the wrong layer, and then picks a troubleshooting tool that tests the wrong layer.
Layer models are taught as abstract diagrams, so candidates memorize layer names without anchoring each to concrete devices (hub L1, switch L2, router L3) and protocols (ARP L2, IP/ICMP L3, TCP/UDP L4, HTTP/DNS/DHCP L7), which makes 'which tool verifies which layer' questions unanswerable.
What to do instead
Create a one-page layer map with a device, a protocol, a PDU name, and a diagnostic tool at every layer (cable tester, MAC/ARP table, ping/traceroute, netstat/port check, DNS lookup, HTTP status). For each tool, state the highest layer it proves is working; this converts abstract recall into a decision rule.
The candidate chooses the strongest-sounding security control for every scenario (full-disk encryption, MFA, IDS) instead of the control that addresses the specific threat or risk described, such as least privilege for an insider access problem or patching for a known exploited vulnerability.
Security vocabulary is learned as a list of good things rather than as a mapping from threat to control; candidates also confuse preventive, detective, and corrective controls, so they pick a detective tool (logging, IDS) when the question asks how to stop an event, or a preventive control when the question asks how to detect one.
What to do instead
For each scenario, first name the threat (insider, phishing, lost laptop, ransomware, weak password) and then classify the candidate answers as preventive, detective, or corrective before selecting. Practice justifying why each wrong option is weaker for that specific threat, and memorize the CIA triad mapping so confidentiality, integrity, and availability questions resolve cleanly.
The candidate answers cloud and emerging-technology questions using on-premises assumptions, misapplying the IaaS/PaaS/SaaS boundary, confusing scalability with elasticity, or treating a shared-responsibility question as if the provider secures everything.
Cloud models are new vocabulary layered on familiar hardware mental models; candidates memorize the acronyms but not the division of responsibility, so they claim the provider patches the guest OS in IaaS or that the customer manages the hypervisor in SaaS.
What to do instead
Draw the shared-responsibility stack for IaaS, PaaS, and SaaS with a clear line for OS, runtime, application, and data, and memorize the rule that the customer always owns data and identity. Distinguish vertical scaling (bigger instance) from horizontal scaling (more instances) and elasticity (automatic, demand-driven) with one concrete example each.
The candidate mixes up ITIL-style service management concepts, treating an incident as a problem, a change as a release, or a service request as an incident, and then selects the wrong process or the wrong priority for the scenario.
The terms overlap in everyday use, so candidates rely on intuition rather than definitions: an incident restores service quickly, a problem finds and removes the root cause, a change alters a configuration item under control, and a service request is a standard user ask.
What to do instead
Write one-line definitions plus a contrasting example for each pair (incident vs problem, change vs release, event vs incident) and memorize the priority matrix of impact times urgency. For each practice scenario, name the process first and only then evaluate the answer options against that process definition.
The candidate confuses file system and permission concepts, such as the difference between NTFS and FAT32/exFAT limits, between share permissions and NTFS permissions, and between a local account and a domain account, when answering OS and software questions.
These are memorized as isolated facts rather than as a layered model, so candidates do not know that effective access is the most restrictive combination of share and NTFS permissions, or that FAT32 caps individual files near 4 GB while exFAT and NTFS do not.
What to do instead
Build a comparison table for FAT32, exFAT, and NTFS covering max file size, max volume size, journaling, permissions, and encryption, and memorize the rule that when share and NTFS permissions differ the more restrictive one wins (except that explicit deny always wins). Practice two-account scenarios where a user reaches a file through a share.
The candidate skips the verification and documentation step of the troubleshooting model, declaring the issue resolved after the first symptom disappears, and fails questions that ask what to do next after a fix is applied or that reward confirming no side effects and updating the ticket or knowledge base.
Candidates focus on the dramatic middle of the process (identify, test, implement) and treat the bookends as filler, so they cannot recognize 'verify full system functionality', 'document findings', or 'establish a theory of probable cause' as the correct next step in a sequence question.
What to do instead
Memorize the troubleshooting model as an ordered list with a one-line action for each step, then practice 'what is the NEXT step' questions by locating the scenario's current step before reading the options. Treat documentation and verification as mandatory steps, not optional, and note that asking the user what changed belongs to information gathering, before theory formation.
The candidate answers professional-practice and support questions by choosing the technically correct action while ignoring policy, escalation, safety, or customer-handling requirements, such as performing a repair beyond their authorization, skipping the ticket, or arguing with an upset user.
Technical training rewards solving the problem, so candidates default to the fix and undervalue the procedural answer; they also miss that some scenarios test escalation thresholds, change approval, data-handling rules, or communication etiquette rather than the repair itself.
What to do instead
Read each scenario for the constraint words (authorized, policy, first action, best response) and eliminate options that bypass approval, ignore the user's report, or break confidentiality, even if technically effective. Memorize a short escalation ladder and the rule that you confirm understanding and set expectations before acting, and practice choosing the option that both solves the issue and follows process.