TCTCN common mistakes
TCTCN · Understand the traps and how to avoid them.
Reciting acronym expansions and definitions from memory but being unable to place the term in the layer, phase, or function where it actually operates when a scenario asks for it.
Study material presents terminology as flat glossary lists, so recall is trained as one-to-one word matching rather than as a map of how the pieces relate.
What to do instead
Build a single-page map (layer/phase/function on one axis, terms on the other) and self-quiz in both directions - function to term and term to function - until every term has a location, not just a definition.
Treating near-miss concept pairs as interchangeable on the exam, e.g. picking the recovery-time objective when the stem described an acceptable data-loss window, or describing authorization when the scenario asked who may prove identity.
The pairs share vocabulary and appear together in real documentation, so recognition is fluent while discrimination is not.
What to do instead
Maintain a contrastive-pairs table with three columns: the distinguishing question each term answers, a one-line operational consequence of confusing them, and a memorized trigger phrase from the stem that signals each one.
Answering quantitative items without a unit and order-of-magnitude check - mixing bits and bytes, decimal and binary prefixes, or per-second and per-hour rates - and selecting a numerically plausible but dimensionally wrong option.
Under time pressure the arithmetic is done mentally and the unit labels in the options are skimmed rather than compared against the unit in the stem.
What to do instead
Force unit normalization before calculating: rewrite every given value in one base unit, solve, then confirm the answer's unit matches what the question asked for. Practise on ten numeric items until normalization becomes automatic.
Selecting a design option that matches a familiar reference architecture before finishing reading the stem, so the chosen answer violates a constraint stated later in the scenario (budget, scale ceiling, latency target, regulatory scope).
Experienced candidates pattern-match quickly; the fast pattern competes with careful constraint extraction and usually wins under a clock.
What to do instead
Two-pass reading: first pass extract and write down every explicit constraint and requirement as a short numbered list, second pass read the options. Eliminate any option that breaks a written constraint before comparing the survivors on merit.
Counting redundant components as resilience - declaring a design highly available because it has two servers or two links, when both share a single upstream dependency such as one rack, one power feed, or one credential store.
Component count is visually obvious in a description while shared dependencies must be inferred, so the design is evaluated by tally rather than by topology.
What to do instead
Draw the dependency path from client to data store for the proposed design and mark every point where two nominally distinct paths reconverge. Any reconvergence point that the availability target does not tolerate is a failing single point of failure.
Applying a configuration change with no pre-change state capture and no stated verification or rollback step, then choosing a remediation option that continues forward from an unknown baseline.
Study habits focus on the command or setting that produces the desired end state and omit the surrounding operational discipline, which is what scenario items actually test.
What to do instead
Adopt a fixed change ritual and rehearse it in a lab: record current state, state the expected post-change observation, apply, verify against that observation, and have the reversal step written before starting. Identify options that skip capture or verification as wrong by construction.
Reproducing configuration syntax from memory in the wrong order, or before the prerequisite object exists, and then blaming the tool when the result fails.
Passive study (videos, reading) produces the feeling of familiarity without the procedural memory that ordering and dependency handling require.
What to do instead
Rebuild the configuration from a blank environment with the reference guide closed, deliberately breaking it twice to see the error each dependency violation produces. Repeat from blank until the sequence can be written without looking.
Troubleshooting by testing the most recently changed element or a personal favourite cause first, rather than narrowing the fault by observation.
Recent-change thinking is a strong heuristic that feels efficient on the job and misfires on exam scenarios engineered with a less obvious cause.
What to do instead
Use a fixed diagnostic order on paper: reproduce and write down the exact symptom, define what does and does not fail (blast radius), bisect the path into halves and test at the midpoint, then confirm root cause by restoring the element and observing the symptom clear.
Choosing a security control that is strong in general but unmapped to the specific requirement in the stem, or applying controls across a scope boundary the scenario excluded.
Candidates answer from a general hierarchy of 'more secure equals better' instead of translating the stated obligation into a testable condition first.
What to do instead
Before reading options, rewrite the requirement as one testable sentence naming the asset, the actor, the condition that must hold, and the scope. Accept only options that satisfy that sentence exactly; both over-control and under-control become visibly wrong.
In troubleshooting items, stopping the analysis once service is restored and selecting the remediation that makes the symptom disappear, when the question asks for root cause or for prevention of recurrence.
Operational instinct treats symptom clearance as the end of the incident, and the options reward that instinct by including tempting workarounds.
What to do instead
Read the final clause of the question stem first and label it as cause, fix, or prevention; then require the chosen option to address that specific target. Discard any option that only masks or restarts.