Skip to content

Practice questions: Architect – Foundations

Thirty-five original practice questions written for this repository against the public exam blueprint, framed inside the six published scenarios the way the real exam frames its items. They are unofficial practice aids, not items from the live exam, which is covered by a non-disclosure agreement. For unlimited practice, use Practice with Claude or the repository's built-in exam coach skill.

1. Support resolution agent: Agentic Architecture & Orchestration. Your support agent resolves most tickets but sometimes loops indefinitely, re-calling lookup_order on the same order. What is the correct structural fix?

  • A. Raise max_tokens so the loop has room to finish
  • B. Remove the lookup_order tool
  • C. Add explicit loop-termination conditions: cap tool iterations, detect repeated identical calls, and route to escalate_to_human when progress stalls
  • D. Lower the temperature
Answer and rationale

C. Agent loops need engineered termination: iteration budgets, repeated-call detection, and an escalation path when the agent cannot progress. Token budget (A) delays the symptom, removing a needed tool (B) breaks resolution, and temperature (D) does not bound iteration.

2. Support resolution agent: Tool Design & MCP Integration. process_refund currently accepts any amount. Support policy caps agent-initiated refunds at $200; larger refunds need a human. Where does that rule belong?

  • A. In the system prompt, phrased firmly
  • B. In the model's reasoning, since it reads the policy
  • C. In quarterly staff training
  • D. Enforced in the tool layer: the tool rejects amounts over the cap with a structured error, and a hook or the tool itself routes larger cases to escalation
Answer and rationale

D. Hard policy limits are enforced deterministically at the tool boundary, not requested of the model. Prompt phrasing (A) and model reasoning (B) are probabilistic where the requirement is absolute, and training (C) does not constrain the agent at all.

3. Multi-agent research: Agentic Architecture & Orchestration. Your coordinator delegates to search, analysis, and report subagents. Final reports cite sources that do not support their claims, though each subagent behaves sensibly alone. What is the most likely architectural cause?

  • A. Provenance is lost at handoffs: findings and their sources are not passed together in a structured form, so the report writer pairs claims with citations by guesswork
  • B. The report subagent's model is too small
  • C. The web is unreliable
  • D. Too many subagents are running in parallel
Answer and rationale

A. In multi-agent pipelines, provenance survives only if the handoff format carries claim and source together. That failure mode produces exactly this symptom while every stage looks locally fine. Model size (B), source quality (C), and parallelism (D) do not explain correct facts paired with wrong citations.

4. Multi-agent research: Context Management & Reliability. The analysis subagent returns 30,000-token document dumps to the coordinator, which then fails on context limits. What is the right fix?

  • A. Give the coordinator a bigger context window
  • B. Have subagents return structured extracts, findings with citations and confidence, while full documents stay in the subagent's context or a scratchpad file
  • C. Have the coordinator drop the oldest messages silently
  • D. Run the analysis twice and keep the shorter answer
Answer and rationale

B. Context isolation is the point of subagent delegation: raw bulk stays at the edge, distilled results travel. A larger window (A) postpones the failure, silent dropping (C) loses arbitrary information, and rerunning (D) changes nothing structural.

5. Claude Code for development: Claude Code Configuration & Workflows. Your monorepo has frontend and backend directories with different conventions, and one team-wide rule about commit style. Where does each piece of configuration belong?

  • A. Everything in one root CLAUDE.md
  • B. Each engineer's personal user-level CLAUDE.md
  • C. The commit rule in the project-level CLAUDE.md; the per-area conventions in path-scoped rules under .claude/rules/ that load only when matching files are touched
  • D. A wiki page linked from the README
Answer and rationale

C. The hierarchy exists for exactly this: shared rules at project scope, conditional conventions path-scoped so context is spent only where relevant. One root file (A) loads everything everywhere, personal files (B) diverge per engineer, and a wiki (D) never reaches the model.

6. Claude Code in CI: Claude Code Configuration & Workflows. Your CI job runs Claude Code to review pull requests, and the pipeline must parse the results mechanically. Which invocation is correct?

  • A. Interactive mode with a human copying the output into CI
  • B. Plan mode, which is safer for automation
  • C. A shell script that greps the human-readable transcript
  • D. Non-interactive mode with -p, with --output-format json and a schema so the review arrives as machine-readable, validated output
Answer and rationale

D. Headless CI use is what -p with JSON output and a schema is for: deterministic invocation, parseable results. A human in the loop (A) is not CI, plan mode (B) is a review gate for interactive work rather than an output format, and grepping prose (C) breaks on the first wording change.

7. Claude Code in CI: Prompt Engineering & Structured Output. The automated reviewer flags dozens of trivial style nits per pull request, and engineers have started ignoring it. Which change addresses the false-positive problem the way the blueprint suggests?

  • A. Define explicit review criteria in the prompt: what to flag, what to ignore, and a severity bar, with a few worked examples of in-scope and out-of-scope findings
  • B. Run the review twice and post only findings that appear both times
  • C. Cap the reviewer at three findings per pull request
  • D. Route all findings to a channel nobody reads
Answer and rationale

A. Precision comes from explicit criteria and few-shot examples that draw the boundary between signal and noise. Double-running (B) filters randomness but not systematic nit-picking, an arbitrary cap (C) drops real findings on bad days, and (D) is surrender.

8. Structured data extraction: Prompt Engineering & Structured Output. Invoices sometimes lack a purchase-order number, and your extraction schema must handle that honestly while catching real misses. What is the right schema design?

  • A. Make every field required so nothing is missed
  • B. Make purchase_order nullable, so absence is recorded as null, and validate that it is present whenever the document type requires it
  • C. Make everything optional to avoid validation errors
  • D. Have the model invent a plausible number when one is missing
Answer and rationale

B. Schema design encodes reality: genuinely optional data is nullable, and conditional requirements are validated downstream. All-required (A) forces fabrication or failure on legitimate documents, all-optional (C) blinds you to true misses, and invention (D) is data corruption.

9. Structured data extraction: Context Management & Reliability. Your pipeline reports 98% field accuracy, measured on the documents the schema validated cleanly. An auditor calls the number misleading. Why?

  • A. Accuracy should be measured only on the hardest documents
  • B. 98% is below industry standard
  • C. Validation-clean documents are a biased sample: the honest measure comes from a labeled sample drawn across all documents, including ones that failed or barely passed validation
  • D. Field accuracy is not a real metric
Answer and rationale

C. Measuring only where the system already succeeded inflates the estimate; calibration requires a labeled sample representative of the full input stream. Hardest-only (A) biases in the opposite direction, the standard claim (B) is invented, and (D) is false.

10. Developer productivity agent: Tool Design & MCP Integration. Your codebase-exploration agent has get_file_contents, read_source, and fetch_file tools that all read files, and it frequently picks poorly among them. What is the correct fix?

  • A. Add a fourth, better file-reading tool
  • B. Fine-tune the model on the tool list
  • C. Randomize which tool the harness dispatches
  • D. Consolidate to one file-reading tool, or give the survivors sharply differentiated descriptions that state exactly when each applies
Answer and rationale

D. Tool selection runs on descriptions; overlapping tools with vague descriptions produce dithering. Consolidation or sharp differentiation is the documented cure. Adding overlap (A) worsens it, fine-tuning (B) is disproportionate, and randomization (C) institutionalizes the confusion.

11. Agentic Architecture & Orchestration. A support workflow resolves tickets by looking up an account, checking entitlement, and drafting a reply, always in that order. Which architecture is correct?

  • A. A deterministic pipeline that calls the model at each defined step
  • B. A single agent that decides each step at runtime
  • C. Three agents that negotiate the order between them
  • D. One prompt containing all three steps
Answer and rationale

A. A known, fixed sequence should be encoded rather than rediscovered on every run, which makes it cheaper, faster, and testable step by step. Runtime decisions (B, C) add nondeterminism for no gain, and one prompt (D) removes the checkpoints between steps.

12. Agentic Architecture & Orchestration. What is the strongest justification for splitting work across subagents?

  • A. The task has many steps
  • B. Separate lines of work each need their own context, and mixing them degrades both
  • C. Subagents are faster than a single agent
  • D. The output must be assembled from several sections
Answer and rationale

B. Subagents exist to isolate context, so the case for them is contamination between concerns rather than volume. Step count (A) and sectioned output (D) suit a workflow, and delegation usually adds latency rather than removing it (C).

13. Agentic Architecture & Orchestration. An agent loops between two tools without converging. What is the most appropriate first control?

  • A. Increase the context window so it can see more history
  • B. Switch to a larger model
  • C. Impose a step ceiling and define the terminating condition explicitly
  • D. Remove one of the two tools
Answer and rationale

C. Non-termination is bounded by an explicit stop condition and a hard ceiling, which contains cost and makes the failure visible. More context (A) and a larger model (B) do not guarantee convergence, and removing a tool (D) may break the task.

14. Agentic Architecture & Orchestration. Which property most increases the operational risk of an agentic design?

  • A. It calls more than one model
  • B. It produces structured output
  • C. It runs longer than a minute
  • D. It takes irreversible actions without a checkpoint
Answer and rationale

D. Reversibility governs the cost of being wrong, which is the dominant risk in autonomous execution. Multiple models (A), structure (B), and duration (C) affect cost and complexity rather than blast radius.

15. Agentic Architecture & Orchestration. How should an agentic system handle a step whose result it cannot verify?

  • A. Surface the unverifiable step for human confirmation before acting on it
  • B. Proceed, since the model is usually right
  • C. Retry the step until two runs agree
  • D. Log the step and continue
Answer and rationale

A. An unverifiable result is exactly where human judgment belongs, before it is acted upon. Assuming correctness (B) and logging without stopping (D) both act on unchecked output, and agreement across runs (C) establishes consistency rather than truth.

16. Agentic Architecture & Orchestration. A team proposes an agent for a task where every input is well formed and every rule is known. What should the architect recommend?

  • A. An agent, for future flexibility
  • B. A deterministic implementation, reserving model calls for the genuinely ambiguous parts
  • C. An agent with a low step limit
  • D. A multi-agent design for separation of concerns
Answer and rationale

B. Known rules over well-formed input are code, and using a model there buys nondeterminism at a price. Speculative flexibility (A), a constrained agent (C), and multiple agents (D) all keep the cost without the need.

17. Agentic Architecture & Orchestration. What most improves the debuggability of an agentic system in production?

  • A. Reducing the number of tools
  • B. Using a single model for every step
  • C. Recording the inputs, tool calls, and outputs of each step as a trace
  • D. Increasing the step limit
Answer and rationale

C. A per-step trace is what makes a nondeterministic run reconstructable after the fact. Fewer tools (A) and one model (B) simplify without explaining, and a higher ceiling (D) makes failures longer rather than clearer.

18. Claude Code Configuration & Workflows. Where should conventions that apply to everyone working in a repository be recorded?

  • A. In each developer's personal settings
  • B. In the pull request template
  • C. In a pinned chat message
  • D. In a CLAUDE.md committed to the repository
Answer and rationale

D. Committed project memory is versioned, reviewable, and shared, which is what a team convention requires. Personal settings (A) do not propagate, and templates (B) and messages (C) are not read as working context.

19. Claude Code Configuration & Workflows. What distinguishes work suited to headless mode?

  • A. It is well defined and repeatable, so it can run unattended in automation
  • B. It is complex and needs close supervision
  • C. It requires many tools
  • D. It produces a long output
Answer and rationale

A. Headless execution suits bounded, repeatable work where no one is watching. Supervision (B) argues for interactive use, and tool count (C) and output length (D) do not determine suitability.

20. Claude Code Configuration & Workflows. A skill and a subagent could both address a need. What decides between them?

  • A. Skills are always preferable
  • B. Whether the need is reusable know-how or an isolated line of work with its own context
  • C. Whether the task is long
  • D. Whether the repository already has a CLAUDE.md
Answer and rationale

B. The two solve different problems: a skill packages reusable procedure, a subagent isolates context. A blanket preference (A), duration (C), and existing files (D) do not address that distinction.

21. Claude Code Configuration & Workflows. What is the correct use of a hook in a Claude Code workflow?

  • A. To hold instructions the model should follow
  • B. To store project context
  • C. To enforce a deterministic action at a defined point, independently of the model
  • D. To define which model is used
Answer and rationale

C. Hooks run as code at fixed points, so they enforce rather than request. Instructions (A) and context (B) belong in project memory, and model choice (D) is configuration.

22. Claude Code Configuration & Workflows. Claude Code performs well for one engineer and inconsistently across the team. What is the most likely cause?

  • A. The others need more capable machines
  • B. The repository is too large
  • C. The others are using different terminals
  • D. The working conventions live in one person's local setup rather than in the repository
Answer and rationale

D. Context that is not committed does not travel, which produces exactly this asymmetry. Hardware (A), repository size (B), and terminal choice (C) do not explain a difference in output quality.

23. Prompt Engineering & Structured Output. A pipeline requires output that always validates against a schema. What is the correct approach?

  • A. Declare the schema as a tool the model must call, and validate on receipt
  • B. Ask for the schema in the prompt and validate afterwards
  • C. Ask for JSON and repair malformed output in code
  • D. Use a lower temperature
Answer and rationale

A. A declared schema makes the structure part of the contract rather than a request, and validation on receipt closes the loop. Prompt requests (B), downstream repair (C), and temperature (D) all leave the shape to chance.

24. Prompt Engineering & Structured Output. Extraction is accurate for common cases and fails on rare formats. What is the most effective response?

  • A. Raise the temperature to encourage flexibility
  • B. Add examples covering the rare formats and define what to return when a field is absent
  • C. Switch to a larger model
  • D. Ask the model to try harder on unusual inputs
Answer and rationale

B. Rare cases fail because they are unspecified, and examples plus an explicit absent-field rule specify them. Temperature (A) adds variance, a larger model (C) is not aimed at the gap, and exhortation (D) is not a specification.

25. Prompt Engineering & Structured Output. What should a schema define for a field the source document may not contain?

  • A. Nothing, since the model will omit it
  • B. A default value that looks plausible
  • C. An explicit representation for absence, so a missing value is distinguishable from an unfilled one
  • D. A free-text field for notes
Answer and rationale

C. Absence must be representable, or downstream code cannot tell a genuine gap from a failure. Silent omission (A) is ambiguous, plausible defaults (B) fabricate data, and a notes field (D) does not make the state machine-readable.

26. Prompt Engineering & Structured Output. Which practice most improves consistency across a long-running structured extraction job?

  • A. Randomising the order of documents
  • B. Increasing the output token limit
  • C. Running each document twice
  • D. Fixing the prompt, the schema, and the model version, and recording them with the output
Answer and rationale

D. Consistency requires that the things that shape output are pinned and recorded, so results remain comparable and reproducible. Ordering (A) is irrelevant, the token cap (B) affects length, and duplicate runs (C) measure variance without removing it.

27. Prompt Engineering & Structured Output. A prompt mixes the instruction, the data, and the output format in continuous prose. What is the first improvement?

  • A. Separate the sections so the instruction, the input, and the required format are distinguishable
  • B. Shorten it
  • C. Move it into the system prompt
  • D. Add emphasis to the format requirement
Answer and rationale

A. Structure lets the model tell instruction from data, which is the most common source of confusion in long prompts. Shortening (B) may remove needed detail, relocation (C) does not clarify, and emphasis (D) does not separate.

28. Tool Design & MCP Integration. What is the strongest indicator that a tool surface needs redesign?

  • A. It contains more than ten tools
  • B. The model regularly selects a tool that cannot accomplish the request
  • C. The tools return JSON
  • D. The tools are implemented across several services
Answer and rationale

B. Repeated wrong selection is evidence that the tools are not distinguishable from their descriptions, which is a design fault. Tool count (A), return format (C), and implementation topology (D) are not themselves problems.

29. Tool Design & MCP Integration. How should a tool that performs an irreversible action be designed?

  • A. With a description warning the model to be careful
  • B. So that it requires more parameters
  • C. So that authorisation and confirmation are enforced outside the model
  • D. So that it is declared last
Answer and rationale

C. Irreversibility is controlled by the surrounding system, because a prompt-level warning is a request rather than a guarantee. Extra parameters (B) and ordering (D) do not constrain authority.

30. Tool Design & MCP Integration. A tool returns a large payload that consumes most of the context window. What is the right change?

  • A. Increase the context window
  • B. Summarise the payload with a second model call
  • C. Call the tool less often
  • D. Return only what the task needs, with a way to request more detail
Answer and rationale

D. Tools should return task-relevant results rather than everything available, which keeps context for reasoning. A larger window (A) postpones the problem, a second call (B) adds cost and a failure point, and calling less often (C) does not change the payload.

31. Tool Design & MCP Integration. What belongs in a tool's description?

  • A. What the tool does, when to use it, and what its parameters mean
  • B. The implementation language and framework
  • C. The service level agreement
  • D. The name of the team that owns it
Answer and rationale

A. The description is the model's selection guide, so it must answer purpose, applicability, and parameters. Implementation detail (B), service levels (C), and ownership (D) are irrelevant to the choice.

32. Context Management & Reliability. A long agentic run degrades in quality as it proceeds. What is the most likely cause?

  • A. The model version changed mid-run
  • B. Context has accumulated until relevant material competes with stale material
  • C. The temperature was set too low
  • D. The tools became slower
Answer and rationale

B. Progressive degradation over a long run is the signature of context accumulation and drift. Versions do not change mid-run (A), low temperature (C) reduces variety rather than quality, and tool latency (D) does not affect correctness.

33. Context Management & Reliability. What is the right way to carry state across a compaction boundary?

  • A. Rely on the model to remember what mattered
  • B. Increase the context window so compaction is never needed
  • C. Write the decisions and constraints that must persist into an explicit summary that is carried forward
  • D. Restart the task after compaction
Answer and rationale

C. Persistence must be deliberate, because compaction is lossy by design. Relying on recall (A) is unreliable, a larger window (B) only delays the boundary, and restarting (D) discards the work.

34. Context Management & Reliability. Which measure most improves reliability for a workflow that must not silently produce wrong output?

  • A. A larger model
  • B. A longer prompt
  • C. More examples in the prompt
  • D. A validation step that can reject output and trigger a defined fallback
Answer and rationale

D. Reliability against silent failure requires detection and a defined response, which is what validation with a fallback provides. Model size (A), prompt length (B), and examples (C) improve the average case without catching the bad one.

35. Context Management & Reliability. What should be measured to know whether a production agentic system is healthy?

  • A. Task success against a defined criterion, plus the rate and shape of failures
  • B. Total tokens consumed
  • C. Average response time
  • D. The number of tool calls per run
Answer and rationale

A. Health is defined by whether the system accomplishes the task and how it fails when it does not. Tokens (B), latency (C), and call counts (D) are cost and behavior signals that say nothing about correctness.

These questions are the maintainer's original work for self-assessment. Study guide · Study notes · Mock exam · Repository index