Domain 1 — Solution Design and Architecture (17%)

17% of the exam, roughly 11 questions. Translating a business problem into a Claude architecture, and being able to say why this shape and not another.

1.1 From business problem to architecture

The professional discipline is refusing to choose a pattern until you have the constraints. Four questions come before any design decision:

1. What outcome is being bought? Not "summarise documents" but "cut claim handling from four days to one, without raising the error rate."
2. What is the cost of being wrong? This sets the review model, the guardrails and how much verification the design must carry.
3. What are the hard constraints? Latency budget, data residency, retention, sector regulation, existing identity systems, integration surfaces you cannot change.
4. How will success be measured? Agreed before build, not after.

A design that satisfies the functional requirement but violates a constraint discovered later is the canonical professional failure, and the exam builds questions around exactly that.

1.2 Choosing the shape

The professional framing of the workflow-versus-agent decision is a governance one as much as an engineering one: an agentic system is harder to bound, harder to audit and harder to cost-forecast. In a regulated context that is often decisive on its own, and an option that reaches for autonomy where a workflow satisfies the requirement is wrong twice over.

1.3 End-to-end architecture

A complete design names all of these, and questions frequently hinge on the one that was omitted:

• Entry point and identity — who is calling, authenticated how, authorised to reach what.
• Retrieval and grounding — where the facts come from and how they are attached.
• The model layer — tier, deployment surface, fallback behaviour.
• Tools and side effects — what the system can change in the world, and under what authority.
• Validation — schemas, business rules, guardrails.
• Human review — which cases, by whom, within what time.
• Observability — what is logged, what is measured, what alerts.
• Failure behaviour — what happens on timeout, refusal, rate limit or degraded quality. Graceful degradation is a design decision, not an accident.

1.4 Aligning with business value

Professional-level questions ask you to defend a design commercially, not only technically. The useful framing is unit economics: cost per transaction against the cost of the alternative, including the human time the system replaces or the review time it adds. A design that is elegant and costs more per unit than the process it replaces has failed, and one that saves money by removing a control the regulator requires has failed worse.

Recurring distractor — the option that maximises capability with no reference to the constraint in the stem. At this level, "use the most capable model everywhere" and "make it fully autonomous" are almost never right, because they answer a question about ambition rather than about requirements.

← Previous: The mental model  |  Next: Domain 2 — Claude Models, Prompting and Context Engineering →