CCDV-F practice questions: Agents and workflows.

Which loop correctly implements a tool-using agent?

• Call the model once with tool_choice any and return the first tool_use arguments
• Call the model; on tool_use run the tool, append the result, call again; stop on end_turn or a turn cap
• Call the model repeatedly until its text no longer mentions any tool by name
• Run every declared tool up front with default arguments, then pass all of the results to the model in a single call

What does the Claude Agent SDK handle for you that a hand-rolled loop does not?

• Automatic retries, rate-limit backoff, and typed request and response objects
• Fine-tuning the model on your repository before the first run
• The agent loop, tool execution, permission checks, hooks, and subagents
• Server-side tool execution so your code does not have to handle tool_use blocks

In a hand-rolled agent loop, what must happen before calling the model again after a tool call?

• Remove the tool_use block from history so the model does not call it again
• Change tool_choice to none so the model must answer in text
• Append a tool_result block whose tool_use_id matches the tool_use block
• Reset the conversation and resend the system prompt with the tool output

Which pattern fits 'translate, then have a second call grade the translation, then revise until it passes'?

• Routing by input type
• Orchestrator-workers
• Parallel sectioning
• Evaluator-optimizer loop

What should limit an agent loop besides end_turn?

• A maximum number of iterations plus a time or cost budget
• The context window, which ends the loop once it fills up
• A stop sequence that fires when the model writes the word done
• A max_tokens value low enough to stop long-running turns

The Claude Agent SDK's hooks are useful for:

• Switching the model mid-run when a task turns out to need more capability than expected
• Rewriting the system prompt between turns based on the user's tone
• Injecting API credentials into the environment before each tool runs
• Running deterministic checks around tool calls, such as blocking a dangerous command

A workflow has a step that sometimes needs human input. How should the code model it?

• A default value so the step completes and the human reviews afterwards
• A pause state that persists progress and resumes when the input arrives
• A blocking loop that polls for the input every few seconds until it appears
• A retry policy that restarts the workflow from the top once input exists

Which is true about subagents in the SDK?

• They must use the same system prompt and model as the parent
• They run with their own context and return a result to the parent
• They share the parent's full conversation so nothing needs restating
• They run tools only through the parent, which executes on their behalf

Why give each workflow step one responsibility?

• Each step becomes testable on its own and failures are easier to localize
• It lets every step share one system prompt across the whole workflow, which keeps behavior consistent
• Smaller steps use fewer tokens per run, which lowers cost
• The API rejects steps that combine more than one tool