Solution Design & Architecture

Solution Design & Architecture is the second-largest domain on CCAR-P at 17% — roughly 11 of the 63 questions. It is the domain that sets the tone for the whole exam, because almost every question is a choice between designs that would all work, at different costs.

The blueprint covers translating business problems into Claude-based solutions, designing end-to-end architectures with feedback loops, selecting between workflow, agentic and augmented-LLM patterns, designing multi-agent systems and orchestration strategies, applying decomposition techniques, and aligning a solution to business value — efficiency, cost, and performance SLAs.

What separates this from the Foundations tier is the presence of consequences. Foundations asks which pattern a description matches. Professional gives you a constraint — a per-transaction cost ceiling, a p95 latency target, a compliance boundary, a team that has to operate this in six months — and asks which design survives it. The correct answer is frequently the less sophisticated one, and candidates who have spent a year building agents find that genuinely hard to pick.

If you are budgeting study time, treat this domain and Integration as the pair that decides your result. Together they are 36% of the exam, and the reasoning they test is the same reasoning: name the trade-off, then choose against a stated constraint rather than against a general preference.

What the exam actually tests

• —Choosing between a workflow, an agent, and a single augmented LLM call — and naming what each costs
• —Which composition pattern a scenario calls for: routing, prompt chaining, parallelisation, orchestrator-workers, evaluator-optimiser
• —When multi-agent fan-out is a context strategy rather than a speed strategy, and when it is neither
• —Where the feedback edge lives in an end-to-end design, and what consumes it
• —Decomposing a pipeline so different steps can run on different models and effort levels
• —Tying an architectural choice to a stated business constraint instead of to abstract quality

Workflow, agent, augmented LLM — the decision is about specifiability

A workflow orchestrates model calls through code paths you wrote: predictable cost, predictable latency, a trace you can read. An agent lets the model decide the control flow at runtime: it handles tasks you could not fully specify in advance, and its cost per request has no upper bound you set in code.

Four questions decide it. Is the task genuinely hard to specify ahead of time? Does the outcome justify higher cost and latency? Is the model capable at this task? Can errors be caught and recovered from — by tests, review, or rollback? A 'no' on any of them means drop to the simpler tier.

The exam-relevant consequence is variance. A workflow's spend per request sits in a narrow band; an agent's has a long tail. When a stem gives you a per-transaction cost model or a hard latency budget, that tail is the thing that breaks it, and the agentic option is the distractor.

Composition patterns and what selects between them

The augmented LLM — one model call with retrieval, tools and memory attached — is the unit. Everything above it is composition.

Routing fits when the input class determines the handler and you can classify cheaply. Prompt chaining fits when each step's output is the next step's input and you want a checkable gate between them. Parallelisation fits two shapes: sectioning, where independent subtasks run at once, and voting, where the same task runs several times and the results are aggregated. Orchestrator-workers fits when you cannot enumerate the subtasks until you have seen the input. Evaluator-optimiser fits when you have a clear rubric and iteration measurably improves the output.

Whether the number of subtasks is known in advance is what separates parallelisation from orchestrator-workers, and it is the fact exam questions most often bury in a clause.

The feedback edge is part of the architecture

The blueprint's phrasing is input, processing, output, feedback loops. The first three are where most candidates' designs stop, and the fourth is where production systems differ from demos.

A feedback edge is a concrete path: a human correction, a thumbs-down, a downstream rejection, a support escalation — captured, routed somewhere, and consumed by something. The realistic destinations are an evaluation set that grows from production failures, a retrieval corpus that receives the corrected document, a prompt or skill that gets amended, or a routing table that learns which inputs to send elsewhere.

A design with no path from a bad output back into the system does not stay at its launch quality. It degrades quietly, because the world moves and nothing tells the system. Expect at least one question where the strongest-looking design is the one missing this edge.

Multi-agent orchestration: what it buys, what it costs

Delegating to subagents buys two things: parallel execution, and — more importantly — context isolation. Each subagent works in its own context window, so reading-heavy exploration never fills the coordinator's. Framing fan-out as a context strategy first is the professional read.

It costs a briefing on the way in and a report on the way out, per subagent. Subagents do not inherit the coordinator's conversation; whatever the task description omits, the subagent does not know. They share a filesystem, not a history.

Good fits: genuinely independent tracks, work that would otherwise flood one context, specialists with narrow tool sets. Poor fits: anything one loop could finish in a handful of tool calls, and verification — checking the work belongs in the main loop, where the coordinator already holds the context needed to judge it.

Decomposition against the cost and latency envelope

Decomposition is what lets a pipeline use different models for different steps. Extraction, classification, normalisation and filtering are high-volume, low-judgement work a small fast model does well; the synthesis or decision step is where capability earns its price. Effort level is a second dial on the same axis — lowering effort on a routine step often recovers more latency than downgrading the model, and costs less quality.

The business-value framing matters here. The blueprint names efficiency, transformation, productivity, cost and performance SLAs, and questions tend to state one of them explicitly. An answer that improves accuracy when the stated constraint was p95 latency is wrong, however good the technique. Read for which pillar the scenario is measured on before comparing options.

Where candidates go wrong

How to study this domain

Work this domain by rewriting scenarios rather than by reading pattern lists. Take any system you have shipped and write down, in one line each: the pattern, the constraint that selected it, and the pattern you rejected. If you cannot name the rejected alternative, you have a habit rather than a decision — and that is exactly the gap CCAR-P questions are built around.

When practising, read the stem twice. The first pass identifies what is being designed; the second finds the constraint, which is usually one clause — a cost ceiling, a percentile latency target, a data boundary, a team that inherits this. Then eliminate against that constraint alone. Options in this domain are engineered so that several are correct in general and only one survives the stated condition.

Drill the specific discriminators: known versus unknown subtask count, independent versus dependent steps, reversible versus irreversible actions, and bounded versus unbounded per-request cost. Practise saying out loud what each wrong option would cost in production. If you cannot name the failure it causes, you have not understood the question well enough to answer it, and guessing between two plausible designs is where this domain takes points off experienced architects.

Common questions