ITA common mistakes
ITA · Understand the traps and how to avoid them.
Choosing the fastest-sounding storage or memory option without matching it to the stated workload, such as recommending an NVMe SSD where the scenario calls for bulk archival capacity, or picking RAM speed over capacity for a virtualization host.
Candidates memorize headline speeds and marketing terms (SSD faster than HDD, more GHz is better) and then apply them as a reflex instead of reading the constraint the scenario actually states, so the trade-off between cost, capacity, and throughput is never evaluated.
What to do instead
Before answering, underline the scenario's stated constraint (budget, capacity, durability, latency) and eliminate any option that violates it, then justify the remaining choice in one sentence using that constraint. Practice by classifying ten storage or memory technologies against three criteria each.
Confusing volatile and non-volatile storage, or describing what happens to open files and unsaved data during a power loss, shutdown, or sleep transition incorrectly.
The terms RAM, cache, and disk get used loosely in everyday speech, and candidates transfer that casual usage into exam answers without a clear mental model of which layer retains state when power is removed.
What to do instead
Build a one-page table listing RAM, cache, registers, SSD, HDD, and firmware, marking each volatile or non-volatile and what survives a hard power cut. Rehearse the sleep versus hibernate versus shutdown distinction until it can be stated without notes.
Answering permission and access questions by naming the highest-privileged account or the quickest workaround rather than the least-privilege option that satisfies the requirement.
Candidates reason from personal habit (log in as administrator to fix it) and from urgency framing in the question stem, so the security principle of least privilege is overridden by the desire to make the problem go away.
What to do instead
When a stem mentions access, sharing, or a fix, scan every option for privilege level and prefer the minimum that meets the stated need. Practice rewriting five 'just give admin' solutions into scoped group or role assignments.
Treating encryption, hashing, and encoding as interchangeable, for example saying a password should be encrypted for storage or that hashing provides confidentiality in transit.
All three transform data into unreadable-looking output, so surface similarity masks the different purposes: reversibility, integrity, and transport representation. Candidates match on appearance rather than on property.
What to do instead
Memorize a three-row comparison: encryption is reversible with a key and gives confidentiality, hashing is one-way and gives integrity, encoding is reversible without a key and gives compatibility. Then classify ten scenario statements into these rows before looking at options.
Misdiagnosing a network fault by skipping the layered sequence, such as replacing a cable or reinstalling drivers before confirming link status, IP configuration, and reachability in order.
Candidates jump to the layer they are most comfortable with, often the physical or the application layer, and the question stem rewards a structured escalation from the bottom up rather than the most dramatic fix.
What to do instead
Apply a fixed checklist for every connectivity scenario: physical link, then address configuration, then name resolution, then default gateway and routing, then application. State which step the evidence supports before selecting an answer.
Confusing similar addressing and service concepts, for example private versus public addresses, static versus dynamic assignment, or which protocol handles name resolution versus address assignment.
The vocabulary overlaps and the acronyms are learned as a list rather than as a set of functions, so recall of the abbreviation is strong while recall of its job is weak.
What to do instead
Create a function-first glossary: write the job in plain words on the left and the protocol or concept on the right, then cover the right column and self-test. Add one concrete example address or port for each entry to anchor it.
Choosing a destructive or data-losing troubleshooting step, such as reformatting, reinstalling the operating system, or restoring from backup, before exhausting non-destructive diagnostics.
These are familiar and satisfying fixes, and the question stem's pressure wording pushes candidates toward decisive action. The cost of lost user data is easy to overlook under time pressure.
What to do instead
Rank every proposed action by data risk before choosing. If two options both resolve the symptom, prefer the one that preserves user data and is reversible. Practice by labeling ten remediation steps as non-destructive, destructive, or restorative.
Mixing up database keys and normalization concepts, such as treating a primary key as a foreign key, or describing normalization as a performance optimization rather than a redundancy-reduction process.
The terms are introduced together and share the idea of uniqueness, so definitions blur. Normalization's benefits are also described inconsistently in casual material, which reinforces the wrong framing.
What to do instead
Draw a two-table example with a primary key in each and a foreign key linking them, then annotate what each key guarantees. Separately list normalization's purpose (reduce redundancy and update anomalies) and its trade-off (more joins), and test yourself on both directions.
Answering web and application questions by conflating client-side and server-side execution, for example expecting browser code to enforce access control or expecting a server to render without a request.
Modern pages blend markup, styling, and logic in one file, so the boundary between what the browser runs and what the server runs is invisible in the source a candidate has seen.
What to do instead
For each scenario, first label where the code runs, then ask what that location can and cannot be trusted to do. Remember that anything sent to the browser can be read and modified, so enforcement belongs on the server.
Treating incident management and problem management as the same process, or assigning a change type without checking its risk and approval requirements.
Both processes respond to things going wrong, and the terminology is close. Candidates also default to 'standard change' because it sounds routine, ignoring whether the change is pre-approved.
What to do instead
Anchor on outcomes: incident restores service, problem removes the root cause. For changes, decide by risk and pre-approval status, not by familiarity. Write one sentence definitions for each and apply them to five short scenarios.