iSAQB CPSA Foundation Level common mistakes
iSAQB CPSA Foundation Level · Understand the traps and how to avoid them.
Listing architectural patterns (layers, MVC, microservices) as the answer when the question asks for a quality attribute scenario, a design principle, or a building block view, because the candidate pattern-matches on the word 'design'.
The iSAQB curriculum separates recurring structures (patterns), design principles (e.g. information hiding, separation of concerns), and architecture views. Candidates who memorised pattern names from tutorials conflate these categories and pick the most familiar-sounding term instead of reading what the question actually demands.
What to do instead
Before answering, classify the stem: is it asking 'which view?', 'which principle?', 'which pattern?', or 'which quality scenario component?'. Build a one-page table mapping each curriculum term to its category and rehearse sorting unfamiliar terms into it. If a term cannot be placed, treat it as a distractor.
Describing the software architect's job as 'writing all the code' or 'making all technical decisions', ignoring the coordination, communication, and stakeholder-negotiation duties that the curriculum lists explicitly.
Most candidates arrive from a developer role and answer from personal experience of what a senior developer does. The exam tests the curriculum's broader role definition, which includes driving quality goals, moderating trade-offs, and communicating across technical and non-technical stakeholders.
What to do instead
Memorise the role as a set of responsibilities: defining and owning the architecture, eliciting quality requirements with stakeholders, making and documenting trade-offs, guiding and reviewing implementation, and communicating the architecture. For role questions, choose the answer that spans these duties rather than the one that is purely hands-on.
Drawing or interpreting a view without stating which viewpoint and which stakeholder concern it serves, so the answer mixes elements from the building block view, runtime view, and deployment view.
Candidates learn the views as lists of diagram types and not as answers to stakeholder questions. Under time pressure they select a plausible diagram instead of asking 'whose concern does this address, and what does it therefore contain?'
What to do instead
For every view question, first name the concern (static structure, interaction at runtime, mapping to hardware, or context/dependencies), then the view that answers it. Practise stating 'this view serves stakeholder X with concern Y' for each of context, building block, runtime, deployment, and cross-cutting views before choosing.
Treating the architecture as a complete up-front blueprint and rejecting iterative or evolutionary approaches, or conversely choosing 'agile' as a blanket answer whenever the word 'change' appears.
The exam tests the curriculum's position that architecture work is iterative, risk-driven, and continues alongside development. Candidates overcorrect in one direction: either waterfall habits from traditional projects or reflexive agile answers without checking the constraints in the stem.
What to do instead
Read the constraints in the stem (safety-critical, fixed requirements, high uncertainty, regulated environment) and match the approach to them. Learn that architecture decisions are made when risk is highest and revisited, and that documentation depth scales with criticality and team distribution, not with methodology labels.
Choosing a quality attribute tactic that improves one attribute while silently worsening another, without acknowledging the trade-off the question is testing (e.g. picking caching to improve performance when the stem asks about consistency).
Quality attributes are taught one at a time, so candidates learn 'caching improves performance' as an isolated fact. Exam items embed conflicting goals, and the candidate optimises the named attribute while ignoring the second requirement stated in the stem.
What to do instead
Underline every quality requirement in the stem, including the one introduced by 'but', 'while', or 'however'. Evaluate each option against all stated attributes and eliminate options that satisfy one at the expense of another. Where the question asks for a trade-off, prefer the option that names the conflict explicitly.
Mixing up the parts of a quality attribute scenario (source, stimulus, artefact, environment, response, response measure) and accepting an option that states a vague goal such as 'the system must be fast' as a valid scenario.
Candidates recognise the six-part structure in theory but cannot apply it under exam conditions, so they pick answers that sound specific but omit the response measure, or that describe a tactic rather than a scenario.
What to do instead
Practise rewriting vague goals into full scenarios: name who or what triggers the stimulus, the affected artefact, the conditions, the expected response, and a measurable criterion. On the exam, reject any option lacking a measurable response measure or naming a tactic instead of an outcome.
Confusing architecture evaluation methods, for example describing ATAM as a review that produces a score or certification, or treating a lightweight review and a formal scenario-based evaluation as interchangeable.
Method names are learned as acronyms without their purpose, inputs, and outputs. Candidates then answer from the acronym's expansion rather than from what the method actually produces, such as risks, sensitivity points, and trade-off points.
What to do instead
For each method in the curriculum, learn four things: when it is used, who participates, what inputs it needs, and what artefacts it produces. Focus on the distinction between evaluating against quality goals and checking conformance to a specification, and match the method to the question's purpose.
Treating documentation as a deliverable to be maximised, so the candidate selects the most comprehensive documentation option even when the stem describes a small co-located team with a short-lived prototype.
Candidates assume more documentation scores better and overlook the curriculum's principle that documentation effort must be proportionate to its audience and purpose. They ignore signals in the stem about team size, distribution, criticality, and lifespan.
What to do instead
For documentation questions, identify the readers and their concerns first, then choose the smallest set of views and artefacts that answers those concerns. Learn that documentation is evaluated on fitness for purpose, not volume, and that unnecessary views are a cost, not a virtue.
Assuming a tool question has a single universally correct answer, for example naming one modelling notation or one diagram tool as 'the' standard, instead of matching the tool to the purpose and the stakeholders who must read the result.
Candidates prepare by learning one notation or tool deeply and generalise from that experience. The curriculum treats tools as means to communication and analysis ends, so questions test fitness for purpose, not brand loyalty.
What to do instead
Answer tool questions by asking what the artefact must achieve and who consumes it: precise formal semantics, quick stakeholder communication, or automated consistency checking. Prefer options that justify the tool by purpose, and be suspicious of any option claiming a single mandatory tool for all situations.
Spending disproportionate time on long scenario questions and then rushing the short definitional items, leaving easy points on the table and misreading multi-part stems.
Long scenario items feel more important and candidates fear missing their hidden complexity, so they over-invest there. The resulting time pressure causes misread negations and missed qualifiers on the items that reward quick, precise recall.
What to do instead
Do a first pass answering items you know immediately, flag long scenarios, and return to them with remaining time. For every item, read the final sentence twice to catch 'not', 'least', and 'except', and allocate a fixed budget per question based on the total item count.