A research system gives each supplier a polished risk summary. Yet the final comparison is unreliable: one summary reports a contractual commitment, another reports actual performance, and a third leaves out the source of its conclusion. Each worker completed its assigned document, but the system never agreed on what evidence the comparison needed.
Useful CCAR-F mock exam practice asks you to reason about the complete design. You need to explain what each component does, what information crosses between components, and how the system detects a missing or invalid result. These three original questions for Claude Certified Architect – Foundations (CCAR-F) develop that reasoning through document analysis, tool design, and code review.
This is independent Timo practice. It is not official Anthropic exam content, recalled material, a full timed assessment, or a prediction of your exam result.
Amotion AI, a registered member of the Claude Partner Network, runs Timo to help individuals develop their Claude skills, prepare for certification and work toward AI consulting. For an aspiring architect, Timo combines Claude learning with original architecture practice and practical assessments. The questions here help you explain how components exchange evidence and how the complete system behaves when one step fails.
What you are practising at Architect Foundations level
The provider's Architect Foundations guide describes design judgement across Claude Code, Claude application interfaces, agent workflows, tool integration, and the reliability of context and structured outputs. The Timo Architect Foundations guide provides a track overview.
Use the provider’s certification listing and current guide to confirm eligibility and assessment details before planning your exam.
An agent is a model-driven component that can choose steps or tools while carrying out a task. A workflow connects components in a defined sequence. The architecture determines how those parts collaborate: their inputs, responsibilities, permissions, and responses when something fails. More agents do not automatically produce a better architecture. The useful question is whether dividing the work improves the system's ability to deliver and verify the required result.
Practice question 1: dividing a research workflow
A research assistant must analyse 80 supplier documents, extract standard risk fields, compare suppliers, and flag conflicting evidence. The required fields include the supplier, risk category, relevant finding, and supporting source location. A single agent frequently loses earlier details as its context grows. Context is the material available to the model while it performs a step.
The team needs a design that reduces this pressure while preserving comparable, reviewable evidence. Which architecture is the best starting point?
A. Split documents between workers, have each produce a concise narrative summary, and ask the final agent to resolve differences from those summaries.
B. Group documents by supplier, let each worker define the fields it finds relevant, and compare the resulting supplier reports in a final pass.
C. Use document-level workers with a shared extraction schema, retain source references, validate each result, and run a separate comparison pass over the structured evidence.
D. Use one agent for each risk category, give every agent all documents, and merge their category conclusions into the supplier comparison.
Best answer: C. Each worker receives a bounded task: extract the agreed information from a document and record where it came from. A shared schema is a defined set of fields and types used by every worker. It makes a missing value visible and prevents one worker's free-form conclusion from silently replacing the evidence another worker is expected to provide.
Validation checks whether each result meets that contract. The comparison step can then group records by supplier, compare the same fields, and flag disagreement. For example, two documents may give different notice periods. Retained references let a reviewer inspect both passages and determine whether one document supersedes the other, instead of asking the final agent to choose whichever summary sounds more convincing.
Document-level extraction does not mean every question can be resolved within one document. Cross-document interpretation belongs in the comparison and review stage. The final step can request the specific source passages it needs to investigate a conflict without receiving all 80 raw documents again. Validation of shape should also be supplemented with source checks: a well-formed record can still contain an inaccurate extraction.
Why the alternatives are weaker: A reduces the material each worker sees, but narrative summaries may omit qualifications and supporting references needed for comparison. B keeps a supplier's documents together, which can be useful, but allows each worker to decide what fields matter. The resulting reports may compare unlike things. D gives each agent a focused risk category while repeating the full document burden, and still leaves the final evidence reconciliation undefined.
Practice question 2: designing an MCP boundary
An internal Claude application needs to read approved customer records and open a service request. Its backend also exposes account deletion and bulk export operations, which are outside this application's responsibility.
The team is using Model Context Protocol (MCP), a standard way for AI applications to connect to tools and data. An MCP server can expose operations to the application, but the protocol does not decide which business permissions the user should have. Which design best limits the tool access to the task?
A. Expose a generic backend tool but use an allowlist in the prompt to limit operations to record reads and request creation.
B. Expose all read operations under the user's identity and keep request creation behind a separate confirmation step.
C. Create narrow read-record and create-request tools, but use one shared service identity and filter returned fields in the application.
D. Create narrow read-record and create-request tools with explicit schemas, user-scoped authorization, server-side validation, and typed error results.
Best answer: D. The tool surface—the operations the agent can request—should match the application's job. A read-record tool and a create-request tool give each action a clear purpose, input format, and result. They do not give this assistant a reason or a means to invoke deletion or bulk export.
User-scoped authorization means the service checks the requested operation against the permissions of the authenticated user. Server-side validation means trusted service code checks the request before performing the operation or returning protected contents. These controls remain effective even if a model produces a mistaken request. Typed errors give the caller a distinct result for a permission failure, invalid input, or temporary outage so it can choose the appropriate recovery.
The read and creation operations may need different rules. A user entitled to view a record is not automatically entitled to create every type of service request. The implementation must enforce each operation's actual permissions rather than treating connection to the MCP server as blanket approval.
Why the alternatives are weaker: A places the restriction in instructions while leaving a broad operation available. The backend capability remains usable if the model requests it. B correctly preserves user identity but exposes unrelated reads, including operations the assistant does not need. C narrows the tool names but retrieves under a shared identity with potentially broader authority. Filtering returned fields afterwards does not enforce the user's permission at the point of access.
Practice question 3: reviewing a large code change
Claude Code is reviewing a migration that changes authentication logic across many files. Separate file reviews have found local defects. Previous reviews, however, missed an invalid transfer of identity information between middleware, which processes incoming requests, and the service that manages signed-in sessions.
The team needs attention to both individual files and the complete identity path. Which workflow best addresses those needs?
A. Run focused file-level reviews, record findings in a defined format, then perform a cross-file review of identity flow, state transitions, and error handling.
B. Run file-level reviews and ask the final agent to rank the combined comments by severity using file summaries only.
C. Assign agents to middleware, services, and tests, then accept the review when each owner reports no local critical issue.
D. Run two full-change reviews with different models and investigate only findings on which both models agree.
Best answer: A. A file-level review can inspect whether an individual function validates its input and handles errors. It may not reveal that another component calls the function with a different assumption. The integration review follows the actual path from request handling through session lookup to the final access decision.
For example, one file may represent an expired session as an empty value while another interprets that value as permission to continue without a session. Each function can appear internally consistent while their combination produces the wrong result. A cross-file review must inspect those contracts and transitions directly, including what happens when the session service fails.
Record local findings with enough context to locate and verify them, then use the integration pass to inspect the relationships. A targeted test of the identity path provides stronger evidence than a collection of favourable file summaries.
Why the alternatives are weaker: B prioritises existing comments but never inspects the path that previous reviews missed. C creates useful component ownership but assumes local success proves system success. D adds another opinion, yet agreement is not proof of correctness. Requiring agreement before investigation can discard a real defect that only one reviewer noticed, and does not focus attention on the known integration risk.
Review your answer as a design decision
After each question, write a short architecture decision record: a note that names the requirement, the chosen design, the strongest alternative, and why the choice fits the constraints. Avoid stopping at broad adjectives such as “secure” or “scalable.” State which operation is unavailable, which evidence is retained, or which failure the design can detect.
For the supplier exercise, a useful record explains why the shared schema matters, how missing source references are rejected, and when a reviewer must inspect conflicting passages. It should also acknowledge the cost: extraction, validation and comparison are additional steps that must be maintained. Their value lies in the comparability and traceability the original design lacked.
Make the architecture testable
Build a small document-review workflow with an extraction step and a comparison step. Include a normal record, a missing reference, and two conflicting values. Check that the workflow accepts the complete record, flags the missing evidence, and preserves the conflict for review.
Capture an end-to-end trace: a record of the source, the intermediate outputs, the checks, and the final result. Then ask another person to locate the first failure in a deliberately broken run. If they cannot, improve the records crossing the component boundaries. The Claude certification readiness checklist can help you choose further resources that explain architecture decisions under explicit constraints.
CCAR-F mock exam FAQs
Is this an official CCAR-F practice exam?
No. Timo wrote these original questions independently. Anthropic has not supplied, reviewed, or endorsed them.
Are these questions copied from an exam guide?
No. The guide informs the role scope; the scenarios and answer options were developed independently. They do not reproduce live or protected assessment content.
How is this different from developer practice?
The emphasis here is on the relationships among components: how work is divided, what crosses a boundary, and how the complete system behaves when a part fails. Implementation knowledge supports that reasoning, but the design must account for the whole workflow.
Do I need multiple agents for every architecture exercise?
No. Use the smallest design that satisfies the requirement. These questions include cases where dividing work is useful, but extra agents add coordination and validation work that must be justified.
Can a three-question preview predict my exam result?
No. It cannot represent the full blueprint or reproduce official assessment conditions. Use it to identify design assumptions you need to examine further.
How can Timo help me prepare for CCAR-F?
Timo supports CCAR-F preparation with Claude learning, original architecture scenarios and practical assessments. Use this preview to identify weaknesses in document workflows, tool boundaries and cross-component review, then create a decision record that explains your design and its failure paths. Amotion AI, which runs Timo, is a registered member of the Claude Partner Network.
Apply for CCAR-F preparation and name the skills you want to improve. Membership is US$50 for two months; Timo reviews your profile and shares the enrollment details before payment. Current learning resources and onboarding instructions arrive by email. Anthropic sets official exam eligibility and fees and awards the credential.