IUP ITS common mistakes
IUP ITS · Understand the traps and how to avoid them.
When asked to choose the first step in an incident or service request workflow, the candidate selects the resolution action (e.g., applying a known fix, escalating to a specialist) rather than the preceding step such as logging, categorizing, or initial diagnosis.
Candidates with hands-on technical backgrounds jump straight to the fix because that is what they do in practice; they read the scenario as a troubleshooting puzzle rather than as a process-ordering question tied to ITIL-style lifecycle stages.
What to do instead
Before answering any process question, mentally write the lifecycle sequence (detect/log, classify, prioritize, diagnose, resolve, close) and ask which stage the stem is located in. Eliminate any option that belongs to a later stage than the one the stem describes, and practice with scenario stems that explicitly say 'first', 'next', or 'immediately after'.
The candidate treats priority and severity as interchangeable, assigning high priority to every high-impact technical fault, or ranking a single-VIP complaint above a widespread outage.
In day-to-day support, urgency and impact usually move together, so the distinction feels academic. Exam stems deliberately separate them by pairing low impact with high urgency (a CEO's laptop) or high impact with lower urgency (a background batch failure).
What to do instead
Apply the two-axis rule explicitly: impact is breadth of affected users or business criticality, urgency is how fast the damage grows. Score each option on both axes and pick the one where the combination, not either single dimension, justifies the answer; rehearse with the CEO-laptop versus outage contrast until the pattern is automatic.
The candidate answers subnetting, VLSM, or route-summary items from memory of common masks instead of computing host ranges and broadcast addresses, and picks an option that looks familiar.
Time pressure and the absence of a scratchpad habit push candidates toward pattern-matching on /24 and /16 boundaries; distractor options are built to match those familiar patterns.
What to do instead
Convert every address to binary or use the block-size shortcut (256 minus the interesting octet) and write the network, first host, last host, and broadcast before looking at the options. Budget a fixed time per calculation item and practice 20 to 30 items until the block-size method is faster than guessing.
The candidate confuses Layer 2 and Layer 3 symptoms, attributing a VLAN or duplex problem to routing, or blaming DNS for connectivity failures that are actually link-layer or ARP issues.
Real outages present with mixed symptoms, and candidates anchor on the last similar problem they solved rather than working the OSI model bottom-up or top-down deliberately.
What to do instead
Adopt an explicit troubleshooting ladder: confirm link and speed/duplex, then ARP and VLAN membership, then IP addressing and routing, then name resolution and application. For each exam scenario, state which layer the described symptom implicates before evaluating options, and discard options that fix a layer above the demonstrated fault.
The candidate selects the control that detects or logs a problem when the question asks for prevention or mitigation, or recommends encryption where the requirement is integrity or availability.
Security vocabulary overlaps (monitoring, auditing, hardening, encryption) and candidates match on topic rather than on the CIA property or control category the stem specifies.
What to do instead
Underline the requirement word in the stem (prevent, detect, recover, confidentiality, integrity, availability) and classify each option by control type (preventive, detective, corrective) and CIA property before choosing. Build a one-page mapping of common controls to categories and review it before the exam.
The candidate recommends the strongest technical control (full disk encryption, MFA everywhere, network segmentation) in response to a governance or risk question where the expected answer is a policy, risk acceptance, or compensating control proportionate to the risk.
Technical candidates equate security with tooling and overlook that governance questions test risk treatment decisions, ownership, and cost-benefit, not maximal hardening.
What to do instead
For any question containing risk, policy, exception, or ownership language, first identify who owns the risk and which treatment (mitigate, transfer, avoid, accept) the scenario supports. Prefer the option that establishes accountability and documentation over the one that adds technology, unless the stem explicitly asks for a technical safeguard.
The candidate applies a Linux command or permission fix to a Windows scenario, or vice versa, and misreads file permission notation such as 755 or an ACL entry.
Cross-platform familiarity blurs command syntax, and permission questions are often answered by recalling a common value like 755 rather than computing owner, group, and other bits for the stated requirement.
What to do instead
Read the platform marker in the stem first and filter options by operating system before evaluating correctness. For permission items, write out rwx for owner, group, and other from the requirement, then convert to octal or symbolic form and compare, rather than recognizing a familiar number.
The candidate answers backup, replication, or high-availability questions by choosing the mechanism with the shortest recovery time without checking whether the stem's requirement is RPO (data loss tolerance) or RTO (downtime tolerance).
Replication and backups are treated as synonyms in casual use, and the shortest-downtime option feels safest, so candidates ignore the data-loss dimension the stem is testing.
What to do instead
Label each scenario with RPO and RTO before reading options, then classify every option as protecting data (backup, snapshot, log shipping) or protecting uptime (cluster, load balancer, replication). Choose the option that satisfies the stated constraint, and note that synchronous replication addresses RPO while failover addresses RTO.
The candidate picks the normalization form or index strategy that feels most rigorous (third normal form, index every column) instead of the one that matches the stated workload, reporting need, or write-heavy pattern.
Textbook rules are memorized as absolutes, so candidates apply 3NF or indexing as default answers without weighing denormalization for read performance or the write cost of excess indexes.
What to do instead
For each data-model question, identify the dominant workload (OLTP writes, analytical reads, reporting) and the stated constraint, then evaluate options against that constraint. Remember that denormalization and covering indexes are legitimate design choices when reads dominate, and eliminate options that ignore the stated access pattern.
The candidate treats a change as approved because the requester is senior or because testing passed, skipping the change advisory or approval step, and confuses emergency change handling with skipping the process entirely.
In practice, seniority often shortcuts process, and candidates map that experience onto exam scenarios where the expected answer is that the emergency path still requires retrospective approval and documentation.
What to do instead
For every change-management stem, check whether the change is standard, normal, or emergency, and select the option that follows the corresponding path, including post-implementation review for emergency changes. Reject any option that grants approval based on the requester's role or on test results alone.