EXIL-CBI common mistakes
EXIL-CBI · Understand the traps and how to avoid them.
Answers terminology items using the everyday meaning of a word (for example treating 'governance', 'management', 'role', 'process' and 'function' as interchangeable) instead of applying the operational definition the syllabus assigns to it.
The words are already familiar, so the candidate skims the glossary, recognises the term and feels no need to learn the boundary that separates it from its nearest neighbour. Recognition is mistaken for definition.
What to do instead
Build a two-column contrast sheet pairing every confusable pair (governance/management, role/function, policy/standard, output/outcome). For each pair write one discriminating test question, then rehearse by substituting the definition back into the stem and checking whether the option still fits.
Picks the option that is most comprehensive, most technically impressive or longest, instead of the option that satisfies the qualifier in the stem ('primary', 'first', 'most cost-effective', 'best').
Long multiple-choice exams train candidates to look for the 'fullest' answer, and domain expertise pulls attention toward the richest option even when it answers a different question than the one asked.
What to do instead
Before reading the options, cover them, restate the stem in one sentence in your own words and name the qualifier explicitly. Eliminate any option that answers a different qualifier even if the content is factually correct.
Names the wrong data-quality dimension on items that hinge on telling accuracy from precision, validity from completeness, or consistency from timeliness, and defends the choice with a plausible-sounding sentence.
The dimensions overlap in ordinary speech (people say 'accurate' when they mean 'complete' or 'consistent'), so the option chosen feels right without the candidate ever testing it against a formal criterion.
What to do instead
For each dimension memorise a single diagnostic question (Is it the right value? Is it the same value everywhere? Is it the right value for the purpose? Is anything missing?). Apply that question to the scenario data described in the stem, not to the option text.
Jumps straight to the recommended solution or target-state design in scenario items, skipping over the step of establishing the current state, the requirement or the constraint that the item is testing.
Practitioners are rewarded at work for decisiveness, and the solution-shaped option is the most interesting thing on the page, so attention locks onto it before the problem statement has been fully parsed.
What to do instead
Force a three-line scratch note on every scenario item before answering: input given, constraint stated, output required. Reject any option that resolves the output while ignoring a stated constraint, even if the option is the 'modern' or 'best-practice' answer.
Treats phased or stage-based models as rigid sequential waterfalls, so an option describing iteration, feedback or parallel activity is dismissed as incorrect.
Diagrams in study material read left to right and imply order, and candidates conflate the order in which activities are described with the order in which they must be performed or the order in which deliverables are signed off.
What to do instead
For each model, learn separately (a) the sequence of activities and (b) the dependencies between deliverables. Ask which one the item is about; only dependency-based items reward iteration as an answer.
Answers implementation and delivery items for an idealised environment - unlimited time, clean data, willing stakeholders, unlimited licence budget - rather than for the constraints explicitly written in the stem.
Long scenario stems exceed attention span, so the constraint sentence buried mid-paragraph is read but not encoded, and memory supplies the default assumptions from the candidate's own workplace.
What to do instead
Annotate the stem as you read: circle every budget, deadline, legacy system, regulatory or staffing constraint. Then check each surviving option against the circled list and discard any option the scenario has already ruled out.
Uses 'build complete', 'tested', 'deployed', 'accepted' and 'handed over' as if they refer to the same delivery milestone, and selects options that collapse them into one gate.
In practice these activities blur together in quick releases, so the candidate has no crisp mental model of which artefact or sign-off belongs to which stage.
What to do instead
Learn the delivery chain as a set of distinct gates with an owner and an evidence artefact for each. When an item names a milestone, ask what evidence would exist at that point and choose the option that matches that evidence.
Replaces the control or obligation stated in the standard or policy with the practice used at the candidate's own organisation, and selects the local practice when the two diverge.
Personal experience is vivid and repeatedly reinforced, while the written requirement was read once during study, so the workplace answer feels more authoritative under time pressure.
What to do instead
For security and compliance items, delay judgement until you have asked 'what does the governing document require?' rather than 'what works well?'. When an option describes local pragmatism that contradicts a documented requirement, treat it as a distractor.
Swaps preventive controls for detective or corrective ones, or swaps likelihood-reduction measures for impact-reduction measures, when the item asks what a specific control achieves.
Control lists are memorised by name and category label without a link to purpose and timing, so recall succeeds while classification fails.
What to do instead
Re-label every control you study on two axes - before/during/after the event, and reduces likelihood / reduces impact / restores service - and practise sorting a mixed list from memory until the classification is automatic.
Proposes a remedy that removes the symptom described in the scenario (reset it, restart it, retrain the user) when the item is testing permanent resolution, root-cause removal or improvement of the underlying process.
Incident, problem and change language overlaps in operational settings, and fast symptom relief is the behaviour that gets praised day to day, so it is offered as the answer by default.
What to do instead
Classify each operations item first as restore service, remove root cause, or improve the process, using the stem's own verbs. Only after labelling the intent should you look at options, and then select the one whose lifespan matches that intent.