完整模拟考试讲解

You are about to work a full mock exam end to end. The Claude Certified Architect exam is scenario-based: each question gives you a realistic architecture situation and four options, exactly one correct. You see 4 of the 8 reference scenarios, scored on a 100-1000 scale with 720 to pass.

• No penalty for guessing — never leave a blank. An eliminated-then-guessed answer beats an empty one.
• Weight your prep by domain: D1 Agent Architecture 27%, D3 Claude Code 20%, D4 Prompt Engineering 20%, D2 Tool/MCP 18%, D5 Context & Reliability 15%.

For each question below we will read the stem, eliminate distractors, and justify the key. The skill you are building is distractor elimination, not recall.

Most wrong answers on this exam are named anti-patterns. If you memorize the anti-pattern list, you can often eliminate two or three options before you even reason about the correct one.

Top distractors to flag on sight:

• Parsing text for words like "done" to end an agent loop.
• Using an iteration cap as the primary stop mechanism.
• Enforcing critical business rules with prompts alone.
• Same-session self-review and single-pass multi-file review.
• Escalating on sentiment or model self-rated confidence.
• Requiring schema fields that may be absent.

Read every option, mentally tag each against this list, then choose what remains.

Scenario 1, Customer Support Agent. A support agent calls tools in a loop. The team asks how the loop should decide it is finished.

• A) Scan the assistant's text for "resolved" or "done".
• B) Stop after a fixed cap of 10 iterations.
• C) Inspect stop_reason; continue while it is tool_use, terminate on end_turn.
• D) Stop as soon as any tool returns a result.

Work it: A is text-parsing (anti-pattern). B treats the cap as the primary stop (caps are only a safety net). D stops too early — one tool result rarely completes the task. The loop is model-driven via stop_reason.

Answer: C.

The exam tests this repeatedly because it is the foundation of agentic design. Decisions are model-driven; hard code is reserved for guarantees. The model emits a structured stop_reason on every turn — that is the contract, so consume it instead of inventing a heuristic over free text.

• end_turn — task complete, exit the loop.
• tool_use — run the requested tools, append results to history, request again.
• max_tokens — output was truncated; raise the budget or continue.
• stop_sequence — a configured stop string was hit.

The iteration cap is your seatbelt against a runaway loop. It protects you; it does not decide for you.

Scenario 1 continued. Policy: refunds over $500 must be blocked. Where does this rule belong?

• A) In the system prompt: "Never issue a refund above $500."
• B) In a PostToolUse / outgoing-call hook that deterministically blocks the action.
• C) Ask the model to rate its own confidence before refunding.
• D) A few-shot example showing a denied $600 refund.

A and D are prompt-only — about 90% reliable, which is unacceptable when failure has financial or legal consequences. C is confidence-based gating (anti-pattern). A hook is 100% deterministic enforcement.

Answer: B.

Internalize the decision boundary the exam loves:

• Hooks = 100% deterministic. Use them when failure has financial, legal, or safety cost.
• Prompts = ~90% probabilistic. Fine for tone, formatting, soft guidance.

A related correct pattern is the programmatic precondition: block process_refund until get_customer has returned a verified identity. That is a deterministic guarantee prompt guidance cannot give you. Whenever an option says "instruct the model to always..." for a hard rule, suspect a distractor.

Scenario 3, Multi-Agent Research System. A hub-and-spoke coordinator delegates subtasks to subagents. A subagent keeps producing off-topic results. Most likely cause?

• A) Subagents do not inherit the coordinator's conversation history, and the prompt omitted the needed context.
• B) The Task calls ran in parallel instead of sequentially.
• C) The coordinator forgot to parse the subagent's text for "complete".
• D) The subagent had only 4 tools instead of 18.

B is fine — parallel Task calls are a feature. C is a text-parsing anti-pattern. D is backwards (4-5 tools is optimal; 18+ degrades selection). The defining fact: subagents start with no history; pass all context explicitly.

Answer: A.

The coordinator in hub-and-spoke owns five jobs: decompose, delegate, aggregate, route, and handle errors. Two exam-favorite details ride along with this scenario:

• Define each subagent with least privilege — name, description, system_prompt, allowed_tools scoped to its role.
• On a subagent failure, return partial results plus a coverage annotation ("source X unreachable") rather than aborting the whole workflow or silently dropping the gap.

Research answers also carry provenance: claim → source URL, doc name, quote, publication date. Conflicting stats get annotated, not arbitrarily resolved — dates often explain the conflict.

Scenario 5, Claude Code for CI/CD. You add an automated code review to a pre-merge pipeline. Which setup is correct?

• A) Run interactively and pipe the TUI output to a log.
• B) Use -p with --output-format json in a fresh isolated session, separate from any generation context.
• C) Submit the diff to the Message Batches API to save 50%.
• D) Reuse the same session that generated the code so it has full context.

A is not non-interactive. C is wrong — Batch has no latency SLA and is for non-blocking jobs, never a pre-merge gate. D is same-session self-review (the author won't challenge its own reasoning). Independent isolated review wins.

Answer: B.

The Batch API distractor appears across multiple scenarios, so lock the rule down. Message Batches are 50% cheaper with up to a 24-hour window, no latency SLA, and no multi-turn tool calling.

• Right use: overnight audits, bulk report generation, non-blocking enrichment. Correlate with custom_id; re-submit only the failures.
• Wrong use: anything blocking or time-sensitive — pre-merge checks, live support replies, an interactive agent turn.

To cut false positives in CI review, give explicit criteria ("flag only when a comment contradicts the code") instead of vague guidance like "be more precise."

Scenario 6, Structured Data Extraction. You extract invoice data via a tool-use JSON Schema. An invoice sometimes has no purchase_order field. How do you model it?

• A) Mark purchase_order required so the model never skips it.
• B) Leave it optional; require only fields that are always present.
• C) Force tool_choice: "auto" so the model can answer in prose.
• D) Drop schema validation and retry on any parse failure.

A forces the model to fabricate an absent field — the classic schema trap. C doesn't guarantee structured output. The correct move: never require a possibly-absent field, and use tool_choice: "any" to guarantee a tool call.

Answer: B.

Put it together. Read the stem, eliminate against the anti-pattern list, then commit.

You just worked five scenario questions. Carry these reflexes into the real exam:

• Loop control: drive on stop_reason (end_turn), never text-parsing; caps are a safety net only.
• Hard rules: hooks and programmatic preconditions for financial/legal/safety; prompts only for soft guidance.
• Multi-agent: subagents inherit no history — pass context explicitly; return partial results with coverage annotations.
• CI/CD: -p --output-format json, isolated/independent review; Batch API only for non-blocking jobs.
• Schemas: never require a possibly-absent field; tool_choice: "any" guarantees structure; retry-with-feedback fixes format/arithmetic, not absent data.

Answer every question, eliminate the named anti-patterns first, and 720 is well within reach. Go pass it.