Preparing for Claude Certified Architect – Foundations is easier when you organize your work around architectural decisions rather than memorizing definitions. The exam’s subjects overlap: choosing an agent workflow affects which tools are exposed, how context is preserved, where human review belongs and what the application should do when evidence conflicts. A productive study plan therefore combines short domain reviews with concrete system-design exercises that you can explain to another engineer.
This plan supports candidates preparing for the CCAR-F exam, also listed as Anthropic CCA-F in the Exam-Topics catalog. The CCA-F and CCAR-F labels identify one Architect Foundations examination, not separate syllabuses. Study readiness does not automatically establish eligibility: Anthropic currently restricts certification registration to people aged 18 or older working at Claude Partner Network organizations who use a recognized company-email domain. These technical activities complement—not replace—the official Anthropic certification blueprint and its current exam-access policies.
Organize your study around the five published domains
The current Anthropic Academy blueprint assigns 27% to Agentic Architecture & Orchestration, 18% to Tool Design & MCP Integration, 20% to Claude Code Configuration & Workflows, 20% to Prompt Engineering & Structured Output, and 15% to Context Management & Reliability. These figures describe the stated relative emphasis, not an exact fixed question count for a particular exam delivery. In practice, an architecture case may involve several domains simultaneously.
| Exam area | What to explain without notes | Practice artifact |
|---|---|---|
| Agentic architecture (27%) | Why an agent is or is not needed; delegation and finite workflow boundaries | One-page state diagram with exits |
| Tool design and MCP (18%) | Tool descriptions, request schemas, permissions and honest error states | Read-only tool contract |
| Claude Code (20%) | Repository scope, settings, hooks, skills, review and CI controls | Team rule set plus tests |
| Prompts and structured output (20%) | Examples, extraction criteria, valid schemas and factual verification | Schema with adversarial test cases |
| Context and reliability (15%) | Evidence provenance, context limits, checkpointing and recovery | Runbook for interrupted work |
Use the percentages to distribute breadth, then adjust sessions according to your actual mistakes. If a diagnostic exercise repeatedly exposes uncertainty about tool permissions, address that weakness even if you already spent time on the tool-design domain. A weighted syllabus is a coverage map, not a substitute for measuring readiness.
Understand question formats and six scenario themes
Anthropic’s July 2026 Architect Foundations exam guide identifies 60 questions in multiple-choice and multiple-response formats, 120 minutes of testing time and a 720 passing score on a 1,000-point scale. A scaled 720 is not a guarantee that 72% of correct selections pass.
A multiple-response item can require more than one answer, so read the instruction before evaluating options. The guide publishes six scenario themes, four of which are used on a particular exam form. Prepare across all six rather than predicting a form.
- Support-resolution agent: separate authorized read-only diagnosis from actions that need human or service approval; plan for stale evidence and failures.
- Claude Code generation: scope repository instructions, edits and tests without allowing model prose to override deployment controls.
- Multi-agent research: coordinate search, analysis and synthesis; keep source IDs, date context, uncertainty and partial failures visible in a cited report.
- Developer productivity: choose repository discovery, reading, editing or command tools according to actual execution authority.
- CI/CD review: analyze a known commit, ground findings in code and tests, measure false positives and protect deployment credentials.
- Structured extraction: distinguish valid JSON from factual truth, preserve conflicting source spans and validate before privileged operations.
For each theme, draft a safe success path and a failure case. State the authority for the next action, the evidence that makes the decision possible and what the application should do when evidence is unavailable. The published themes illustrate learning objectives; they do not reveal confidential live exam questions.
Days 1–2: build the architecture map
Start with a scenario: a company’s support team needs an assistant that helps engineers investigate service incidents. Staff can search a knowledge base, retrieve current monitoring data, propose safe diagnostic commands and draft a resolution summary. Only authorized systems and people may apply production configuration changes. Define the assistant’s allowed outputs, evidence requirements, data boundaries and stopping conditions before selecting any framework.
Compare three designs. A fixed sequence performs a known health check and generates a structured report. A bounded single agent chooses among diagnostic reads when the failing service is not known in advance. A delegated design sends independent questions about logs and recent deployments to specialists while a coordinator reconciles the answers. Explain the cost of every added model step and why parallelism helps only when tasks are independent. Then write how each design behaves when monitoring is unavailable.
Draw a flow showing the user request, identity check, source retrieval, evidence review, diagnostic proposal, optional human decision and response. Add a hard limit on diagnostic steps and an explicit unresolved result. Agent architecture should make each point where a model can propose—but cannot commit—an action visible to reviewers. A fixed workflow is preferable when no genuine adaptive decision is needed.
Days 3–4: design tool contracts and permission boundaries
Define a tool named get_service_health. Its inputs could include an authorized service identifier, a bounded time window and an optional environment. State who is allowed to request that information, what sources it reads, how output freshness is represented and what the tool must never do. An informative tool description helps Claude select it; target-service authorization determines whether the requested data may actually be returned.
Give the tool distinct responses for valid data, not found, access denied, invalid input and temporary unavailability. A service that is unreachable is not evidence that the service is healthy or missing. Write a recovery policy: perhaps a bounded retry for a transient diagnostic read, no retry for an authorization denial, and escalation when the monitoring source remains inaccessible. Avoid using the model’s reassuring explanation as a substitute for these programmatic states.
Draw the MCP host/client/server relationship and label where authentication and authorization occur. Test an untrusted log message containing instructions: it may be evidence about an incident but cannot override policy. MCP permissions must be enforced by the application and target service, not by the model’s interpretation of that log.
Days 5–6: review Claude Code as a governed workflow
Make a miniature repository with a script, tests, sample configuration and a project instruction document. Define which directories the assistant may inspect, how to execute tests, how changes should be reviewed and which secrets are off limits. Separate stable team conventions from temporary task instructions. Write one narrow reusable skill that checks schema compatibility and explain who maintains it.
Try a planning-only task before allowing edits. A good plan lists affected files, likely dependency changes, tests, rollbacks and unresolved risks. It does not claim that reviewing a plan makes unsafe commands acceptable. Model hooks as additional validation or notification points, with policy enforcement also present in the repository, CI service and deployment permissions.
Design a CI workflow that requests a failure summary and proposed fix. Distinguish reading test results from modifying deployment environments. Claude Code settings should restrict credentials, prevent untrusted pull-request content from granting authority, and keep deployment decisions subject to explicit review.
Days 7–8: practise prompts and structured output together
Use a fictitious incident ticket with three conflicting observations: a user’s report, a monitoring alert and an older runbook. Ask for a structured incident-triage record with service name, observations, source identifiers, evidence timestamps, conflicting claims and an escalation decision. Include a field that can explicitly record incomplete information; do not force a model to choose a confident conclusion when the evidence is contradictory.
Test representation errors separately from meaning errors. Invalid JSON is a schema problem. Valid JSON that states the wrong service is affected is a factual problem. A complete incident record that proposes an unapproved production change is a workflow-policy problem. Each failure needs its own check: schema validation, source confirmation, and deterministic authorization respectively. The system can ask for a corrected record without treating a second model response as proof of truth.
Write two few-shot examples with real purpose: one case that needs more evidence and another that permits a grounded diagnostic recommendation. Add an adversarial source that attempts to override the safety rules. Structured outputs can make the result machine-readable; separate evidence checks must still determine whether the recommendation is trustworthy.
Days 9–10: test context handling and an interrupted session
A working context window is not the authoritative state of a real incident. Place current service health, source document versions, permissions and completed diagnostic operations in independently retrievable records. Give the assistant small relevant excerpts and stable source identifiers rather than copying an entire monitoring history into every prompt. The objective is reliable evidence use, not maximal context size.
Now simulate a long investigation that requires compaction. Identify which conversational details may be summarized, what provenance references must survive, and what must be fetched again because it could have changed. Interrupt the session after a diagnostic tool call but before the final summary. On resumption, verify the latest diagnostic state rather than inventing whether a previous operation finished.
Test conflict handling by making a knowledge-base article disagree with newer monitoring data. A sound context management design preserves both sources and their timestamps, identifies which source is authoritative for each fact, and escalates questions that remain unresolved. Compaction must not silently erase those conflicts.
Days 11–12: combine domains in an end-to-end design review
Give yourself a new requirement: the support assistant must handle several independent services, use an external MCP diagnostic provider and operate under stricter audit policies. Redraw the architecture without simply adding agents everywhere. Decide which tasks remain deterministic, which specialist needs a limited tool set, how model responses are checked and who can approve a proposed production change. Show what happens when an external provider times out or returns ambiguous data.
Review the design under three counterfactuals. First, the user loses access to a service halfway through the investigation. Second, the model selects an expensive diagnostic tool repeatedly. Third, an external log contains text crafted to misdirect the assistant. Identify the enforcement point in each case, the evidence your audit trail would retain and the rollback or escalation behavior. If the answer is “the prompt tells the model not to do it,” revisit the boundary.
Evaluate quality with objective measures: percentage of valid diagnostic summaries, correctness of tool selection, number of unjustified source claims, unnecessary tool calls, correct escalations, and response time. A fluent explanation is not sufficient if a trace shows unauthorized data access or repeated tool invocations. Keep the review grounded in system behavior.
Days 13–14: close gaps rather than collecting more slogans
Revisit your decision log for every scenario. Describe each error as an engineering mistake: missing authority check, confusing empty data with a failed lookup, using a flexible agent where a fixed workflow is better, or believing that schema-compliant output is necessarily correct. Write one improved design rule and one regression test for each mistake. This creates a concise personal study record.
Use official documentation to resolve disputed product behavior and confirm the objective list. Unofficial practice questions are not evidence that a feature is tested in a particular way. Anthropic’s certification rules control exam timing, format and access; verify them before booking rather than treating previous summary figures as permanent.
Your final readiness measure is whether you can defend a complete architecture under uncertainty. When asked “What should happen next?”, state the authorized actor, the relevant evidence, the tool boundary, the expected failure state and the stopping or recovery condition. That discipline both prepares you for architecture-oriented certification material and produces systems that are safer to operate after the exam.