[Anthropic] CCAR-F - Claude Certified Architect Foundations Practice Questions & Study Guide

Free [Anthropic] CCAR-F - Claude Certified Architect Foundations Practice Questions Preview

• Question 1

  An engineering team is building a custom agentic loop using the Claude API. On each iteration, the loop inspects the API response before deciding whether to continue calling tools or stop. Which field-and-value check should drive that decision?

  • A. Check whether the response's content array includes a text block, and treat any accompanying text as the stop signal, since assistant turns can include explanatory text alongside a tool_use block
  • B. Check whether stop_reason equals 'tool_use', then execute the requested tool(s) and resubmit the results
  • C. Check whether usage.output_tokens falls under a fixed threshold, and stop the loop once token usage drops below that number
  • D. Check whether the conversation has exceeded a hard-coded number of turns and stop there, since bounding total turns is a common safety guardrail against runaway loops when tool use fails to converge to end_turn

  Correct Answer: B

  Explanation:

  Option B is correct. The authoritative loop-control mechanism in Claude's agentic loop is the `stop_reason` field, and specifically the value `'tool_use'` signals that the model wants to invoke a tool and expects results before continuing.

  Reason

  Under the official exam blueprint's Domain 1 knowledge summary, the agentic loop lifecycle is explicitly defined around stop_reason 'tool_use' vs 'end_turn'. When the API returns stop_reason == 'tool_use', the correct action is to execute the requested tool(s) and append the tool results back to the conversation history before resubmitting — this is the deterministic, machine-readable signal the API provides precisely so developers don't need to infer intent from text content. When stop_reason is 'end_turn', the model has signaled it has no further tool calls and the loop should terminate. This field-and-value check is the canonical, reliable loop-control mechanism.

  Why the other options are not as suitable

  • Option A is wrong because the presence of a text block in the content array is not a stop signal — the model routinely emits both a text block and a tool_use block in the same response, so treating accompanying text as a completion indicator would cause premature termination mid-task, which the blueprint explicitly calls out as an anti-pattern.
  • Option C is wrong because output_token count does not signal tool invocation or completion intent; token usage varies based on response verbosity and has no semantic relationship to whether the model wants to continue using tools, making it an unreliable and architecturally incorrect termination signal.
  • Option D is wrong because hard-coding a fixed turn count as the primary termination signal is explicitly identified in the Domain 1 blueprint as an anti-pattern ('avoiding anti-patterns like… arbitrary iteration caps'); a fixed cap may truncate legitimate multi-step workflows or allow runaway loops on short tasks, and is acceptable only as a high safety ceiling, not as the primary loop-control mechanism.

  Citations

  • https://anthropic-partners.skilljar.com/claude-certified-architect-foundations-certification

• Question 2

  A developer implements loop termination by scanning the assistant's latest message for phrases like 'Task complete' or 'I'm finished' and exiting the loop when found. During testing, the agent sometimes exits prematurely because it used that phrase inside an explanation of a subtask, and sometimes never exits because it phrased completion differently. What is the correct fix?

  • A. Have the agent call a dedicated mark_complete tool as an explicit completion signal, and detect that tool call instead of scanning the message text
  • B. Route the assistant's final message through a separate classifier call that judges whether the phrasing indicates completion, replacing exact-string matching with model-based judgment
  • C. Restrict the phrase search to only the last two sentences of the message rather than the entire response, on the assumption that completion phrases are more reliable near the end
  • D. Replace text-pattern matching with a check on stop_reason == 'end_turn', which the model sets deterministically when no further tool calls remain

  Correct Answer: D

  Explanation:

  Option D is correct. Replacing fragile natural-language pattern matching with a check on `stop_reason == 'end_turn'` is the architecturally sound fix because it uses the model's own deterministic API-level signal rather than interpreting assistant text.

  Reason

  The Domain 1 blueprint explicitly identifies 'parsing natural-language completion signals' as an anti-pattern in agentic loop design. The API's stop_reason field is the purpose-built, deterministic mechanism: when the model has no further tool calls to make, it sets stop_reason to 'end_turn', regardless of the phrasing it chose in its explanatory text. This eliminates both failure modes described — premature exit when completion language appears in a subtask explanation, and infinite looping when the model phrases completion differently — because neither scenario affects the stop_reason value.

  Why the other options are not as suitable

  • Option A is wrong because introducing a dedicated mark_complete tool adds unnecessary complexity and still relies on the model choosing to call that tool — if the model fails to call it or calls it prematurely, the same class of reliability problems recurs; furthermore, the blueprint's canonical fix for loop termination is stop_reason, not a sentinel tool call.
  • Option B is wrong because routing the final message through a secondary classifier call adds latency, cost, and a new failure mode (the classifier itself can misclassify), and it still fundamentally relies on natural-language interpretation rather than the deterministic API signal — it replaces one probabilistic text-parsing approach with another.
  • Option C is wrong because restricting the phrase search to the last two sentences is an arbitrary heuristic that does not address the root cause; the model can still use completion language in a penultimate sentence when describing a subtask, and may still phrase actual completion without any recognizable phrase, so both original failure modes remain.

  Citations

  • https://anthropic-partners.skilljar.com/claude-certified-architect-foundations-certification

• Question 3

  A document-extraction agent is hard-capped at 3 tool-call iterations to keep runtime bounded, but some documents genuinely require 5 or more tool calls (e.g., multiple lookups) to complete correctly. Extractions on longer documents are silently truncated. What is the recommended architectural fix consistent with agentic loop best practices?

  • A. Raise the fixed cap to a larger number, such as 10 iterations, so that most documents complete before hitting the limit
  • B. Replace the iteration cap with a token-usage cap, halting the loop once cumulative tool-call tokens cross a fixed budget rather than counting calls
  • C. Let the loop continue based on stop_reason until it reaches 'end_turn', adding a high safety ceiling only as a guardrail against runaway loops, not as the primary termination signal
  • D. Have the model estimate the number of tool calls a document will require up front, and set that document's iteration cap to the model's estimate before the loop starts

  Correct Answer: C

  Explanation:

  Option C is correct. Allowing the loop to continue based on stop_reason until 'end_turn' is reached — with only a high safety ceiling as a guardrail — is the architecture the CCAR-F blueprint prescribes, contrasted directly against using arbitrary iteration caps as the primary termination signal.

  Reason

  The Domain 1 blueprint explicitly calls out 'avoiding anti-patterns like… arbitrary iteration caps' as a core agentic loop skill. The correct pattern is to let stop_reason drive termination: the loop continues while stop_reason is 'tool_use' (executing and resubmitting tool results) and stops when stop_reason reaches 'end_turn'. A hard numeric cap (e.g., 3 or 10 iterations) used as the primary termination signal will silently truncate tasks that legitimately require more steps — exactly the failure mode described. The blueprint sanctions a high safety ceiling only as a last-resort guardrail against genuinely runaway loops, not as the architectural mechanism that drives normal termination.

  Why the other options are not as suitable

  • Option A is wrong because simply raising the cap from 3 to 10 does not eliminate the architectural flaw — it only shifts the truncation threshold; documents requiring 11 or more calls would still be silently truncated, and the blueprint's guidance is to remove the cap as the primary signal entirely, not to tune its value.
  • Option B is wrong because substituting a token-usage cap for an iteration cap still makes resource consumption — rather than the model's own stop_reason signal — the primary termination driver; the blueprint does not endorse token budgets as the main loop-control mechanism, and a token ceiling would still silently truncate legitimate multi-step tasks before the model reaches 'end_turn'.
  • Option D is wrong because asking the model to estimate its own tool-call count up front and then using that estimate as a per-document cap introduces a new probabilistic dependency — model estimates are unreliable for variable documents — and still results in an arbitrary cap that can under- or over-estimate, perpetuating the same class of truncation or runaway risk the blueprint warns against.

  Citations

  • https://anthropic-partners.skilljar.com/claude-certified-architect-foundations-certification

• Question 4

  A research pipeline's agentic loop must call three tools in sequence—search, summarize, and compile—before the model can produce its final answer. Each tool call corresponds to one assistant turn returning stop_reason 'tool_use'; after each, the tool result is appended and the conversation is resubmitted. The model's final turn returns stop_reason 'end_turn' with no further tool calls. How many total API requests does this single task run generate?

  • A. 4 total requests — one per tool-use turn plus the final end_turn turn.
  • B. 6 requests, assuming each tool call requires a separate acknowledgment request in addition to the tool_use turn before the next tool can run.
  • C. 3 requests, one per tool call, since the final end_turn response is typically bundled with the last tool result rather than sent separately.
  • D. 5 requests, including an extra initial planning request issued before the search tool call to determine the correct tool sequence.

  Correct Answer: A

  Explanation:

  Option A is correct. A three-tool sequential pipeline generates exactly 4 API requests: one for each tool-use turn (3) plus one final turn that returns end_turn.

  Reason

  The agentic loop lifecycle as defined in Domain 1 of the CCAR-F blueprint works as follows: each assistant turn that returns stop_reason 'tool_use' constitutes one API request; the orchestrating code appends the tool result as a user message and resubmits, generating the next API request. For three sequential tool calls (search → summarize → compile), that produces three tool-use turns (requests 1, 2, 3). After the last tool result is appended and resubmitted, the model responds with stop_reason 'end_turn' and no further tool calls — that is the fourth and final API request. There are no hidden acknowledgment calls, planning calls, or bundled responses; the loop is strictly request → response → append result → repeat.

  Why the other options are not as suitable

  • Option B is wrong because there is no 'acknowledgment request' step in the standard agentic loop; appending a tool_result and resubmitting is a single API call, not two.
  • Option C is wrong because the final end_turn response is never bundled with the last tool result — the tool result is appended as a user-turn message and a new API request is made, which then produces the end_turn response as a separate call.
  • Option D is wrong because the agentic loop does not issue an extra planning request before the first tool call; the model determines tool sequencing within its own generation on the first request, not via a separate pre-flight planning API call.

  Citations

  • https://anthropic-partners.skilljar.com/claude-certified-architect-foundations-certification

• Question 5

  While generating a long tool_use block, a request returns stop_reason 'max_tokens' instead of 'tool_use' or 'end_turn', meaning the response was cut off mid-generation. How should a well-designed agentic loop handle this case?

  • A. Automatically resubmit the same request once with a larger max_tokens budget, treating the outcome as an ordinary tool_use turn without separately logging or flagging that a truncation occurred
  • B. Discard the truncated content and resubmit from the prior turn as though the max_tokens response never happened, relying on the next generation attempt to complete normally
  • C. Recognize it as a distinct incomplete state needing different handling than a normal completion or tool call, such as flagging for retry or escalation rather than treating it as success
  • D. Treat it the same as a completed tool_use block and execute whatever partial tool call was captured, since the block's name and partial input fields may already contain enough information to attempt the call

  Correct Answer: C

  Explanation:

  Option C is correct. A stop_reason of 'max_tokens' mid-tool-use block is a distinct incomplete state that requires special handling — not the same as a normal tool_use or end_turn completion.

  Reason

  The CCAR-F Domain 1 blueprint specifically calls out stop_reason values ('tool_use' vs. 'end_turn') as key signals the agentic loop must interpret correctly, and the Exam Guide's reliability and error-handling objectives extend this to incomplete/truncated states. A response cut off by max_tokens during a tool_use block means the JSON tool call is malformed and unexecutable; treating it as either a successful tool_use or a silent retry without logging violates sound agentic loop design. The correct architecture flags this as a distinct error state — requiring either a retry with an adjusted max_tokens budget, escalation to a human-in-the-loop workflow, or structured error logging — so the system does not silently corrupt conversation history or attempt to execute a partial tool call.

  Why the other options are not as suitable

  • Option A is wrong because automatically resubmitting without logging or flagging obscures a real failure mode from observability and monitoring systems, which violates the reliability principles in Domain 5.
  • Option B is wrong because simply discarding the truncated content and resubmitting from the prior turn without any special handling treats a structural truncation error as a normal no-op, which can cause silent data loss and does not address why the truncation occurred.
  • Option D is wrong because executing a partial tool_use block is dangerous — the tool call's input JSON is incomplete and likely unparseable, and attempting execution on partial data can cause downstream errors, data corruption, or unintended side effects in connected systems.

  Citations

  • https://anthropic-partners.skilljar.com/claude-certified-architect-foundations-certification

• Question 6

  A coordinator agent's response includes stop_reason 'tool_use' along with three separate tool_use content blocks in the same message (a parallel tool-call pattern). What is the correct way to continue the agentic loop?

  • A. Execute only the first tool_use block and ignore the rest to keep the loop simple
  • B. Execute all three tool calls, then combine all three tool_result blocks into one subsequent user turn before resubmitting the conversation.
  • C. Reject the response and force the model to regenerate with only one tool call at a time, since sequential execution is sometimes assumed to reduce race conditions when multiple tools modify shared state concurrently.
  • D. Split the three tool calls into three separate follow-up conversations run independently

  Correct Answer: B

  Explanation:

  Option B is correct. When a coordinator returns multiple tool_use blocks in a single response, all tool calls should be executed and all their results collected into one combined user turn before resubmitting.

  Reason

  The CCAR-F Domain 1 blueprint explicitly describes parallel spawning as 'multiple Task calls in one response' and specifies that this is a valid, intentional pattern for concurrent tool execution. The correct loop behavior is to execute all tool calls in the batch, then return all corresponding tool_result blocks in a single subsequent user message before resubmitting the conversation. This preserves conversation history integrity — the model expects a tool_result for every tool_use block it emitted — and allows the coordinator to reason over all results at once. The parallel pattern exists precisely to improve throughput and reduce total API round-trips.

  Why the other options are not as suitable

  • Option A is wrong because ignoring tool_use blocks that the model explicitly requested breaks the agentic loop contract — the model expects a result for each tool_use block, and omitting results will cause errors or undefined behavior on the next turn.
  • Option C is wrong because forcing sequential single-tool regeneration destroys the parallelism the coordinator intentionally expressed, and the premise that parallel tool calls always cause race conditions is false — the architect is responsible for designing tools that are safe to call in parallel when the model is allowed to do so.
  • Option D is wrong because splitting tool calls into separate independent conversations would break shared conversation context, prevent the coordinator from reasoning over combined results, and is architecturally incompatible with the single-task agentic loop model described in the CCAR-F blueprint.

  Citations

  • https://anthropic-partners.skilljar.com/claude-certified-architect-foundations-certification

• Question 7

  A customer-support agent's loop has produced 18 consecutive turns with stop_reason 'tool_use' without ever reaching 'end_turn', suggesting the agent may be stuck in an unproductive cycle rather than making genuine progress toward resolution. Beyond simply capping iterations, what is the more robust reliability pattern?

  • A. Immediately terminate after exactly 10 turns in all future runs, since empirical testing on this specific support workflow showed that most successful resolutions complete well within that many tool-use turns.
  • B. Switch the model's system prompt to ask it to 'try harder' and continue the loop unchanged
  • C. Instrument the loop to detect lack of meaningful progress across turns (e.g., via hooks or state tracking), and trigger escalation or human review rather than relying only on a fixed turn count.
  • D. Ignore the pattern since stop_reason 'tool_use' always implies forward progress

  Correct Answer: C

  Explanation:

  Option C is correct. The CCAR-F blueprint explicitly contrasts robust programmatic loop-control mechanisms against brittle prompt-only or arbitrary-cap approaches, and escalation/human-in-the-loop is the canonical reliability pattern when genuine forward progress cannot be confirmed.

  Reason

  The CCAR-F Domain 1 knowledge summary specifically warns against arbitrary iteration caps as an anti-pattern, and Domain 5 (Context Management & Reliability) elevates human-in-the-loop workflows and self-evaluation patterns as production-grade reliability mechanisms. Option C addresses both concerns: it uses programmatic state tracking or hooks (e.g., PostToolUse hooks from the Agent SDK) to detect whether the loop is making meaningful progress, and it triggers escalation or human review rather than blindly cutting the loop at a fixed number. This distinguishes genuine completion signals from looping failure modes. The Exam Guide's intended audience section emphasises 'sound escalation and reliability decisions, including error handling, human-in-the-loop workflows, and self-evaluation patterns' as core practitioner competencies.

  Why the other options are not as suitable

  • Option A is wrong because capping at a hard-coded turn count (even one derived from empirical testing on a specific workflow) is precisely the arbitrary iteration cap anti-pattern the blueprint explicitly lists as something practitioners must avoid; it does not distinguish a stuck loop from a legitimately complex resolution that happens to require many tool calls.
  • Option B is wrong because changing the system prompt to instruct the model to 'try harder' is a prompt-only probabilistic instruction, which the blueprint contrasts unfavorably against programmatic enforcement; it does nothing to detect or break an infinite loop.
  • Option D is wrong because stop_reason 'tool_use' does not imply forward progress—it only indicates the model emitted a tool-use block and is awaiting a result; a loop stuck calling the same tool repeatedly will always return this stop_reason, making it useless as a progress signal.

  Citations

  • https://anthropic-partners.skilljar.com/claude-certified-architect-foundations-certification

• Question 8

  In the core agentic loop lifecycle, which condition correctly signals that the model has produced its final answer and no further tool invocation is expected, allowing the loop to exit normally?

  • A. The assistant's response contains a period at the end of the last sentence
  • B. The tool result returned an empty payload
  • C. The number of turns exceeds an arbitrary configured maximum
  • D. stop_reason equals 'end_turn'

  Correct Answer: D

  Explanation:

  Option D is correct. The CCAR-F Domain 1 knowledge summary explicitly names stop_reason 'end_turn' as the canonical signal that the model has completed its turn without requesting further tool use, allowing the agentic loop to exit normally.

  Reason

  Domain 1 of the CCAR-F blueprint directly specifies the agentic loop lifecycle in terms of two named stop_reason values: 'tool_use' (the model is requesting a tool call and the loop must continue) and 'end_turn' (the model has produced its final response and no further tool invocation is expected). When the API returns stop_reason == 'end_turn', the loop control logic should recognise this as the normal exit condition and return the assistant's final message to the caller. This is a deterministic, machine-readable signal—not a heuristic—making it the most reliable loop-termination check in production agentic architectures.

  Why the other options are not as suitable

  • Option A is wrong because the presence of a period at the end of a sentence is a natural-language surface signal; the blueprint explicitly lists 'parsing natural-language completion signals' as an anti-pattern to avoid in agentic loop design.
  • Option B is wrong because an empty tool result payload indicates only that a tool returned no data, not that the model has finished its turn; the model may still emit further tool calls in subsequent turns.
  • Option C is wrong because exceeding an arbitrary configured maximum is the iteration-cap anti-pattern explicitly called out in Domain 1's anti-pattern list; it is a fallback guard, not the correct normal-exit signal.

  Citations

  • https://anthropic-partners.skilljar.com/claude-certified-architect-foundations-certification

• Question 9

  An agentic workflow requires a subagent to call `validate_schema` before it is allowed to call `write_to_db`. The team enforces this only through a system prompt instruction telling the model the correct order. Under load, the team observes that the model occasionally calls `write_to_db` first, skipping validation. What is the most reliable fix?

  • A. Add a hook that intercepts the `write_to_db` call and blocks it unless `validate_schema` has already succeeded earlier in the session.
  • B. Rephrase the prompt instruction using stronger imperative language such as 'You MUST always validate first'
  • C. Increase the model's max_tokens so it has more room to reason about ordering
  • D. Add the ordering requirement to a few-shot example in the prompt instead of stating it directly, since demonstrating the correct call sequence with concrete examples is often assumed to generalize better than abstract instructions.

  Correct Answer: A

  Explanation:

  Option A is correct. The CCAR-F Domain 1 knowledge summary explicitly contrasts programmatic enforcement via hooks against probabilistic prompt-only instructions, and the Agent SDK's PostToolUse (and tool-call interception) hooks are the prescribed mechanism for enforcing business-rule ordering.

  Reason

  The CCAR-F blueprint Domain 1 states that multi-step workflow enforcement must use programmatic hooks rather than probabilistic prompt-only instructions, precisely because LLMs can and do deviate from ordering rules under load or in edge cases. The Agent SDK's tool-call interception hooks allow the orchestration layer to inspect the call being made, check whether prerequisite steps (here, a successful `validate_schema` call) have been recorded in session state, and block or redirect the call if the precondition is unmet. This converts a probabilistic instruction into a hard, deterministic guardrail—exactly the reliability pattern the exam tests. The team's real observation (occasional skipping of validation under load) is the canonical failure mode that prompts this architectural shift.

  Why the other options are not as suitable

  • Option B is wrong because rephrasing the prompt with stronger imperative language ('You MUST always validate first') is still a prompt-only probabilistic instruction; the blueprint explicitly warns that such instructions cannot guarantee execution order, which the team has already empirically confirmed by observing failures under load.
  • Option C is wrong because increasing max_tokens affects only the length of the model's output, not its adherence to tool-call ordering; reasoning depth is not the root cause of ordering violations, and this change would have no effect on the described failure mode.
  • Option D is wrong because moving the ordering requirement into a few-shot example rather than a direct instruction is still a probabilistic, prompt-based approach; while few-shot examples can improve generalisation for output formatting tasks, they do not provide the deterministic enforcement that business-rule tool sequencing requires, and the blueprint does not recommend few-shot examples as the primary mechanism for enforcing execution order.

  Citations

  • https://anthropic-partners.skilljar.com/claude-certified-architect-foundations-certification

• Question 10

  A tool returns customer phone numbers in inconsistent formats (e.g., '(555) 123-4567', '555.123.4567'). The architecture team wants every tool result appended to the conversation history to already be normalized to a single consistent format before the model ever sees it, without depending on the model to reformat it correctly. Which mechanism should they use?

  • A. A PostToolUse hook that normalizes the tool's raw output into a single consistent format before it is added to conversation history
  • B. A PreToolUse hook that normalizes the arguments passed into the tool before it runs, rather than the value it returns
  • C. A system prompt instructing the model to reformat phone numbers into a single consistent pattern whenever it produces output that references them
  • D. A few-shot example embedded in the tool definition showing one already-normalized phone number, so the model learns the target format from that example

  Correct Answer: A

  Explanation:

  Option A is correct. A PostToolUse hook intercepts the tool's raw output after execution and before it is appended to conversation history, making it the precise architectural point to apply normalization programmatically rather than probabilistically.

  Reason

  The PostToolUse hook fires after a tool has executed but before its result is written into the conversation history. This means any transformation applied in the hook — such as normalizing phone number formats — is guaranteed to reach the model in the desired canonical form every single time, with no dependence on the model's own reformatting behavior. The Domain 1 blueprint explicitly identifies Agent SDK hooks (PostToolUse, tool call interception) for business-rule enforcement as the correct mechanism for enforcing invariants programmatically rather than probabilistically. Because the hook runs in code, it is deterministic: every tool result passes through the same normalization logic before the model sees it, eliminating format variance entirely.

  Why the other options are not as suitable

  • Option B is wrong because a PreToolUse hook fires before the tool runs and can only inspect or modify the arguments passed into the tool — it has no visibility into the value the tool returns, so it cannot normalize the output.
  • Option C is wrong because a system prompt instruction delegates reformatting responsibility to the model itself, which is a probabilistic mechanism; the model may comply inconsistently, especially under long contexts or competing instructions, which is the exact anti-pattern the team is trying to avoid.
  • Option D is wrong because a single few-shot example in a tool description illustrates an expected output format but does not enforce it — the model may still surface raw tool results in their original inconsistent formats, particularly when the tool result is injected directly into conversation history rather than generated by the model.

  Citations

  • https://anthropic-partners.skilljar.com/claude-certified-architect-foundations-certification