Solution Design and Architecture

What this domain tests

17% — roughly 11 of 63 scored items, the second-heaviest domain after Integration. It is the domain that most defines CCAR-P's character.

The Professional exam is architectural-judgment heavy. First-hand accounts from candidates who sat all four exams describe the distractors here as comparatively obvious once you hold a real decision framework, and rate CCAR-P easier than the Foundations exams for an experienced architect — the difficulty ordering feels inverted because Foundations tests recall of mechanics while Professional tests whether you can pick the right shape of system under a stated constraint. Prepare accordingly: memorizing parameter names will not help you here, and having actually shipped and operated an end-to-end system will.

Two format facts worth internalizing:

• Items are multiple-choice and multiple-response, with each item stating how many responses to select. Solution-design items lend themselves to "Select 2" because architecture answers naturally pair a pattern with a control. Scenario-matching styles also appear.
• No official practice exam exists for CCAR-P. The exam guide's sample items are the only published specimens.

The recurring cognitive move in this domain: the stem describes a business situation with an embedded constraint — an SLA, an audit requirement, a volume, a budget, a regulatory boundary — and then offers four architectures. Usually two are competent engineering that ignores the constraint, one is over-engineering, and one fits. The most common single error is reaching for the most sophisticated architecture available rather than the simplest one that satisfies the requirement. The exam rewards restraint as often as it rewards ambition.

Theory outline

1. Translating business problems into Claude-based solutions (Task 1.1)

Before any pattern selection, the architect's first job is turning a stated business complaint into a specified system. The exam tests this indirectly: items that look like technology choices are frequently decided by a requirement buried in the first sentence of the stem.

A disciplined translation answers five questions:

Not every problem is an LLM problem. A deterministic rules engine, a database query, a search index, or a conventional ML classifier is often the correct architecture, and options that recognize this are sometimes the intended answer. Claude earns its place where the work involves natural language, unstructured input, ambiguity, judgment, synthesis, or generation — and specifically where the variety of inputs defeats enumeration by rules.

Feasibility signals the exam plants in stems:

• "Answers must be identical every time for the same input" → deterministic component, or heavy constraint plus caching; pure generation is a poor fit.
• "The answer must be auditable to a source" → retrieval with citation, not parametric recall.
• "Regulation requires a human decision-maker" → the system drafts and evidences; it does not decide.
• "The rules are 40 pages and change monthly" → a strong LLM fit, because encoding and maintaining them as code is the actual pain.
• "10 million records nightly, cost-sensitive" → batching, tiering, and a hard look at whether a cheaper classifier handles the bulk.

Scoping the first version. The architecturally mature answer to "automate the whole department's workflow" is to identify the highest-volume, lowest-consequence, most-measurable slice and build that first, with a measured baseline. This is not timidity; it is how you get evidence before spending. Expect at least one item where the correct answer is a bounded pilot with a defined success metric rather than the comprehensive platform.

2. End-to-end architecture: input, processing, output, feedback (Task 1.2)

The official task statement spells out four stages, and the fourth is the one candidates skip. A design without a feedback loop is an incomplete answer, and the exam knows it.

Input stage. Acquisition and normalization: where the request or document comes from, parsing heterogeneous formats, validation, PII detection and redaction where required, authentication of the caller, and rate limiting. Design questions: what does the system do with malformed input, oversized input, or input in an unsupported language?

Processing stage. Context assembly (retrieval, prior state, user profile), prompt construction, model invocation with a chosen configuration, tool execution, and any orchestration across steps. Design questions: what is the ordering of the prompt (stable content first for cacheability — Domain 3), what is the timeout and retry policy, what happens when a tool is down?

Output stage. Structured output where a downstream system consumes it, validation against a schema, grounding and citation checks, safety filtering, formatting for the surface, and delivery. Design questions: what is returned when validation fails — a retry, a fallback, or an explicit error the user can act on?

Feedback stage. This is what turns a deployment into a system that improves:

• Explicit signals: thumbs up/down, corrections, edits the user made to a draft, escalation to a human.
• Implicit signals: acceptance rate, abandonment, time-to-resolution, rework rate, whether the drafted action was executed unchanged.
• Operational signals: retrieval hit rate, refusal rate, tool error rate, cost and latency distributions.
• The loop that closes them: captured failures feed the evaluation set; the evaluation set gates changes; changes are measured against the baseline. Without the capture step, every improvement is anecdote.

Failure paths are part of the architecture, not an operational afterthought. Every stage needs a defined behavior when it cannot do its job: retrieval returns nothing, a tool times out, the model is unavailable, confidence is low, the output fails schema validation. The general shape of a good answer is degrade explicitly rather than fabricate — return "I don't have information on that", route to a human, or fall back to a simpler deterministic path, and make the degraded state visible in telemetry.

State and idempotency. Multi-step and long-running designs need to answer: where does state live between steps, what happens if the process is interrupted midway, and is re-executing a step safe? An architecture that can double-charge a customer on retry has a design bug, not an operations bug.

3. Choosing the architectural pattern: workflow, agentic, augmented LLM (Task 1.3)

The three named patterns form a ladder of increasing capability and increasing cost of ownership. Climb only when forced.

The decision rule: can you enumerate the steps in advance?

• If yes, and they are the same every time → workflow. You get determinism, testability, a fixed cost profile, and an audit trail that a compliance reviewer can read.
• If no — the path depends on what earlier steps discover, and the space of situations is too large to enumerate → agentic. You are buying adaptability.
• If the task is a single transformation that just needs current facts or one tool → augmented LLM. Do not build an orchestration layer around a task that is one call plus retrieval.

Common workflow shapes worth naming, since items often describe one without naming it: prompt chaining (each step's output feeds the next, with a checkable intermediate), routing (classify the request, then dispatch to a specialized path), parallelization (independent subtasks concurrently, then aggregate — including running the same task multiple ways and voting), orchestrator-worker (a coordinating step dispatches dynamically-determined subtasks), and evaluator-optimizer (generate, critique, revise in a loop against explicit criteria).

What agentic autonomy actually costs, stated plainly because the exam tests whether you know the bill:

• Latency variance. A run that takes three tool calls today may take eleven tomorrow. Hard p95 SLAs and unbounded agent loops are in tension.
• Cost variance. Per-request cost is a distribution, not a number. Budget accordingly, and cap.
• Reduced auditability. "Why did it do that?" has a different answer every run. When a regulator or an audit trail needs a repeatable, explainable path, a workflow is the architecturally correct choice even though an agent could do the job.
• Larger blast radius. Runtime-chosen actions mean the permission scope must assume the model will use everything you gave it (Domain 3's capability bloat).
• Harder evaluation. You must evaluate trajectories, not just final outputs.

When agentic is right anyway: open-ended investigation, tasks where the next step genuinely depends on what the previous step found, long-tail variety that defeats enumeration, and situations where a human expert would also have to explore. The mature design is usually agentic within a bounded envelope — an agent with a narrow tool set, an iteration ceiling as a safety backstop, programmatic gates on consequential actions, and a defined escalation path — rather than a choice between "fully scripted" and "fully autonomous".

(Loop mechanics — stop reasons, tool-result handling, hooks — are CCA-F Foundations material and are not what Professional items are testing. Here the question is always which shape, and at what cost.)

4. Multi-agent systems and orchestration strategies (Task 1.4)

Multi-agent is the most over-applied pattern in the field, which makes "should this be multi-agent at all?" a productive exam question.

Legitimate reasons to split into multiple agents:

Illegitimate reasons, and what to do instead:

• "The prompt got long" → refactor the prompt, or use retrieval. Splitting into agents to shorten a prompt adds coordination cost to solve an editing problem.
• "It feels more sophisticated" → the exam's favorite over-engineering distractor.
• "One step occasionally fails" → fix or verify that step; a second agent supervising the first doubles cost and adds a new failure mode.
• Steps with hard data dependencies → these run sequentially regardless of how many agents you create. Splitting them buys nothing and costs handoffs.

Orchestration topology. The standard shape is hub-and-spoke: one coordinator, N specialized subagents, and all inter-agent communication routed through the coordinator. Subagents do not talk to each other directly. The hub buys you one place to observe the system, one error-handling path, and controlled information flow. Free-form peer-to-peer chatter between agents is the anti-pattern — it is unobservable, its failure modes compound, and no single component knows the state of the whole.

The coordinator's responsibilities: decompose the goal, select only the subagents the request actually needs (not the full pipeline every time), delegate with complete context, aggregate and validate results, and iterate where coverage is insufficient.

Two design risks worth stating explicitly, because they show up as symptoms in stems:

• Context does not flow implicitly. Each delegated unit of work must carry everything it needs. A subagent producing generic output that ignores prior findings is almost always missing context that lived only in the coordinator.
• Decomposition must cover, not merely partition. Slicing a broad goal into narrow slivers leaves gaps between them; overlapping slices waste tokens and produce conflicting summaries. Partition scope deliberately and check the union against the original question.

Cost reality: a multi-agent system multiplies token consumption — coordinator reasoning, per-subagent context, and aggregation all cost. It is worth it when parallelism or isolation buys something real. It is indefensible when a single well-designed workflow would produce the same output.

5. Decomposition techniques for complex problems (Task 1.5)

Decomposition is the skill underneath both workflow design and multi-agent design, and the exam treats it as its own objective.

Two strategies, matched to how knowable the work is:

Decomposition heuristics that generalize to any item:

• Cut at verifiable boundaries. Every step should produce an output you can check — a schema-valid object, a classification, a citation-backed claim. If you cannot say how a step is validated, you have not decomposed, you have merely subdivided.
• Separate extraction from judgment. Pulling facts out of a document and deciding what to do about them are different tasks with different failure modes and different evaluation criteria. Fusing them hides which one failed.
• Local passes then an integration pass. For work spanning many items — reviewing 40 files, reconciling 200 invoices — analyze each unit individually for depth, then run a separate pass whose only job is cross-unit consistency. A single pass over everything catches local issues and misses the relationships between them.
• Map before you plan on open-ended work. "Add tests to this legacy codebase" starts with surveying structure and identifying high-impact areas, then a prioritized plan that adapts as dependencies surface — not a fixed pipeline (the steps are unknown) and not unplanned wandering (no prioritization).
• Route by difficulty. Classify first, then send the easy majority down a cheap deterministic or small-model path and the hard remainder to a stronger one. This is decomposition in the cost dimension and it is frequently the intended answer when a stem pairs high volume with a quality floor.
• Do not over-decompose. Every boundary is a handoff, and handoffs lose context and add latency. Three well-chosen steps beat nine narrow ones.

6. Aligning solutions to business value pillars (Task 1.6)

This objective is the most distinctly Professional one in the domain and the easiest to under-prepare. The exam guide names five pillars — efficiency, transformation, productivity, cost, and performance SLAs — and expects you to connect an architecture to the value it is supposed to produce, then to the metric that would prove it.

Three exam-relevant behaviors:

Name the pillar the stem is buying, then check each option against it. A design that lowers cost while breaching the stated latency SLA is a wrong answer regardless of how elegant it is. A design that adds an evaluator-optimizer loop to a workflow whose stated goal is cost reduction has spent the savings.

Baseline first. You cannot claim an improvement without a measured before. When a stem describes a stakeholder asking whether the system is working, the correct answer usually involves establishing the pre-deployment baseline and instrumenting the outcome metric — not adding capability.

Count total cost of ownership, not inference cost. Model spend is one line. Human review time, engineering maintenance, evaluation infrastructure, index rebuilds, and the cost of errors all belong in the comparison. An architecture that halves inference cost while doubling the human review burden has made the business worse off, and items do test this.

Trade-offs must be stated, not hidden. The professional posture is naming what a decision costs: choosing a workflow over an agent buys auditability and predictable cost at the price of adaptability; adding a verification pass buys accuracy at roughly double the latency and spend. (Communicating those trade-offs to stakeholders and managing expectations is Domain 6; making them correctly is here.)

Worked problems

Problem 1. An insurer wants to automate first-pass review of claims documents. The process is the same for every claim: extract fields from submitted PDFs, validate them against policy records, flag exceptions, and route. Regulators require that the reviewer be able to explain exactly how any claim was handled. Volume is 30,000 claims/day. Which architecture fits best?

A. An autonomous agent with document, policy-lookup, and routing tools that decides its own approach per claim B. A workflow: extract with schema-validated structured output, validate against policy records in code, classify exceptions with the model, route deterministically — with human review on flagged exceptions C. A multi-agent system with an extraction agent, a validation agent, a compliance agent, and a routing coordinator D. A single large prompt containing all policy rules and each claim, returning a routing decision

Approach: Two constraints decide this before you consider anything else. The steps are fully enumerable and identical per claim, and regulators require an explainable, repeatable path. Both point at a workflow, where the model does the parts that need language understanding and code does the parts that need determinism. High volume reinforces it: predictable per-claim cost and latency are what a workflow gives you.

Why the others fail: A buys adaptability nobody asked for and pays in cost variance, latency variance, and exactly the auditability the regulator requires — a different path per claim is the failure mode here, not a feature. C is the over-engineering distractor: the steps are strictly sequential with hard data dependencies, so multiple agents add handoffs and token cost while buying no parallelism. D fuses extraction, validation, and judgment into one un-checkable call, so a wrong routing decision cannot be attributed to a stage, and there is no schema validation anywhere.

Answer: B

Problem 2. A support organization deploys a Claude-based assistant. Six weeks in, leadership asks whether it is working, and the team can only report uptime and request volume. Which two additions most directly close the gap? (Select 2)

A. Instrument the business outcome the deployment was meant to move — deflection rate and time-to-resolution — against the pre-deployment baseline B. Capture explicit and implicit feedback (thumbs, escalations, edits to drafted replies) and route failures into a growing evaluation set C. Upgrade to a more capable model tier so quality improves D. Add more tools so the assistant can resolve a wider range of tickets E. Increase logging verbosity on the web tier

Approach: The architecture is missing its fourth stage. Input, processing, and output exist; there is no feedback loop, so the system cannot be assessed and cannot improve. Closing it takes two things: an outcome metric measured against a baseline, which answers leadership's question, and a capture mechanism that turns real failures into an evaluation set, which is what makes future changes defensible rather than anecdotal.

Why the others fail: C and D add capability before anyone knows what is broken — and with no measurement, neither change could be shown to have helped. E adds volume to infrastructure logs that already report a healthy system; a wrong answer returns a clean 200, which is precisely why request-level telemetry did not surface the problem.

Answer: A and B

Problem 3. A research team's assistant answers questions requiring synthesis across web sources, an internal document store, and a metrics database. Each query needs a different, unpredictable mix. Latency of a minute or two is acceptable; answers must cite sources. An architect proposes one agent holding all three tool families with a long system prompt covering all three. Assess.

A. Correct — one agent is simpler and avoids coordination overhead B. A coordinator with specialized subagents per source, each returning condensed cited findings, is better here: the subtasks are genuinely independent and parallelizable, and context isolation keeps raw source material out of the coordinator's window C. Correct — split it into three separate applications the user chooses between D. Replace it with a fixed workflow that always queries all three sources and concatenates the results

Approach: Check the legitimate reasons for multi-agent, and here three of them hold at once. The source queries are independent — nothing about the web search depends on the metrics query — so they parallelize and the latency budget can absorb the coordination. They have distinct tool and permission scopes. And each produces bulky raw material that should be condensed before it reaches the synthesis step, which is the context-isolation argument. This is what multi-agent is actually for.

Why the others fail: A is defensible as a starting point but gives up parallelism on independent work and loads one context window with raw output from three sources, which is where synthesis quality degrades. C pushes the routing decision onto the user, who came to the system precisely because they do not know which source holds the answer. D is the "always run the full pipeline" anti-pattern — the mix is stated to be unpredictable, so a coordinator should select the sources a given query needs rather than paying for all three every time.

Answer: B

Problem 4. A retailer processes 4 million product descriptions per month for categorization. Currently every description goes to the most capable model tier. Accuracy is 97%, cost is over budget by a wide margin, and there is no latency requirement — the job runs nightly. Which redesign best fits?

A. Move everything to the cheapest tier and accept whatever accuracy results B. Route by difficulty: a cheap fast path handles the high-confidence majority, with escalation to the stronger tier on low confidence or ambiguity, and run the whole job through asynchronous batch processing C. Add an evaluator-optimizer loop so every categorization is critiqued and revised D. Cache the model responses so repeated descriptions are not reprocessed

Approach: Name the pillar: this is cost, with an accuracy floor to protect and — critically — no latency constraint, which is an explicit invitation to trade latency for unit cost. Two levers compose. Difficulty routing keeps the strong model for the slice that actually needs it instead of paying for it on easy items. Batching converts the absent latency requirement into a discounted unit rate. Together they cut spend without a blanket quality sacrifice.

Why the others fail: A trades away the accuracy floor uniformly, including on the hard items where the tier difference matters most. C is the exact inversion of the goal — a critique-and-revise loop roughly doubles cost on a workload that is already over budget. D is a genuinely useful supporting optimization, but product descriptions are largely unique, so dedupe caching addresses a small fraction of a problem whose bulk is per-item inference on novel text.

Answer: B

Problem 5. A bank wants to use Claude to answer customer questions about their own accounts and to execute transfers on request. Which architectural posture is most appropriate for the transfer capability?

A. Give the agent the transfer tool and instruct it in the system prompt to confirm details before transferring B. Have the system prepare and evidence the transfer — validated parameters, the policy basis, and the customer's stated intent — and require an explicit human or customer confirmation step outside the model before execution C. Give the agent the transfer tool but log every transfer for weekly review D. Use a more capable model tier so the transfer instructions are followed reliably

Approach: Place human-in-the-loop by consequence and reversibility. A money transfer is high-value and effectively irreversible, which puts it firmly in the gate-it category — and the gate must be programmatic, sitting outside the model, because a prompt instruction has a non-zero failure rate no matter how it is phrased. The read-only account questions can flow freely; the consequential action is what gets the control. Note the shape of the answer: the system does the work and produces the evidence, and a human or the customer authorizes.

Why the others fail: A relies on a prompt for a guarantee. C is detective, not preventive — the money has moved by the time anyone reads the log. D confuses model capability with authorization control; a stronger model still has a non-zero failure rate on an irreversible action, and reliability is not the same as a guarantee.

Answer: B

Problem 6. A team is asked to build an assistant that answers questions over a 12-page internal policy document that changes about twice a year. They propose a RAG pipeline with a vector store, a chunking strategy, a reranker, and a nightly re-index job. Evaluate.

A. Correct — RAG is the standard architecture for document question answering B. Over-engineered: the document is small, stable, and entirely relevant, so an augmented-LLM design that places the full policy in a cached stable prefix is simpler, faster, and avoids a retrieval failure mode C. Correct, but they should also add a multi-agent layer for complex questions D. Under-engineered: they should fine-tune a model on the policy document

Approach: Climb the ladder only when forced. Twelve pages is small, the content is stable, and per-request relevance is high — every one of the conditions that makes retrieval worthwhile is absent. Putting the whole policy in the prompt as a stable cached prefix gives lower latency, lower cost on repeat traffic, no chunking decisions, no index to version, and no possibility of the correct passage failing to be retrieved. Recognizing when not to build the sophisticated thing is an examinable skill.

Why the others fail: A applies a pattern by reflex rather than by fit, and inherits an entire failure mode (retrieval misses) for no benefit. C stacks more architecture on an already over-built design. D is the wrong tool entirely: fine-tuning teaches behavior and form, not current facts, and it makes a document that changes twice a year into a retraining event — the policy needs to be in context, where it can be cited and updated by editing a file.

Answer: B

Exam traps

• Reaching for the most sophisticated architecture. Multi-agent and autonomous agents are the seductive wrong answers when a workflow, or a single augmented call, satisfies the stated requirement. Climb the ladder only when the simpler tier provably fails.
• Ignoring the constraint buried in the stem. Latency SLAs, audit requirements, budgets, and regulatory boundaries decide these items. Two options will be good engineering that does not address the constraint.
• Agentic design where the path must be auditable. Runtime-chosen paths differ per run. When a regulator, an auditor, or a compliance reviewer needs a repeatable explanation, a workflow is the correct answer even though an agent could do the work.
• Multi-agent to fix a long prompt. Context length is a prompt or retrieval problem. Multi-agent earns its cost on parallelism, context isolation, and distinct permission scopes — not on editing.
• Splitting sequential, data-dependent steps across agents. They still run in order; you have added handoffs and token cost for no wall-clock gain.
• Peer-to-peer agent chatter. Route through a coordinator. Direct agent-to-agent communication inside one system destroys observability and compounds failure modes.
• Designs with no feedback loop. The official task statement names it explicitly: input, processing, output, feedback. An option that omits capture, measurement, and the path from failures into an evaluation set is incomplete.
• Designs with no failure path. Empty retrieval, tool timeouts, low confidence, and schema-validation failures all need defined behavior. Degrade explicitly; never fabricate.
• Uniform human review. Gate by consequence and reversibility. Reviewing everything destroys the efficiency case; reviewing nothing ignores irreversible actions.
• Prompts used as guarantees for consequential actions. Irreversible, high-value, or regulated actions get a programmatic gate outside the model. "Instruct it more firmly" and "use a bigger model" are the two standard distractors.
• Fine-tuning proposed to inject current facts. Fine-tuning shapes behavior and format. Facts that change belong in context, retrieved and cited.
• Improving before measuring. Without a pre-deployment baseline and an instrumented outcome metric, no change can be shown to have worked. When a stem asks "is it working?", the answer is measurement, not capability.
• Counting inference cost as total cost. Human review time, maintenance, evaluation infrastructure, and the cost of errors all belong in the comparison. Halving inference spend while doubling review burden is a loss.
• Assuming the answer must involve an LLM. Deterministic rules, a database query, or a conventional classifier is sometimes the correct architecture, and the exam is willing to make that the right answer.