Claude Certified Architect – Foundations (CCA-F) exam guide and free practice test

Why: pause_turn means a long-running server-tool turn was paused, not finished or failed; the harness continues it by passing the paused assistant response back in a subsequent request.

Server tools like web search can take multiple rounds, and the API may pause the turn and hand control back; the documented continuation is to return the paused content so the model resumes where it stopped. Option A misreads a normal control-flow signal as an error — retrying the original request throws away the progress already made. Option B treats an explicitly unfinished turn as a final answer. Option C also discards progress and burns tokens redoing the search from scratch. Exam tip: stop_reason values are loop-control signals — tool_use and pause_turn both tell the harness exactly what to send next, and neither is an error.

Why: Tool discovery in MCP uses ListToolsRequest — the schema/SDK type for the tools/list method on the wire — and the server responds with the tools it exposes, including names, descriptions, and input schemas. CallToolRequest (tools/call) is for invoking a specific tool once you know it exists; the other two message types don't exist in the protocol.

Capability discovery in MCP is explicit: the client sends a ListToolsRequest (the tools/list method on the wire) and the server replies with each tool's name, description, and input schema. Option B, CallToolRequest (tools/call), is the follow-up message used to invoke one specific tool once you know it exists. Option C and Option D are plausible-sounding but nonexistent — the protocol defines no ToolDiscoveryRequest or GetToolsMessage. Exam tip: the same list-then-call pattern repeats across primitives (resources/list, prompts/list, prompts/get), so learning the tools pair teaches you all of them.

Why: Format normalization is mechanical, so it belongs in deterministic code — the tool's own output handling or a PostToolUse hook — where it cannot be gotten wrong. Prompt-level fixes leave the model doing error-prone arithmetic on every call.

Once normalization happens before results ever reach the model, the failure mode is eliminated for every future call at zero token cost — the model only ever sees one canonical format. Option A gives the model reference material but still asks it to perform the conversions probabilistically. Option C improves the odds per conversion yet can't make arithmetic reliable across arbitrary epochs and locales. Option D makes errors more visible without making them less frequent. Exam tip: 'intermittently mangles a mechanical transformation' is the cue for the deterministic-beats-probabilistic rule — move the work out of the model and into code.

Why: Structured outputs cannot be combined with citations — the request is rejected with a 400 — and the same incompatibility applies to response prefilling.

The grammar constrains the final response text, and citation-bearing content blocks don't fit that contract, so the API rejects the combination up front rather than degrading silently. Option A, Option B, and Option C all describe silent or partial fallback behavior, but this is a hard validation error — nothing runs. Also remember the constraint's scope while you're here: the grammar governs only the direct final output, so thinking blocks, tool-use calls, and tool results are not schema-constrained. Exam tip: structured outputs' incompatibility list (citations, prefilling) is tested as a bare fact — know it cold.

Why: A 529 means the service is temporarily overloaded, and clients should back off and retry. Option B corresponds to a 401 authentication error. Option C would surface as a 400/413-style request error, not 529. Option D would be handled through tool_result blocks with is_error, not an HTTP 529.

HTTP 529 is Anthropic's overloaded_error: the service is temporarily saturated and clients should back off and retry, so Option A is correct. Option B describes a 401 authentication_error. Option C would surface as a 413 request_too_large (or a 400 validation error), never a 529. Option D never surfaces as an HTTP status at all—tool failures are reported in-band as tool_result blocks with is_error: true so the model can recover. Exam tip: memorize the retryable set (429, 500, 529) versus the fix-your-request set (400, 401, 403, 404, 413).