Five real, previously unpublished CCA-F practice questions for the highest-weighted domain on the exam: Agentic Architecture & Orchestration (27% of the test). Try to answer each one yourself before revealing the explanation — that's how you actually find the gaps in your understanding.
Practice the full domain-filtered set on AICert Study →
Question 1
A team caps the agentic loop at 5 iterations as the primary stop condition for the customer support agent. After a complex multi-tool dispute, the agent stops mid-investigation without returning a final answer. What does this reveal about the design?
- A. The model is broken; switch to a more capable model.
- B. Iteration caps were used as the primary stop mechanism instead of stop_reason. Caps should be a backstop, not the main termination logic.
- C. The user prompt is too long; truncate it.
- D. Increase the cap to 50 and the problem will disappear.
Show answer & explanation
Correct answer: B
Hard iteration caps are a safety backstop to prevent runaway costs or infinite loops, not the primary signal for whether work is complete. Using them as the main termination mechanism causes the agent to abandon legitimate multi-step work. The correct primary signal is stop_reason='end_turn'; caps catch pathological cases only.
- The model is broken... is incorrect. The model is producing tool_use blocks correctly; the harness is killing the loop early. Changing models will not fix a wrong stop condition.
- The user prompt is too long... is incorrect. Prompt length has no direct relation to the number of agentic iterations needed and does not explain the early termination.
- Increase the cap to 50... is incorrect. Raising the cap hides the symptom but the design flaw remains: the primary stop signal should be the model's own stop_reason, not an arbitrary counter.
Share this question on LinkedIn →
Question 2
When a tool call inside the agentic loop returns a tool_result, what must be true about that block for the next API call to succeed?
- A. It must be sent as an assistant-role message.
- B. Its tool_use_id must match the tool_use block the model previously produced, and it must be sent in a user-role message.
- C. It must be wrapped inside a system prompt for the next turn.
- D. It can use any unique id and is sent inside the assistant message.
Show answer & explanation
Correct answer: B
Tool results are returned in a user-role message and their tool_use_id field must match the id of the corresponding tool_use block the assistant produced. This correlation is how Claude knows which result belongs to which call.
- It must be sent as an assistant-role message... is incorrect. The assistant role is reserved for the model's own output; tool results come from your code and are conventionally placed in user messages.
- It must be wrapped inside a system prompt... is incorrect. The system prompt is set once for the conversation; tool_result blocks belong to the message turn, not the system slot.
- It can use any unique id... is incorrect. tool_use_id must exactly match the assistant's tool_use id, otherwise the API rejects the request or the model cannot correlate the result.
Share this question on LinkedIn →
Question 3
A support agent's first turn requests three tools in parallel (get_customer, lookup_order, check_loyalty_status). Your loop executes them and prepares the next API call. How should the tool_results be sent back?
- A. As three separate user messages, one tool_result each, in chronological execution order.
- B. All three tool_result blocks in a single user message, each referencing its corresponding tool_use_id.
- C. Only the first result; the other two will be re-requested on the next iteration.
- D. As assistant-role messages so the model can read them in sequence.
Show answer & explanation
Correct answer: B
When the assistant requests multiple tools in parallel within a single turn, all tool_result blocks belong in one user-role message, each referencing the matching tool_use_id. The model expects all parallel results in the next turn so it can reason over them together.
- As three separate user messages... is incorrect. Splitting parallel results across turns breaks the request/response structure; the API requires all tool_results for an assistant turn to be in the immediately following user turn.
- Only the first result... is incorrect. The API will reject the request because the conversation is missing tool_results for the other tool_use_ids in the previous turn.
- As assistant-role messages... is incorrect. Tool results are not produced by the model; placing them under the assistant role corrupts the conversation structure.
Share this question on LinkedIn →
Question 4
A developer agent runs in production with an agentic loop. Engineers observe occasional infinite loops where the model repeatedly calls Grep with slight variations. What is the most appropriate, layered mitigation strategy?
- A. Remove Grep from allowedTools so it cannot be invoked.
- B. Rely solely on stop_reason and trust the model to terminate.
- C. Use stop_reason as primary termination, add a maxTurns/iteration cap as a backstop, and improve prompts and tool descriptions to reduce churn.
- D. Parse the assistant's text after every turn and stop when it mentions 'no more matches'.
Show answer & explanation
Correct answer: C
The correct architecture treats stop_reason as the authoritative termination signal but pairs it with a maxTurns cap so pathological behavior cannot consume unbounded budget. Improving prompts and tool descriptions addresses the root cause of churn (the model is uncertain about its strategy).
- Remove Grep from allowedTools... is incorrect. Disabling a useful tool degrades the agent rather than fixing the loop logic.
- Rely solely on stop_reason... is incorrect. Trusting the model entirely with no backstop leaves you exposed to bugs, model regressions, or pathological prompts.
- Parse the assistant's text... is incorrect. NL-based termination is the anti-pattern that causes unreliable behavior in the first place.
Share this question on LinkedIn →
Question 5
A team's agent loop checks if 'thank you' in response.text: break. In production, the agent terminates after greeting the customer and never calls any tools. What two things are simultaneously wrong with this design?
- A. The temperature is too high and the wait time is too short.
- B. NL parsing is used as the stop signal (anti-pattern), and the loop ignores stop_reason='tool_use' which means it should continue.
- C. The system prompt is missing and the model is unauthenticated.
- D. The tools array is empty and max_tokens is set too low.
Show answer & explanation
Correct answer: B
Two compounding flaws: (1) parsing assistant prose ('thank you') to determine termination is unreliable because the model can greet customers conversationally before issuing tools; (2) the loop should look at stop_reason rather than text. If the first turn returns stop_reason='tool_use' (the agent intends to call get_customer) but the harness breaks because the greeting contained 'thank you', work is abandoned before it begins.
- The temperature is too high... is incorrect. Temperature does not eliminate common politeness phrases or change the structural problem.
- The system prompt is missing... is incorrect. Greeting behavior shows the model is responding; this is unrelated to authentication or system prompt presence.
- The tools array is empty... is incorrect. If tools were missing the API would not return tool_use at all; the scenario implies tools exist but the loop ends before they execute.
Share this question on LinkedIn →
Want more? Our free bank has hundreds of Agentic Architecture questions. Practice them all →