Solution Architecture — study roadmap
Solution Architecture — study roadmap
The domain asks you to turn a business problem into a system whose behavior you can explain and evaluate. Study the three topics in order: define the outcome and boundaries, compose the execution, then justify the operating trade-offs. This is a private house-authored study package aligned to the official objectives; it is not an official exam or a promise about questions on the exam.
Prerequisites: understand a model request and response, the purpose of a tool call, and basic percentages. You do not need a paid API account. Allow approximately two to three hours for the lectures, retrieval practice and project. Work at the pace needed to explain the decisions without consulting the reference answer.
1. From a business outcome to a controlled architecture
Official objectives: CCARP-U1.T1.LO1 and LO2.
Start with an observable customer outcome. “More agents” and “more generated text” describe an implementation. A useful requirement states what the user can accomplish and what acceptable completion means. Define that result before selecting the model, SDK or topology.
Compare a simple candidate against a more capable one on the same cases. A policy FAQ may need retrieved evidence and an answer. A request that inspects an order and proposes an action has additional state and control boundaries. Added planning is valuable only when it helps the complete task meet its requirements.
Trace input → model/tool processing → validation → consequence → outcome. A required check belongs before the consumer that depends on it. Feedback must change subsequent behavior: the project allows one repair of a failed extracted record, followed by revalidation. A second failure stops and escalates with evidence. Resetting the repair counter on every re-entry defeats that limit.
Distinguish runtime responsibilities. The Client SDK provides direct API access and leaves the tool loop to your code. The Agent SDK runs a loop in your process. Managed Agents supplies a hosted agent and sandbox. Regardless of that choice, the application must still enforce its own task criteria and consequence boundaries.
Before advancing, produce: a one-paragraph outcome definition, a baseline comparison, a labeled responsibility diagram and one failed-path trace. Answer the Topic 1 companion quiz using only its supplied scenario facts. Revisit the boundary involved in each missed answer.
2. Compose workflows and agents from real dependencies
Official objectives: CCARP-U1.T2.LO3, LO4 and LO5.
An augmented model has capabilities such as retrieval, tools or retained context. A workflow supplies predefined control paths around those capabilities. An agent plans steps and selects tools while pursuing a task. The concepts can coexist; they are not mutually exclusive product tiers.
Write dependencies before choosing parallel execution. Extraction must precede a check that consumes the extracted record. Two independent checks can run after the shared gate, but the final decision still needs the specified join. Routing selects a specialized path from the input category. A dynamic investigation may discover its next useful subtask only after examining intermediate evidence.
At each delegation boundary, define the entity, period, question, permitted access, return format and finish condition. Separate worker contexts make the returned evidence significant. The lead must align scope and resolve contradictions before synthesizing a conclusion.
Bound the whole run as well as individual workers. The house project uses two concurrent workers, twelve total tool-call admissions and a ninety-second admission deadline. Follow-ups consume the same run budget. When the budget is exhausted, preserve supported findings and report unresolved scope. A local turn cap is useful, but cannot replace the lead's shared accounting.
Revise a plan when evidence changes the partition. If names A and B are aliases, merge that work. If product C is still unresolved and successor D is newly relevant, keep C and add a bounded D task; discovering D does not erase C. If the remaining budget cannot cover both, disclose the gap.
Before advancing, produce: a dependency diagram with its join, an augmented-model/workflow/agent choice, a worker brief and a budget-exhaustion response. Complete the Topic 2 companion quiz. Explain both why your selected option fits and why its strongest alternative does not.
3. Choose architectures by business value and operating limits
Official objective: CCARP-U1.T3.LO6.
Translate productivity into useful work accepted at the required quality, including review and rework. Translate responsiveness into an explicitly defined task boundary. Translate cost into the actual execution and retry workload. An isolated model-call price is insufficient when the architecture changes the number of calls or the number of successful outcomes.
Apply joint limits jointly. A candidate with the highest quality can still fail a mandatory latency ceiling. A fast candidate can still fail the correctness floor. A design must pass the agreed criteria, or the decision record must explicitly propose a design repair or a requirement change.
For synthetic costs, calculate the expected work rather than multiplying a retry charge by every task. If an initial execution costs $0.03 and 20% of tasks need one more $0.03 execution, mean execution cost is $0.036. These figures are exercise inputs, not vendor prices. If the denominator is accepted tasks rather than all tasks, use that denominator explicitly.
Before completing the domain, produce: a comparison table, the arithmetic behind the chosen candidate, a decision record with rejected alternatives, and a current-workload reevaluation trigger. Complete the Topic 3 companion quiz and the project acceptance checks.
Retrieval and assessment plan
| Activity | Purpose | How to use it |
|---|---|---|
| Topic lecture and transcript | Learn mechanisms and worked decisions | Pause before the reveal; state your reasoning |
| Topic companion quiz | Check what the topic taught | Review every option explanation after submission |
| Domain flashcards | Retrieve one fact or distinction at a time | Explain before flipping; repeat uncertain cues |
| Architecture project | Apply all six objectives together | Keep artifacts and run the supplied local checks |
| Exam-bank questions | Practice standalone architecture decisions | Use the stem's requirements, not memorized answer position |
Topic quiz questions and exam-bank questions have separate identities and roles. The full course mock papers are a later course-wide assessment; completing this domain does not itself establish whole-exam readiness.
Primary reading
- Agent SDK overview: loop and runtime ownership.
- Claude prompting best practices: explicit chaining, inspection and independent delegated work.
- Create custom subagents: separate context, access and maximum-turn controls.
- Define success criteria and build evaluations: multidimensional task acceptance.
The project thresholds, task contracts and example outputs are house design exercises. The documentation supports the mechanisms; your own workload determines whether a particular architecture meets its contract.