CBAP common mistakes
CBAP · Understand the traps and how to avoid them.
Treating the six knowledge areas as a linear waterfall and answering each question as if it sits in exactly one phase, so when a scenario describes a BA re-planning stakeholder engagement mid-project the candidate picks the 'Elicitation and Collaboration' answer because the word 'stakeholder' appears, instead of recognising the work as Business Analysis Planning and Monitoring.
Most prep material presents the knowledge areas in numbered order, and candidates memorise the sequence rather than the underlying purpose of each area. The exam deliberately writes scenarios that cross areas, and the task being performed (planning the approach versus executing the elicitation) determines the correct answer, not the vocabulary in the stem.
What to do instead
Before reading the options, write one line describing what the BA is actually doing in the scenario: deciding, preparing, executing, tracing, analysing, or evaluating. Map that verb to the knowledge area's purpose, then eliminate any option that belongs to a different purpose even if its wording echoes the scenario. Drill with mixed sets where you name the purpose before looking at choices.
Selecting the most thorough or most formal technique on every question, assuming the exam rewards maximum rigour, so a small internal enhancement gets a full stakeholder engagement plan, formal sign-off gates, and a complete requirements traceability matrix.
Candidates confuse 'good practice' with 'appropriate practice'. The BA Planning and Monitoring domain is built on tailoring: the exam repeatedly tests whether you can scale governance, formality, and documentation to the size, risk, and regulatory context of the initiative. Choosing the heavyweight option feels safer but ignores context.
What to do instead
For each planning question, first identify the context variables in the stem: project size, regulatory exposure, geographic distribution, organisational culture, and risk tolerance. The correct answer is the one whose rigour matches those variables. Practise writing the context variables in the margin and rejecting any option that is disproportionate to them.
Answering elicitation questions by picking a single technique (usually interviews or workshops) and ignoring that the scenario has already described constraints such as dispersed stakeholders, a short window, or a politically sensitive topic that make that technique unworkable.
Candidates learn technique descriptions in isolation and match on the technique name rather than on its preconditions. The exam embeds feasibility clues in the scenario, and the distractor is almost always a familiar technique that cannot satisfy those clues.
What to do instead
For every elicitation question, extract the constraints first: who is available, where they are, how much time exists, what the topic's sensitivity is, and what artefacts already exist. Then test each option against all constraints. Build a personal table of techniques with columns for group size, co-location need, time cost, and best-fit situation, and revise from that table rather than from prose descriptions.
Skipping the confirmation and verification step after elicitation, treating 'requirements gathered' as 'requirements agreed', so on questions about conflicting stakeholder statements the candidate chooses to document both versions and move on rather than to reconcile and confirm them.
In practice many BAs hand off raw notes and let downstream teams resolve ambiguity, so the confirmation activity feels optional. Elicitation and Collaboration explicitly includes confirming results, and the exam tests whether you close the loop with the source before treating information as a requirement.
What to do instead
Adopt a rule: no elicitation output becomes a requirement until it has been validated with the source and checked for consistency with other sources. When a question shows two stakeholders disagreeing, prefer the option that returns to the stakeholders to resolve and confirm, and reject options that simply record the conflict or escalate it before attempting confirmation.
Treating requirements traceability as a one-time setup at the start of the project rather than a maintained activity, so when a question describes a change arriving after baseline the candidate cannot say which requirements, designs, and tests are affected.
Traceability matrices are often built to satisfy a template and then abandoned. The Life Cycle Management domain tests ongoing maintenance of relationships, and questions about impact analysis assume the BA can traverse from a changed requirement to its dependents in both directions.
What to do instead
Memorise the traceability directions explicitly: backward to the source need, forward to design and test artefacts, and sideways to related requirements. For any impact-analysis question, mentally walk all three directions before choosing. Practise by drawing a small dependency graph from a described scenario and asking which nodes a change would touch.
Approving or rejecting a change request on the basis of whether the requester is senior or whether the change seems reasonable, rather than routing it through the defined change assessment process that weighs value, risk, and impact before a decision authority acts.
Candidates import workplace habits where the loudest stakeholder wins, and the exam offers plausible options like 'implement because the sponsor asked'. The Life Cycle Management domain separates the BA's assessment role from the decision-maker's authority, and questions test whether you keep those roles distinct.
What to do instead
On change questions, identify two things separately: who assesses the change and who authorises it. The correct option almost always has the BA perform impact and value assessment and then route the recommendation to the accountable authority. Eliminate options where the BA unilaterally approves, or where approval happens without assessment.
Jumping straight from a stated problem to a solution in Strategy Analysis scenarios, choosing the option that describes a new system or process rather than first examining the current state and defining the future state and the gap between them.
Stakeholders typically arrive with a solution already in mind, and candidates mirror that by evaluating options immediately. Strategy Analysis requires context, current-state, future-state, and gap analysis before solution options are assessed, and the exam places distractors that skip straight to implementation.
What to do instead
For any strategy question, ask whether the current state has been analysed and the future state defined. If not, the correct answer is the option that does that work, even if a more exciting solution option is present. Remember that the gap between current and future state is what generates requirements, so a question about where requirements come from is answered by the gap, not by a stakeholder request.
Confusing verification with validation, choosing the option that checks requirements are internally consistent and correctly written when the question is about whether the requirements deliver the stakeholder need, or the reverse.
The two terms sound interchangeable and both appear as plausible options. Requirements Analysis and Design Definition treats verification as conformance to quality standards and validation as demonstrating the solution meets the need, and the exam expects you to select based on which of those the scenario describes.
What to do instead
Anchor on the question being asked: verification asks 'did we write this correctly and consistently', validation asks 'is this the right thing for the need'. Scan the scenario for words like ambiguous, conflicting, or standards-compliant (verification) versus stakeholder need, value, or fitness for purpose (validation). Write the distinction on your scratch sheet before the exam.
Assessing solution performance only against the originally documented requirements and declaring success, ignoring that the solution may create new limitations, that measures must be defined before performance is assessed, and that enterprise-level value may differ from requirement compliance.
Teams celebrate requirement completion, so candidates equate meeting requirements with solution success. Solution Evaluation requires defining performance measures, comparing actual to expected value, and identifying limitations and their root causes, which can exist even when every requirement is met.
What to do instead
For Solution Evaluation questions, check whether measures were defined and whether the comparison is against expected value rather than against requirement checklists. When a scenario shows a solution meeting all requirements but underperforming, prefer options that investigate limitations and root causes over options that declare completion or immediately propose replacement.
Ignoring the underlying competencies and the BA's role boundaries, choosing options where the BA makes enterprise decisions, overrides governance, or resolves organisational politics directly instead of facilitating, recommending, and escalating appropriately.
Candidates want the BA to be decisive, and options showing the BA taking charge read as strong leadership. The exam tests whether you understand that the BA enables decisions within authority structures, and it penalises options that exceed the role or bypass governance.
What to do instead
For every option, ask 'is this the BA's decision to make, or the BA's analysis to provide'. Prefer options where the BA facilitates, analyses, recommends, and escalates through the correct authority. Reject options where the BA approves funding, mandates organisational change, or resolves stakeholder conflict by fiat.